Yes, exactly, I wanted to create the new Onem2mPluginLoaderProvider dynamically and now I see why it doesn’t work this way. Thank you very much for answering my questions. Tomas From: Tom Pantelis [mailto:tompante...@gmail.com] Sent: Monday, October 24, 2016 2:35 PM To: Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco) Cc: controller-dev@lists.opendaylight.org; Lionel Florit (lflorit); Juraj Kosmel -X (jkosmel - PANTHEON TECHNOLOGIES at Cisco); John Burns (johnburn) Subject: Re: [controller-dev] Re-configuration of Blueprint modules by RESTCONF requests
I assume you expected a third instance of Onem2mPluginLoaderProvider to be dynamically created? It doesn't work that way. The clustered-app-config just obtains yang data from the data store - it does not create business logic beans - notice that you do that separately via "loader1", "loader2". Perhaps clustered-app-config could be extended to do so for list configs. On Mon, Oct 24, 2016 at 8:20 AM, Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco) <tjanc...@cisco.com<mailto:tjanc...@cisco.com>> wrote: Hi Tom, Thanks for clarification. In case of the instantiation of the new instance of component (I’ve probably used “module” incorrectly) I mean this scenario: Let’s consider this yang model for the list configuration: list plugin-loaders-configs { key "loader-instance-name"; leaf loader-instance-name { type string; } leaf some-string-param { type string; mandatory true; } } } And this is the default configuration from the Blueprint XML: <odl:clustered-app-config id="listConfig1" binding-class="org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.onem2mpluginloader.config.rev161021.PluginLoadersConfigs" list-key-value="LoaderInstance1"> <odl:default-config><![CDATA[ <plugin-loaders-configs xmlns="urn:opendaylight:params:xml:ns:yang:onem2mpluginloader:config"> <loader-instance-name>LoaderInstance1</loader-instance-name> <some-string-param>TestString1</some-string-param> </plugin-loaders-configs> ]]></odl:default-config> </odl:clustered-app-config> <bean id="loader1" class="org.opendaylight.iotdm.onem2mpluginloader.impl.Onem2mPluginLoaderProvider" init-method="init" destroy-method="close"> <argument ref="dataBroker" /> <argument ref="listConfig1" /> </bean> <odl:clustered-app-config id="listConfig2" binding-class="org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.onem2mpluginloader.config.rev161021.PluginLoadersConfigs" list-key-value="LoaderInstance2"> <odl:default-config><![CDATA[ <plugin-loaders-configs xmlns="urn:opendaylight:params:xml:ns:yang:onem2mpluginloader:config"> <loader-instance-name>LoaderInstance2</loader-instance-name> <some-string-param>TestString2</some-string-param> </plugin-loaders-configs> ]]></odl:default-config> </odl:clustered-app-config> <bean id="loader2" class="org.opendaylight.iotdm.onem2mpluginloader.impl.Onem2mPluginLoaderProvider" init-method="init" destroy-method="close"> <argument ref="dataBroker" /> <argument ref="listConfig2" /> </bean> So the default configuration will cause instantiation of two instances with names LoaderInstance1 and LoaderInstance2 and I would expect that I can add third component instance with name LoaderInstanceNew during runtime by RESTCONF request like this: PUT (or POST) http://localhost:8181/restconf/config/onem2m-plugin-loader-config:plugin-loaders-configs/LoaderInstanceNew { "plugin-loaders-configs": [ { "loader-instance-name": "LoaderInstanceNew", "some-string-param": "TestStringNew" } ] } Although I’ve received response with 200OK and the configuration for LoaderInstanceNew has been stored in the data store the new component instance has not been created. Thanks, Tomas From: Tom Pantelis [mailto:tompante...@gmail.com<mailto:tompante...@gmail.com>] Sent: Monday, October 24, 2016 1:59 PM To: Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco) Cc: controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>; Lionel Florit (lflorit); Juraj Kosmel -X (jkosmel - PANTHEON TECHNOLOGIES at Cisco) Subject: Re: [controller-dev] Re-configuration of Blueprint modules by RESTCONF requests On Mon, Oct 24, 2016 at 4:20 AM, Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco) <tjanc...@cisco.com<mailto:tjanc...@cisco.com>> wrote: Hi Guys, I’m testing possibilities of the configuration of modules using Blueprint instead of CSS. I’ve got troubles with retrieving default configuration and creating new instances of modules. For the first one I’ve opened this bug: https://bugs.opendaylight.org/show_bug.cgi?id=7012 Unfortunately, the default configuration can't be obtained currently via restconf. For 1, yang default values are only available via the binding interface (restconf is BI) and 2, the default XML config isn't stored in the data store. We need to utilize the new sharding API, when it's ready, to get the default data. But I’m not sure about the second one. RESTCONF POST method doesn’t work for the instantiation of module, I’ve tested also PUT method and it resulted with 200OK and the new configuration of the new instance has been stored in the data store (I verified with GET) but new instance of module has not been started. Should the module instantiation through RESTCONF work please ? Is it on your TODO list ? I'm not clear on what the issue is here. What do you mean by "module instantiation through RESTCONF"? Can you elaborate with a detailed example? Thank you for your answers in advance, Tomas I’ve tested POST and PUT methods with this URL body: http://localhost:8181/restconf/config/onem2m-plugin-loader-config:plugin-loaders-configs/LoaderInstanceNew { "plugin-loaders-configs": [ { "loader-instance-name": "LoaderInstanceNew", "some-string-param": "TestStringNew" } ] } _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
