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.* > 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.* > Thanks, > Alexis > > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
