Re: [controller-dev] Re-configuration of Blueprint modules by RESTCONF requests
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) 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:
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) 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
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) 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:
>
>
>
> *
> *
> binding-class="org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.onem2mpluginloader.config.rev161021.PluginLoadersConfigs"*
>
> *list-key-value="LoaderInstance1">*
>
> **
>
> * *
>
>
>
> *
> *
> class="org.opendaylight.iotdm.onem2mpluginloader.impl.Onem2mPluginLoaderProvider"*
>
> *init-method="init" destroy-method="close">*
>
> **
>
> **
>
> * *
>
>
>
> *
> *
> binding-class="org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.onem2mpluginloader.config.rev161021.PluginLoadersConfigs"*
>
> *list-key-value="LoaderInstance2">*
>
> **
>
> * *
>
>
>
> *
> *
> class="org.opendaylight.iotdm.onem2mpluginloader.impl.Onem2mPluginLoaderProvider"*
>
> *init-method="init" destroy-method="close">*
>
> **
>
> **
>
> * *
>
>
>
>
>
> 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) 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 configura
Re: [controller-dev] Re-configuration of Blueprint modules by RESTCONF requests
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:
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) 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
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) 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
