I think the reasons for retiring the inventory model are: 1) it is not based in any standard model (e.g. IETF) and 2) current topology IETF topology models allow for inventory information by augmenting node information. This consolidation will also avoid data duplication inventory-topology.
BR/Luis > On May 12, 2016, at 7:44 AM, FREEMAN, BRIAN D <[email protected]> wrote: > > In the end having two models cuts capacity of a node by some measurable > amount. > > I like having backwards compatible API’s but supporting two models is just > not sustainable. > > It is interesting that in a service provider context outside of ODL, topology > is usually a derivation of inventory or multiple inventory data stores. > Usually a small subset of the inventory data to show relationships that will > assist in trouble shooting or path analysis that is quicker to parse/traverse > than the inventory model. We may display or walk the topology but its read > only. All read/write is against the inventory. Flows/Paths on top of > devices/ports/VNFs have a topology aspect but in the end there is an > inventory of flows/paths usually keyed by some device or device-list or > portlist or ip-hop list etc. > > Not sure this wall of text helps or is even pertinent but perhaps its > interesting J > > Brian > > > From: [email protected] > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Colin Dixon > Sent: Thursday, May 12, 2016 10:23 AM > To: Anil Vishnoi > Cc: <[email protected] <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]>; Release > Subject: Re: [OpenDaylight Discuss] Important: Inventory model migration > proposal (instead of inventory to topology model migration) > > The key advantage to doing away with two models is to make writing code that > deals with both the topology and inventory models (which is nearly all code > for OpenFlow) in Java reasonable to write. As it stands, you can only import > one "Node" class in java via anything other than it's full class name with > package and that results in really, really annoying code. > > Also, the constant translation back and forth is a recipe for errors in > program logic. > > --Colin > > > On Mon, May 9, 2016 at 11:26 PM, Anil Vishnoi <[email protected] > <mailto:[email protected]>> wrote: > > > On Mon, May 9, 2016 at 2:42 PM, Robert Varga <[email protected] <mailto:[email protected]>> > wrote: > On 05/02/2016 11:52 PM, Abhijit Kumbhare wrote: > > Hi folks, > > > > [snip] > > > 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. > > *If you have any thoughts about the change - please provide your thoughts*. > > > > We inside of OpenFlow Plugin project like this change (as opposed to the > > inventory to topology model migration change for which there were no > > volunteers due to the effort and lack of obvious benefits). > > I have to disagree on the 'lack of benefits' part. Having aligned base > models is critical for end user experience. The topology model is > implemented by multiple SB plugins to expose exactly the same semantics > as the inventory model. > > From modeling perspective, the inventory model is a strict subset of > concepts expressed in the topology model. > > Keeping two models for the same thing is pure overhead from maintenance > and interoperability point of view. > I don't really see any major maintenance and interoperability issues and i > believe once we move inventory model to openflowplugin, we avoid any future > issues as well. > If i weigh the benefit of removing these models and disrupting the downstream > projects Vs containing it within plugin with minimal disruption, i don't > really see any value in removing inventory models. > > The inventory model must be eliminated if we ever hope to have any sort > of consistence across SB plugins. This has been discussed and agreed > multiple times, can we please stick to the plan? > > I am not sure we can achieve 100% consistency across SB plugin, because IMO > we can't force any southbound plugin from using these inventory models in > future as well. > About sticking to the plan, sure we can, i am just throwing alternate > options, where we can manage this situation without doing any major > disruption and i don't really see any major issue with it. > > > > > > Since there is a proposal to eliminate the OFP version-agnostic model > (which is tied to topology via the new plugin), I think it would be very > logical to attach the OFJ models to topology as a replacement and simple > gradually desupport the inventory model -- old stuff works as long as > old models do. > This looks like a middle path, but i believe it's bit long term solution, > but make sense to me. > > Thanks, > Robert > > > _______________________________________________ > Discuss mailing list > [email protected] <mailto:[email protected]> > https://lists.opendaylight.org/mailman/listinfo/discuss > <https://lists.opendaylight.org/mailman/listinfo/discuss> > > > > -- > Thanks > Anil > > _______________________________________________ > Discuss mailing list > [email protected] <mailto:[email protected]> > https://lists.opendaylight.org/mailman/listinfo/discuss > <https://lists.opendaylight.org/mailman/listinfo/discuss> > > _______________________________________________ > release mailing list > [email protected] <mailto:[email protected]> > https://lists.opendaylight.org/mailman/listinfo/release > <https://lists.opendaylight.org/mailman/listinfo/release>
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
