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> 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
> <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> 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
> 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