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 <zbit...@redhat.com> 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
