Open Stack

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.