[release] [integration-dev] [netide-dev] BindException in release bits.


Gao Kai <gaok12@...>
 

Jensen, Xiao and all,

We need to check if we have put the right port information on the following wiki pages.

Xiao,

Can you please check if we are still using port 8181? Thanks!

Regards,
Kai


-------- Forwarded Message --------
Subject: Re: [release] [integration-dev] [netide-dev] BindException in release bits.
Date: Fri, 25 Mar 2016 22:08:27 +0000
From: An Ho <An.Ho@...>
To: Abhijit Kumbhare <abhijitkoss@...>, Daniel Farrell <dfarrell@...>
CC: jgoodyear@... <jgoodyear@...>, vpnservice-dev@... <vpnservice-dev@...>, integration-dev@... <integration-dev@...>, Release <release@...>, netide-dev@... <netide-dev@...>


At the moment, we ask projects to report their ports on the wiki [1], the test plan [2], and the milestone readout [3].  We could also add it to the Per-Project Release Plan.  However, as we scale on the growing number of projects, I wish we had some automatic mechanism to detect potential port conflicts using something like static analysis at build time or introspection at runtime.

 

Best Regards,

An Ho

 

[1] https://wiki.opendaylight.org/view/Ports

[2] https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Feature_Integration_System_Test_Template#Feature_Pro-activeness

[3] Question 7.  https://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#M4:_API_Freeze

 

 

 

