Good that you are willing to contribute. Nitrogen would be fine - but we will need to plan it.
On Fri, Mar 10, 2017 at 1:13 AM, Brady Allen Johnson < [email protected]> wrote: > Abhijit, > > Do you mean that the OFP already supports both the topology and the > inventory data models? If so, then what is left to do? I guess to kindly > nudge dependent projects to switch over, and remove the inventory data > model all together? Is there a migration guide of some sort explaining how > to switch from inventory to topology? > > Its probably not a good time to do this at this point in Carbon, so maybe > we should kick this off first thing in Nitrogen?? I would be willing to > help contribute. > > Thanks, > > Brady > > -----Original Message----- > *From*: Abhijit Kumbhare <[email protected] > <abhijit%20kumbhare%20%[email protected]%3e>> > *To*: Brady Johnson <[email protected] > <brady%20johnson%20%[email protected]%3e>> > *Cc*: "Brady Johnson, Ericsson" <[email protected] > <%22Brady%20Johnson,%20ericsson%22%20%[email protected]%3e>>, > [email protected] <openflowplugin-dev@lists. > opendaylight.org > <%[email protected]%22%20%[email protected]%3e>>, > sfc-dev opendaylight <[email protected] > <sfc-dev%20opendaylight%20%[email protected]%3e>>, Jozef > Bacigal <[email protected] > <jozef%20bacigal%20%[email protected]%3e>> > *Subject*: Re: [sfc-dev] [openflowplugin-dev] Status of removing usage of > deprecated inventory NodeId classes > *Date*: Thu, 9 Mar 2017 22:09:34 -0800 > > About: > > >> If we simultaneously support both the inventory and the topology > models (that is, listen on both, and do the same thing on the back end) for > a release cycle (or 2), then there will be less pressure for the dependent > projects to migrate, and there won't be that big-bang affect when switching > data models. > > That is already what has happened - not just for a release cycle or two > but for 4-5 releases. And there have always been higher priority items than > this every time - and especially has not been enough of a priority that > someone has come forward to implement it. > > On Thu, Mar 9, 2017 at 10:40 AM, Brady Johnson < > [email protected]> wrote: > > On the one hand that sounds like a reasonable approach, but on the other > hand, do we really need 2 different data models that are actually quite > similar? > > If we simultaneously support both the inventory and the topology models > (that is, listen on both, and do the same thing on the back end) for a > release cycle (or 2), then there will be less pressure for the dependent > projects to migrate, and there won't be that big-bang affect when switching > data models. > > I don't know enough about the internals of the OFP yet to know if my > approach is feasible or even naive, but I think the end result would be > much better for ODL overall. > > Regards, > > Brady > > On Thu, Mar 9, 2017, 18:55 Abhijit Kumbhare <[email protected]> wrote: > > This has been discussed in the past and we have not come to a good > agreement on this (not for the technical merits but because this is an area > that no one has decided to pick up as it has no priority for most of the > individuals/companies - and somehow we forgot this issue over the last few > releases). Hence I suggest we go back to Anil Vishnoi's suggestion in this > thread: > > https://lists.opendaylight.org/pipermail/openflowplugin-dev/ > 2016-May/005003.html > > The suggestion was the following: > > ========================= > > Inventory-model is only used by openflowplugin project only. So as an > alternative > we should move the inventory yang model from controller project to the > openflowplugin project and contain it as an internal project model and > not general inventory model for the other projects. This way it becomes an > OpenFlow plugin model alone - and not an overall OpenDaylight model. Also > undeprecate it. > > This will require some change by the dependent projects (some > modifications in the dependency declaration in the pom files) - however > it will be less change than a complete migration to the topology model. > ========================= > Since we are at M4 for all the projects - for now we may have 2 options: > Option 1) keep things as-is & follow up in Nitrogen > Option 2) Make the minor change proposed by Anil - and require all the > projects to change. > > For now my suggestion is option 1. > > > On Wed, Mar 8, 2017 at 10:42 PM, Brady Allen Johnson < > [email protected]> wrote: > > > > Im not sure how feasible this would be, but there would be less impact on > downstream projects if the OpenflowPlugin first supported listening to both > the deprecated inventory data store and to the newer topology data store. > That way downstream projects could migrate to the newer topology data > store, and once they're all migrated, the OpenflowPlugin could stop > supporting the deprecated inventory data store. This way no downstream > projects would be impacted when the OpenflowPlugin switches over. > > Regards, > > Brady > > > -----Original Message----- > *From*: Jozef Bacigál <[email protected] > <jozef%20%3d%3fiso-8859-1%3fq%3fbacig%3de1l%3f%3d%20%[email protected]%3e> > > > *To*: Brady Allen Johnson <[email protected] > <brady%20allen%20johnson%20%[email protected]%3e>>, > [email protected] <[email protected] > daylight.org > <%[email protected]%22%20%[email protected]%3e>>, > [email protected] <[email protected] > <%[email protected]%22%20%[email protected]%3e> > > > *Subject*: Re: [openflowplugin-dev] Status of removing usage of > deprecated inventory NodeId classes > *Date*: Wed, 8 Mar 2017 16:28:52 +0000 > > Tomorrow we got project community meeting, we will let you know about > dates. > > > Jozef > ------------------------------ > *Od:* Brady Allen Johnson <[email protected]> > *Odoslané:* 8. marca 2017 15:42 > *Komu:* [email protected]; > [email protected] > *Predmet:* [openflowplugin-dev] Status of removing usage of deprecated > inventory NodeId classes > > > We would like to remove the usage of the deprecated inventory NodeId and > related classes from SFC, but probably wont be able to until the > OpenflowPlugin removes them. > > import org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev1 > 30819.NodeId > import org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev1 > 30819.NodeConnectorId; > > What are the current plans in the OpenflowPlugin for removing them? > > Thanks, > > Brady > > > _______________________________________________ > > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > > > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
