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