New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
removing specific ip for jetty connector on port 8181 #101
Conversation
having this seems to deny some service from binding to that port. Signed-off-by: Jamo Luhrsen <jluhrsen@redhat.com>
more info for why I did this. I noticed in our opnfv deploy that I was seeing a BindException in the opendaylight logs (karaf.log) on It seems when we specify the ip address as part of the jetty connector some service cannot bind to org.ops4j.pax.web.pax-web-jetty - 3.1.4 | Connection on port 8181 cannot be open. Exception:java.net.BindException: Address already in use Reason: Address already in use seems that "org.eclipse.jetty.aggregate.jetty-all-server" already has been bound to it. When this config is not there, both seem to bind properly: org.eclipse.jetty.aggregate.jetty-all-server - 8.1.15.v20140411 | STARTED SelectChannelConnector@0.0.0.0:8181 I'm really not sure if anything was truly broken, but seeing these BindExceptions have |
@trozet added this recently - can you comment Tim? Update: It doesn't look like it would resolve to correct XML as it stands. |
@dfarrell07 @jluhrsen Right, we added this because HA Proxy needs to assign a VIP with the same port for load balancing across ODL in HA and the bind will fail when ODL is bound to 0.0.0.0. However, we only care about port 8081, which is a separate jetty connection. I had just added 8181 so that it also bound to a specific IP, but as JamO mentioned we hit bind errors as some other service in ODL is binding to 0.0.0.0 for 8181 port. I'm not sure if we even need that 8181 jetty connection at all, but I'm fine with removing the IP on that connection only (we still need to use the specific IP on 8081). |
@jluhrsen coming back to this one. Can we remove any bind to 8181? We only seem to access port 8081 in TripleO deployments and it works fine. |
yeah, should be fine. |
@jluhrsen can you update the PR to remove the 8181 connection please? |
seems some deployments, like done with TripleO, tweak the ports used by OpenDaylight to their own needs so forcing 8181 here causes some headaches Signed-off-by: Jamo Luhrsen <jluhrsen@redhat.com>
@trozet @dfarrell07 I don't know if I did that right. my fork was really old. let me know if I need to do a new PR and I can do it from scratch. |
Not totally sure I follow this change. The config we're removing is in ODL's default jetty.xml (for latest stable/boron at least). Shouldn't we just be moving to modifying the one port number with something-other-than-template? |
</New> | ||
</Arg> | ||
</Call> | ||
<Call name="addConnector"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dfarrell07 I saw your comment in email that this doesn't look like valid XML, but
I think it's just how git(hub) shows the diff. this line 51 is shown as deleted, but it's
still kept up in line 33. it should be ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's exactly what I was seeing. Removed comment because I saw the strange diff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, ok. I couldn't figure out where the comment was.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as for the purpose of this change, I'm not 100% either.
@trozet, what do we want here? you just want to stop 8181 from lighting up, or you want to also make 8081 come on in place of 8181. From what I know, there are two places that control this:
etc/jetty.xml
etc/org.ops4j.pax.web.cfg
Where is tripleO or apex, etc controlling this 8081?
@dfarrell07 Is the preferred method here to use file_line ? |
+1 to this question @trozet. I used to be able to find this, but can't atm. I see where you pull the puppet module but not where you invoke it. That is done here: That heat parameter gets translated into hieradata, here: |
@dfarrell07 @jluhrsen so we cant use xmlfile becuase that puppet mod isnt available in RDO and we dont want to create a dependency on that mod if we can help it in puppet-odl. Augeas is an option, with an xml lens. I just tried it out, but it looks worse than fileline in my opinion because the XML path is not clear to set the host: ^see it is parsing it as array values for hte sections, because I guess there is no clear xml attribute I think file_line is the way to go for now. @jluhrsen can you update the patch? Also, @dfarrell07 just to confirm, there is only one connection defined in the default ODL jetty.xml, right? |
@trozet Okay, that makes sense, +1 to using file_line.
Both Pre-Boron SR3 and Pre-Carbon jetty.xml add two connectors by default. |
@dfarrell07 then I think we should continue to use a template, otherwise we have the same problem where there are 2 connections, and we only want 1 |
What's wrong with having both ports? Does it cause some problem? If so, maybe we should work on getting one removed from the upstream distro. I'm hesitant to remove a port in this downstream, custom way. Seems to add a lot of risk. |
let's see if anything comes of it: https://lists.opendaylight.org/pipermail/release/2017-February/009226.html you guys can/should reply to that email with support. |
Making good progress https://bugs.opendaylight.org/show_bug.cgi?id=7756 |
having this seems to deny some service from binding
to that port.
Signed-off-by: Jamo Luhrsen jluhrsen@redhat.com