On Fri, May 13, 2016 at 11:55 AM, Alexis de Talhouët < [email protected]> wrote:
> > On May 13, 2016, at 11:18 AM, Tom Pantelis <[email protected]> wrote: > > > > On Fri, May 13, 2016 at 10:41 AM, Alexis de Talhouët < > [email protected]> wrote: > >> >> On May 13, 2016, at 10:29 AM, Tom Pantelis <[email protected]> wrote: >> >> We can remove corresponding config XML files and remove them from the >> features. We can also go a step further and remove the config yang and >> Module classes altogether. The only potential issue with this is if an >> etc/opendaylight/current/controller.currentconfig.xml exists on upgrade. >> For those that aren't aware of this file it is created when a config is >> pushed via the restconf controller-config yang-ext:mount loopback (most >> commonly when a netconf connector mount is pushed). The CSS merges all >> config files under etc/opendaylight/karaf >> into controller.currentconfig.xml and uses this file to load configs on >> restart from then on. Therefore if this file exists on upgrade, it would >> contain the XML for the removed config yang files and would try to push >> them but fail. >> >> >> This make complete sense to me, although, and keep me honest, doing so we >> would slowly wipe out config system injection, right? >> > > *[TP] yes* > > >> This is really fine but wrt config system, I though we were keeping both >> along the way. >> > > *[TP] We don't want both blueprint and the Module classes instantiating > the business logic - we'd have duplicate instances. The approach I've taken > is to essentially make the Module classes no-ops wrt instantiating the > business logic. If the Module does not provide a service that can be > injected into other modules then it's really a no-op (eg > https://git.opendaylight.org/gerrit/#/c/38831/1/applications/forwardingrules-manager/src/main/java/org/opendaylight/openflowplugin/applications/config/yang/forwardingrules_manager/ForwardingRulesManagerModule.java > <https://git.opendaylight.org/gerrit/#/c/38831/1/applications/forwardingrules-manager/src/main/java/org/opendaylight/openflowplugin/applications/config/yang/forwardingrules_manager/ForwardingRulesManagerModule.java>). > But if the module provides a service then I obtain the service instance > that was created via blueprint and return that from createInstance (eg > https://git.opendaylight.org/gerrit/#/c/38646/1/openflowplugin-impl/src/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/params/xml/ns/yang/config/openflow/plugin/impl/rev150327/OpenFlowProviderModule.java > <https://git.opendaylight.org/gerrit/#/c/38646/1/openflowplugin-impl/src/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/params/xml/ns/yang/config/openflow/plugin/impl/rev150327/OpenFlowProviderModule.java>). > Therefore any app/module using the service that hasn't been converted to > blueprint will continue work - it is none the wiser that the actual > instance was created via blueprint.* > > *This means that changes to the CSS config via restconf or manually > editing the config XML file are essentially ignored. I have put comments > in the config XML files indicating this. So the config yang and XML are > deprecated but remain for compatibility for downstream modules that haven't > been converted to blueprint. As I mentioned we need to do this for modules > that provide services but not for ones that don't, in fact this is another > reason for removing the config yang, ie if they're gone then users can't > try to change them.* > > > [AdT] I think I got it. Basically, if there is no wiring needed for a > given bundle, the yang/config file could be removed (as useless). Else it > would stay to benefit the createInstance through which the application > retrieve the services pulled in by blueprint?. > > [*TP] The wiring that was done via yang/config file is now done via blueprint so they are not needed for instantiation/wiring. The only reason to keep the yang/config file is for those that provide a service (ie via the <service> element in the config XML), and even then only if there's downstream consumers of that service still using the config system. So the service instance is provided via blueprint (via the OSGi registry) for **blueprint consumers and is also provided via the createInstance for CSS consumers (CSS uses JMX to store/obtain the service instances).* > the XML elements corresponding to the removed yang files would have to be >> removed. >> >> >> Maybe we can find a way to script this, to help folks doing upgrade. Then >> once ODL is blueprint enabled (so probably Carbon), upgrade would be >> transparent without any action required. >> >> *[TP] yeah it could be scripted, someone would have to contribute that of > course. Or just document it. Up till now we've essentially done neither :( > * > > *Blueprint will be enabled in Boron for openflow. Controller core is > already converted to blueprint. I plan to tackle a few other projects in > Boron but don't have cycles to convert all 40+ projects :) I'll leave that > up to those projects.* > > > [AdT] We (Inocybe) should be able to provide assistance here, and help > for both blueprint migration and script/documentation. But first I (we) > need to read the great wiki you’ve done to understand it fully. Then we > will start working on moving project to blueprint, with you > reviewing/supervising at the beginning :) > I’m already going through all projects to unified pom structure across > ODL, so I could add an extra step being migrate to blueprint. But as you > pointed out, this is time-consuming. > > *[TP] Cool. I can provide guidance and review. openflowplugin took some time b/c it has quite a few modules/apps - I think most others will be simpler (BGP/PCEP is quite large). * > > >> Thanks, >> Alexis >> >> >> > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
