removing specific ip for jetty connector on port 8181

[jluhrsen]

having this seems to deny some service from binding to that port.

Signed-off-by: Jamo Luhrsen jluhrsen@redhat.com

[jluhrsen]

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 port 8181. This is not there in the distribution taken directly from unpackaged opendaylight.

It seems when we specify the ip address as part of the jetty connector some service cannot bind to port 8181. log ERROR:

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 org.ops4j.pax.web.pax-web-jetty - 3.1.4 | Pax Web available at [0.0.0.0]:[8181]

I'm really not sure if anything was truly broken, but seeing these BindExceptions have been worrying me lately. Maybe there is a really good reason for it, and we can ignore the BindException?

[dfarrell07]

@trozet added this recently - can you comment Tim?

Update: It doesn't look like it would resolve to correct XML as it stands.

[trozet]

@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).

[trozet]

@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.

[jluhrsen]

yeah, should be fine.

[trozet]

@jluhrsen can you update the PR to remove the 8181 connection please?

[jluhrsen]

@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.

[dfarrell07]

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?

[trozet]

@dfarrell07 Is the preferred method here to use file_line ?

[dfarrell07]

Is the preferred method here to use file_line ?

@trozet I looked into editing XML files with Puppet while we were talking about #125. The best option I know about is the xmlfile Puppet module to abstract Augeas. I'm also okay with file_line.

[dfarrell07]

Where is tripleO or apex, etc controlling this 8081?

+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: https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/opendaylight-api.yaml#L8

That heat parameter gets translated into hieradata, here: https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/opendaylight-api.yaml#L52

[trozet]

@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: /files/var/lib/jenkins/jetty.xml/Configure/Call[1]/Arg/New/Set[1]/#attribute/name = "host" /files/var/lib/jenkins/jetty.xml/Configure/Call[1]/Arg/New/Set[1]/#text[1] /files/var/lib/jenkins/jetty.xml/Configure/Call[1]/Arg/New/Set[1]/#text[1] = "192.0.2.4\n

^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?

[dfarrell07]

@trozet Okay, that makes sense, +1 to using file_line.

Also, @dfarrell07 just to confirm, there is only one connection defined in the default ODL jetty.xml, right?

Both Pre-Boron SR3 and Pre-Carbon jetty.xml add two connectors by default.

[trozet]

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

[dfarrell07]

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 - @trozet

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.

[jluhrsen]

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.

[dfarrell07]

let's see if anything comes of it

Making good progress

https://bugs.opendaylight.org/show_bug.cgi?id=7756 https://git.opendaylight.org/gerrit/51531