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] <openflowplugin-dev@lists. >> opendaylight.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. >> 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