From: release-bounces@... [mailto:release-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Thursday, March 24, 2016 10:42 PM
To: Daniel Farrell
Cc: Release; jgoodyear@...; vpnservice-dev@...; integration-dev@...; netide-dev@...
Subject: Re: [release] [integration-dev] [netide-dev] BindException in release bits.

 

I was actually suggesting also somewhere in the code this port info is registered - beyond the wiki. BTW the wiki info is accurate for OpenFlow.

 

On Thu, Mar 24, 2016 at 4:45 PM, Daniel Farrell <dfarrell@...> wrote:

@PTLs - Please verify your ports are correct on wiki/Ports (as it
seems to now be fairly important/official).

https://wiki.opendaylight.org/view/Ports

One way we could force an up-to-date port list from projects would
be to add it to the Per-Project Release Plan.

https://wiki.opendaylight.org/view/Simultaneous_Release:Per-Project_Boron_Release_Plan_Template

We could (manually, for now) make sure that wiki/Ports is correct
and that there are no conflicts.

Daniel Farrell
Software Engineer, Red Hat SDN Team
https://wiki.opendaylight.org/view/user:dfarrell07


----- Original Message -----
> May be register in some central place (may be in the datastore) what ports
> are being used?
>
> On Thu, Mar 24, 2016 at 12:00 PM, Luis Gomez <ecelgp@...> wrote:
>
> > Even when 2 projects are not designed to work together we want to avoid
> > port conflicts as much as possible, so for that we ask projects to look and
> > maintain the Ports wiki, at least until we get something better in place.
> >
> > BR/Luis
> >
> >
> > > On Mar 24, 2016, at 11:41 AM, Jamo Luhrsen <jluhrsen@...> wrote:
> > >
> > > Thanks Alec,
> > >
> > > On 03/24/2016 03:56 AM, Leckey, Alexander J wrote:
> > >> All,
> > >>
> > >> Before selecting port 6644, the NetIDE team did review the Port wiki
> > [1] for available ports to ensure 6644 was
> > >> available before choosing it. This was reflected in our M4 status email
> > [2] and updated by An in the tracking
> > >> spreadsheet [3]. I'll ask the VPNservice team to confirm, but it does
> > look like they only selected this port recently
> > >> as their M4 status for ports used was "N/A" [4]
> > >
> > > I think all of this sounds like NetIDE did all the right things with
> > > taking port 6644.
> > >
> > >>
> > >> However, it should be handled more gracefully by the NetIDE code
> > (catching BindException + Karaf Log - I'll open our
> > >> own bug for this).
> > >
> > > if you open another bug, please close 5597 which I opened for the same
> > > reason.
> > >
> > >> Although this is a configurable item in the NetIDE config file, how do
> > you decide who takes precedence on ports?
> > >
> > > Currently, the Ports wiki (which you checked) is our only "official"
> > place
> > > to track these things.
> > >
> > >
> > > JamO
> > >
> > >
> > >
> > >> Rgds, Alec.
> > >>
> > >> [1] https://wiki.opendaylight.org/view/Ports#Ports [2]
> > >>
> > https://lists.opendaylight.org/pipermail/release/2015-December/004723.html
> > [3]
> > >>
> > https://docs.google.com/spreadsheets/d/1Kfp5HVQGydNegEjp6dD2V3XsUnqpice0bysWbdxABA4/edit#gid=1512609931
> > [4]
> > >>
> > https://lists.opendaylight.org/pipermail/release/2015-December/004716.html
> > >>
> > >>
> > >>
> > >> -----Original Message----- From:
> > netide-dev-bounces@...
> > >> [mailto:netide-dev-bounces@...] On Behalf Of Luis
> > Gomez Sent: Wednesday, March 23, 2016 7:07 PM
> > >> To: Jamo Luhrsen <jluhrsen@...>; Release <
> > release@...> Cc: An Ho <An.Ho@...>; Thanh
> > >> Ha <thanh.ha@...>; jgoodyear@...;
> > vpnservice-dev@...;
> > >> integration-dev@...;
> > netide-dev@... Subject: Re: [netide-dev]
> > [integration-dev]
> > >> BindException in release bits.
> > >>
> > >> Adding the release list, I think for now projects should just look at
> > the port wiki [4] before assigning ports and
> > >> update the list once the ports are used. We brought this few times in
> > the past but people may forget.
> > >>
> > >> BR/Luis
> > >>
> > >>
> > >>> On Mar 23, 2016, at 11:45 AM, Jamo Luhrsen <jluhrsen@...> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On 03/23/2016 11:36 AM, Thanh Ha wrote:
> > >>>> Is it possible to script something that either scans the code base or
> > karaf features for potential ports that a
> > >>>> project might be trying to open?
> > >>>
> > >>> My guess is that projects are opening these ports in many different
> > ways so scanning might not be so easy.  In this
> > >>> example netide configures it's port number in an .xml config file, and
> > opens with some zeromq library. vpnservice
> > >>> defines it's port with "static final String" in java and opens with
> > something thrift.
> > >>>
> > >>>> If so we could build a report of potential port conflicts between
> > projects.
> > >>>>
> > >>>> Or maybe build into the controller some sort of port service that
> > allows projects to reserve ports and if
> > >>>> multiple projects request the same ports it can dump the info to log.
> > >>>
> > >>>
> > >>> I don't know how hard/feasible this would be, or if it could even be
> > policed, but maybe...
> > >>>
> > >>> JamO
> > >>>
> > >>>> Regards, Thanh
> > >>>>
> > >>>> On 23 March 2016 at 14:16, Jamo Luhrsen <jluhrsen@... <mailto:
> > jluhrsen@...>> wrote:
> > >>>>
> > >>>> I think I found the issue for this.
> > >>>>
> > >>>> netide [0] and vpnservice [1] both want to use port 6644.
> > >>>>
> > >>>> If vpnservice is loaded first, when netide is then installed it will
> > fail to bind to that port.  However the
> > >>>> BindException is not caught and the library used to do the bind ends
> > up printing to the karaf console.  I filed a
> > >>>> bug [2] for netide to catch this and at least throw it to karaf.log
> > instead of the console.
> > >>>>
> > >>>> It seems that vpnservice does catch this condition and acknowledges
> > so in karaf.log, but it's not noted as a
> > >>>> TTransportException.  I *think* this is a problem right, and makes
> > the two features incompatible.  For this, I
> > >>>> filed another bug [3].  I gave that bug to vpnservice, just to be
> > fair :) It may need to be moved.
> > >>>>
> > >>>> We do track the ports projects use here [4], and I've updated it to
> > note the conflict.
> > >>>>
> > >>>> Why this is seemingly only showing in distributions built by
> > autorelease is still up for question, but my guess
> > >>>> is that the ordering of feature install is consistently different in
> > those distributions making vpnservice
> > >>>> install first.  The problem is still there in our snapshot distros if
> > you reproduce manually.  But, installing
> > >>>> automatically from featuresBoot it seems that netide must be getting
> > installed first.
> > >>>>
> > >>>> There could be other issues like this in the wild, but I can't think
> > of any good way to hunt them down.  We
> > >>>> really need projects to stay in sync with ports they are opening.
> > >>>>
> > >>>> Thanks, JamO
> > >>>>
> > >>>>
> > >>>> [0]
> > https://github.com/opendaylight/netide/blob/master/config/src/main/resources/initial/43-netide.xml#L24
> > [1]
> > >>>>
> > https://github.com/opendaylight/vpnservice/blob/master/bgpmanager/bgpmanager-impl/src/main/java/org/opendaylight/bgpmanager/BgpConfigurationManager.java#L69
> > >>>>
> > >>>>
> > > [2] https://bugs.opendaylight.org/show_bug.cgi?id=5597
> > >>>> [3] https://bugs.opendaylight.org/show_bug.cgi?id=5598 [4]
> > https://wiki.opendaylight.org/view/Ports#Ports
> > >>>>
> > >>>> On 03/18/2016 03:24 PM, Jamo Luhrsen wrote:
> > >>>>> Another odd thing we are facing with the autorelease is in our
> > distribution-deploy [0] job.  This job is
> > >>>>> failing with autorelease bits because it gets a BindException on the
> > karaf console (note: it does not come in
> > >>>>> karaf.log).   this is not coming in our snapshot distros.  Another
> > oddity is that I'm only seeing it if I'm
> > >>>>> loading the features (*all* the projects features) by placing it in
> > featuresBoot.  If I load them directly with
> > >>>>> "feature:install" in the karaf console, we do not see the
> > BindException.
> > >>>>>
> > >>>>> It's worrisome because the distributions we release are starting to
> > feel different than the ones we work with
> > >>>>> and continuously test with the snapshot builds.  This is in
> > reference to the other recent problem where our SR1
> > >>>>> distro would not even come up (not fixed).
> > >>>>>
> > >>>>> What can we do to figure this out?  I'm unsure right now.
> > >>>>>
> > >>>>> Thanks, JamO
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> [0]
> > https://jenkins.opendaylight.org/releng/view/autorelease/job/integra
> > tion-distribution-deploy-beryllium/
> > >>>>>
> > >>>>
> > >>>>
> > >>> _______________________________________________ integration-dev
> > mailing list
> > >>> integration-dev@...
> > https://lists.opendaylight.org/mailman/listinfo/integration-dev
> > >>
> > >> _______________________________________________ netide-dev mailing list
> > netide-dev@...
> > >> https://lists.opendaylight.org/mailman/listinfo/netide-dev
> > >> -------------------------------------------------------------- Intel
> > Research and Development Ireland Limited
> > >> Registered in Ireland Registered Office: Collinstown Industrial Park,
> > Leixlip, County Kildare Registered Number:
> > >> 308263
> > >>
> > >>
> > >> This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any
> > >> review or distribution by others is strictly prohibited. If you are not
> > the intended recipient, please contact the
> > >> sender and delete all copies.
> > >>
> >
> > _______________________________________________
> > integration-dev mailing list
> > integration-dev@...
> > https://lists.opendaylight.org/mailman/listinfo/integration-dev
> >
>

> _______________________________________________
> release mailing list
> release@...
> https://lists.opendaylight.org/mailman/listinfo/release
>