I was looking for any existing 3 party lldp library that we can use, and the only one i found is from ONOS (and looks like that's pretty maintained). I think it's not really an option, but just want to share.
https://search.maven.org/#search%7Cga%7C1%7Clldp As sam mentioned, if we can eliminate the dependency of odlparent for library and push it as as third party library, i think it should be simplest solution. On Wed, Jul 26, 2017 at 12:32 PM, Vishal Thapar <vishal.tha...@ericsson.com> wrote: > This may work if liblldp is part of genius-api feature set. Is there any > Impl code in LLDP that could cause problems? > > > > Regards, > > Vishal. > > > > *From:* Sam Hague [mailto:sha...@redhat.com] > *Sent:* 26 July 2017 23:47 > *To:* Vishal Thapar <vishal.tha...@ericsson.com> > *Cc:* Colin Dixon <co...@colindixon.com>; Stephen Kitt <sk...@redhat.com>; > t...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; > rele...@lists.opendaylight.org; genius-...@lists.opendaylight.org > > *Subject:* Re: [controller-dev] [release] [OpenDaylight TSC] Moving lldp > code from controller > > > > > > > > On Wed, Jul 26, 2017 at 9:56 AM, Vishal Thapar <vishal.tha...@ericsson.com> > wrote: > > As one of the consumers, Genius would be ready to take it in. We’re > planning to discuss/vote-on this in tomorrow’s Genius meeting. Before we > put this up for vote in Genius, we’d like to know expectations from Genius > should we decide to host it. > > I thought this produced a cycle. openflowplugin uses liblldp and genius > uses openflowplugin. Or is that not a concern? > > > > Regards, > > Vishal. > > > > *From:* controller-dev-boun...@lists.opendaylight.org [mailto: > controller-dev-boun...@lists.opendaylight.org] *On Behalf Of *Colin Dixon > *Sent:* 26 July 2017 18:45 > *To:* Sam Hague <sha...@redhat.com>; Stephen Kitt <sk...@redhat.com> > *Cc:* t...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; > rele...@lists.opendaylight.org > *Subject:* Re: [controller-dev] [release] [OpenDaylight TSC] Moving lldp > code from controller > > > > Just to play devil's advocate, new projects for such things have a > significant set of additional overheads: > > > > * during releases, release engineering staff have to track it > > * added periodic merge jobs and integration jobs with spinup time that > adds more load to our infra > > * higher risk of abandonment by loss or committers > > > > I guess in this case, if we expect the project to basically only ever > release once and it's pulling in of order versions of ODL parent is either > OK or eliminated, that should mitigate the first two pretty significantly. > Note that we'd also likely need to make sure other projects pull it in and > test it in an automated fashion to avoid regressions. > > > > It still doesn't fix the risk of abandonment. > > > > --Colin > > > > On Fri, Jul 21, 2017 at 8:28 AM Sam Hague <sha...@redhat.com> wrote: > > On Fri, Jul 21, 2017 at 4:25 AM, Stephen Kitt <sk...@redhat.com> wrote: > > On Thu, 20 Jul 2017 14:35:59 -0400 > Tom Pantelis <tompante...@gmail.com> wrote: > > On Thu, Jul 20, 2017 at 1:41 PM, Robert Varga <n...@hq.sk> wrote: > > > since we would like to make some progress in the great controller > > > purge project, we need to decide what to do about liblldp. > [...] > > > > Do you think this really warrants a separate project? I recall > > mention of merging it into another project - would genius or > > infrautils fit? > > I think it does warrant a separate project, from a maintenance and > lifecycle perspective. liblldp is also quite different from all the > other projects in OpenDaylight, so merging it into another project > would just add a bunch of code to whatever target we pick, code that > the host project doesn’t really care about in all likelihood. > > I also wouldn’t want infrautils to end up being the dumping ground for > ODL... > > Of course this means a certain amount of bureaucracy, which is rather > unfortunate. Perhaps we can continue with the collapsed milestones and > lack of read-out requests for future development cycles ;-). > > Agreed, this seems best for projects like this. If we could create a > lightweight process such that the only real work is the initial work to get > liblldp into a project and building: approve it, make repo, setup jenkins > jobs, and artifacts pushed. From there it is on autopilot. It is > automatically include in the release if others are using it - so no > milestone readouts or other maintenance. Of course if there are breakages > then we need to fix them. But effectively, this becomes like a third-party > artifact. > > > > If we can get something like that together, I would volunteer to take > ownership (PTL and committer and a couple others) and get it into a project > and building. > > > Regards, > > Stephen > > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > _______________________________________________ > release mailing list > rele...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/release > > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > -- Thanks Anil
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
