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:[email protected]]
Sent: Monday, October 24, 2016 1:59 PM
To: Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)
Cc: [email protected]; 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) <[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________
controller-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/controller-dev
