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]
Sent: Monday, October 24, 2016 1:59 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)
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
  • [controller-d... Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)
    • Re: [con... Tom Pantelis
      • Re: ... Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)
        • ... Tom Pantelis
          • ... Tomas Janciga -X (tjanciga - PANTHEON TECHNOLOGIES at Cisco)

Reply via email to