Re: [openstack-dev] [heat] [CustomResource] LifeCycle methods flow
Thanks, Zane. I do understand the mistake I made (too much dependency on ctags). I am getting what you're pointing out. In face inside my _resolve_attribute, I should have return self.properties['value'] instead of depending on the cached value. I wanted to understand if it is OK to cache value in any of such resource. And your explanation is making sense. Thanks a lot. --pradip On Thu, Nov 27, 2014 at 4:05 AM, Zane Bitter wrote: > On 26/11/14 05:20, Pradip Mukhopadhyay wrote: > >> Hello, >> >> >> >> Any pointer (document and/or code pointer) related to how the different >> overridden methods are getting called when a custom resource is getting >> deployed in the heat stack? >> >> >> Basically just tried to annotate the h-eng log on a simple, >> very-first-attempt 'hello world' resource. Noticed the log is something >> like: >> >> 2014-11-26 15:38:30.251 INFO heat.engine.plugins.helloworld [-] >> [pradipm]:Inside handle_create >> 2014-11-26 15:38:30.257 INFO heat.engine.plugins.helloworld [-] >> [pradipm]:Inside _set_param_values >> 2014-11-26 15:38:31.259 INFO heat.engine.plugins.helloworld [-] >> [pradipm]:Inside check_create_complete >> 2014-11-26 15:38:44.227 INFO heat.engine.plugins.helloworld >> [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside >> HelloWorld ctor >> 2014-11-26 15:38:44.234 INFO heat.engine.plugins.helloworld >> [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside >> _resolve_attribute >> >> >> >> >> The constructor (ctor) is getting called in the flow after the >> create-resource. So though understanding the flow would help. >> > > That's... surprising. I suspect it isn't the same object though. > > def __init__(self, controller, deserializer, serializer=None): >> > > BTW that isn't the signature for Resource.__init__. It's > > def __init__(self, name, definition, stack): > > In any event, whatever you're trying to do with self._data_value is > probably not something you should be doing. Resource plugins are > essentially stateless beyond what is explicitly stored in the database > (stuff like resource_id_set()). If you really need to cache a value like > that, store it in the ResourceData table (although I consider this > something of an anti-pattern). > > Basically it's legit for every operation to use a brand new copy of the > object that doesn't contain any runtime state you may have manipulated on a > previous incarnation of the object. > > cheers, > Zane. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [CustomResource] LifeCycle methods flow
On 26/11/14 05:20, Pradip Mukhopadhyay wrote: Hello, Any pointer (document and/or code pointer) related to how the different overridden methods are getting called when a custom resource is getting deployed in the heat stack? Basically just tried to annotate the h-eng log on a simple, very-first-attempt 'hello world' resource. Noticed the log is something like: 2014-11-26 15:38:30.251 INFO heat.engine.plugins.helloworld [-] [pradipm]:Inside handle_create 2014-11-26 15:38:30.257 INFO heat.engine.plugins.helloworld [-] [pradipm]:Inside _set_param_values 2014-11-26 15:38:31.259 INFO heat.engine.plugins.helloworld [-] [pradipm]:Inside check_create_complete 2014-11-26 15:38:44.227 INFO heat.engine.plugins.helloworld [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside HelloWorld ctor 2014-11-26 15:38:44.234 INFO heat.engine.plugins.helloworld [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside _resolve_attribute The constructor (ctor) is getting called in the flow after the create-resource. So though understanding the flow would help. That's... surprising. I suspect it isn't the same object though. def __init__(self, controller, deserializer, serializer=None): BTW that isn't the signature for Resource.__init__. It's def __init__(self, name, definition, stack): In any event, whatever you're trying to do with self._data_value is probably not something you should be doing. Resource plugins are essentially stateless beyond what is explicitly stored in the database (stuff like resource_id_set()). If you really need to cache a value like that, store it in the ResourceData table (although I consider this something of an anti-pattern). Basically it's legit for every operation to use a brand new copy of the object that doesn't contain any runtime state you may have manipulated on a previous incarnation of the object. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [CustomResource] LifeCycle methods flow
Thanks Pavlo.
One particular thing I did not comprehend is:
Suppose my resource code is something like:
class HelloWorld(resource.Resource):
def __init__(self, controller, deserializer, serializer=None):
LOG.info("[pradipm]:Inside HelloWorld ctor");
resource.Resource.__init__(self, controller, deserializer,
serializer)
## Re-setting the data value
self._data_value = self.properties['value']
properties_schema = {
'value': properties.Schema(
properties.Schema.STRING,
_('foo')
),
}
attributes_schema = {
'data': _('the data')
}
...
def _set_param_values(self):
LOG.info("[pradipm]:Inside _set_param_values")
self._data_value = self.properties['value']
return
def handle_create(self):
LOG.info("[pradipm]:Inside handle_create")
container_id = 1 ## some arbitrary id
self.resource_id_set(container_id)
self._set_param_values()
return container_id
I am seeing the constructor is getting called *later on* compared to the
handle_create -> check_create_complete etc.
Is that a *defined* behavior? Or it is purely *temporal* (such that in some
cases the ctor might be called early also).
Thanks,
Pradip
On Wed, Nov 26, 2014 at 4:05 PM, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:
> Pradip,
>
> https://github.com/openstack/heat/blob/master/heat/engine/resource.py#L473
>
> Basically, it calls handle_create that might return some data, yields, and
> than keeps calling check_create_complete with that data returned by
> handle_create, yielding control in-between, until check_create_complete
> returns True.
>
> Best regards,
> Pavlo Shchelokovskyy.
>
> On Wed, Nov 26, 2014 at 12:20 PM, Pradip Mukhopadhyay <
> pradip.inte...@gmail.com> wrote:
>
>> Hello,
>>
>>
>>
>> Any pointer (document and/or code pointer) related to how the different
>> overridden methods are getting called when a custom resource is getting
>> deployed in the heat stack?
>>
>>
>> Basically just tried to annotate the h-eng log on a simple,
>> very-first-attempt 'hello world' resource. Noticed the log is something
>> like:
>>
>> 2014-11-26 15:38:30.251 INFO heat.engine.plugins.helloworld [-]
>> [pradipm]:Inside handle_create
>> 2014-11-26 15:38:30.257 INFO heat.engine.plugins.helloworld [-]
>> [pradipm]:Inside _set_param_values
>> 2014-11-26 15:38:31.259 INFO heat.engine.plugins.helloworld [-]
>> [pradipm]:Inside check_create_complete
>> 2014-11-26 15:38:44.227 INFO heat.engine.plugins.helloworld
>> [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside
>> HelloWorld ctor
>> 2014-11-26 15:38:44.234 INFO heat.engine.plugins.helloworld
>> [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside
>> _resolve_attribute
>>
>>
>>
>>
>> The constructor (ctor) is getting called in the flow after the
>> create-resource. So though understanding the flow would help.
>>
>>
>>
>> Thanks in advance,
>> Pradip
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Pavlo Shchelokovskyy
> Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [CustomResource] LifeCycle methods flow
Pradip, https://github.com/openstack/heat/blob/master/heat/engine/resource.py#L473 Basically, it calls handle_create that might return some data, yields, and than keeps calling check_create_complete with that data returned by handle_create, yielding control in-between, until check_create_complete returns True. Best regards, Pavlo Shchelokovskyy. On Wed, Nov 26, 2014 at 12:20 PM, Pradip Mukhopadhyay < pradip.inte...@gmail.com> wrote: > Hello, > > > > Any pointer (document and/or code pointer) related to how the different > overridden methods are getting called when a custom resource is getting > deployed in the heat stack? > > > Basically just tried to annotate the h-eng log on a simple, > very-first-attempt 'hello world' resource. Noticed the log is something > like: > > 2014-11-26 15:38:30.251 INFO heat.engine.plugins.helloworld [-] > [pradipm]:Inside handle_create > 2014-11-26 15:38:30.257 INFO heat.engine.plugins.helloworld [-] > [pradipm]:Inside _set_param_values > 2014-11-26 15:38:31.259 INFO heat.engine.plugins.helloworld [-] > [pradipm]:Inside check_create_complete > 2014-11-26 15:38:44.227 INFO heat.engine.plugins.helloworld > [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside > HelloWorld ctor > 2014-11-26 15:38:44.234 INFO heat.engine.plugins.helloworld > [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside > _resolve_attribute > > > > > The constructor (ctor) is getting called in the flow after the > create-resource. So though understanding the flow would help. > > > > Thanks in advance, > Pradip > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] [CustomResource] LifeCycle methods flow
Hello, Any pointer (document and/or code pointer) related to how the different overridden methods are getting called when a custom resource is getting deployed in the heat stack? Basically just tried to annotate the h-eng log on a simple, very-first-attempt 'hello world' resource. Noticed the log is something like: 2014-11-26 15:38:30.251 INFO heat.engine.plugins.helloworld [-] [pradipm]:Inside handle_create 2014-11-26 15:38:30.257 INFO heat.engine.plugins.helloworld [-] [pradipm]:Inside _set_param_values 2014-11-26 15:38:31.259 INFO heat.engine.plugins.helloworld [-] [pradipm]:Inside check_create_complete 2014-11-26 15:38:44.227 INFO heat.engine.plugins.helloworld [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside HelloWorld ctor 2014-11-26 15:38:44.234 INFO heat.engine.plugins.helloworld [req-9979deb9-f911-4df4-bdf8-ecc3609f054b None demo] [pradipm]:Inside _resolve_attribute The constructor (ctor) is getting called in the flow after the create-resource. So though understanding the flow would help. Thanks in advance, Pradip ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
