On 26/11/14 05:20, Pradip Mukhopadhyay wrote:

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

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

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.


OpenStack-dev mailing list

Reply via email to