Skip to content
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

Closed
wants to merge 3 commits into from
Closed

removing specific ip for jetty connector on port 8181 #101

wants to merge 3 commits into from

Conversation

jluhrsen
Copy link
Contributor

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

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

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

Signed-off-by: Jamo Luhrsen <jluhrsen@redhat.com>
@jluhrsen
Copy link
Contributor Author

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
Copy link
Owner

@trozet added this recently - can you comment Tim?

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

@trozet
Copy link
Collaborator

trozet commented Mar 24, 2016

@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
Copy link
Collaborator

trozet commented Jan 18, 2017

@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
Copy link
Contributor Author

yeah, should be fine.

@trozet
Copy link
Collaborator

trozet commented Jan 18, 2017

@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>
@jluhrsen
Copy link
Contributor Author

@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
Copy link
Owner

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">
Copy link
Contributor Author

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.

Copy link
Owner

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

@trozet
Copy link
Collaborator

trozet commented Jan 27, 2017

@dfarrell07 Is the preferred method here to use file_line ?

@dfarrell07
Copy link
Owner

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
Copy link
Owner

dfarrell07 commented Jan 27, 2017

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
Copy link
Collaborator

trozet commented Jan 27, 2017

@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
Copy link
Owner

@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
Copy link
Collaborator

trozet commented Jan 30, 2017

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
Copy link
Owner

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
Copy link
Contributor Author

jluhrsen commented Feb 3, 2017

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
Copy link
Owner

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

@jluhrsen jluhrsen closed this Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants