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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
