In-line. On Mon, May 9, 2016 at 2:42 PM, Robert Varga <n...@hq.sk> 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. > Abhijit>> I mentioned "lack of obvious benefits" rather than "lack of benefits" :). > 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. > > 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? > Abhijit>> The biggest problem with this has been that no one seems to have warmed up enough to the idea to start working on it - especially in Boron. I myself will welcome it if there were folks working on it to make it happen. > > 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. > Abhijit>> I think what you are saying is - that we keep the inventory as-is in Boron (due to no one picking up the work); and merge this as part of cleanup of the OFP-OFJ models (assuming that proposal becomes a reality). This sounds an interesting idea - I have added it as a bullet to the proposal as a point of discussion. If this does not become a reality - then we can come back to Anil's proposal. > Thanks, > Robert > >
_______________________________________________ openflowplugin-dev mailing list openflowplugin-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
