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] > <%[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.rev130819.NodeId > import > org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.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
