> 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] > <mailto:[email protected]>> wrote: > >> On May 13, 2016, at 10:29 AM, Tom Pantelis <[email protected] >> <mailto:[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?. >> 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. > > Thanks, > Alexis > > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
