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]<mailto:abhijit%20kumbhare%20%[email protected]%3e>> To: Brady Johnson <[email protected]<mailto:brady%20johnson%20%[email protected]%3e>> Cc: "Brady Johnson, Ericsson" <[email protected]<mailto:%22Brady%20Johnson,%20ericsson%22%20%[email protected]%3e>>, [email protected] <[email protected]<mailto:%[email protected]%22%20%[email protected]%3e>>, sfc-dev opendaylight <[email protected]<mailto:sfc-dev%20opendaylight%20%[email protected]%3e>>, Jozef Bacigal <[email protected]<mailto: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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:jozef%20%3d%3fiso-8859-1%3fq%3fbacig%3de1l%3f%3d%20%[email protected]%3e>> To: Brady Allen Johnson <[email protected]<mailto:brady%20allen%20johnson%20%[email protected]%3e>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:%[email protected]%22%20%[email protected]%3e>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:%[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]<mailto:[email protected]>> Odoslané: 8. marca 2017 15:42 Komu: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev _______________________________________________ sfc-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
