<div dir="ltr"><div><div><div><div>Thanks, Zane.<br><br></div>I do understand the mistake I made (too much dependency on ctags). <br><br></div>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.<br><br></div>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.<br><br><br></div>--pradip<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 27, 2014 at 4:05 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 26/11/14 05:20, Pradip Mukhopadhyay wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
<br>
<br>
Any pointer (document and/or code pointer) related to how the different<br>
overridden methods are getting called when a custom resource is getting<br>
deployed in the heat stack?<br>
<br>
<br>
Basically just tried to annotate the h-eng log on a simple,<br>
very-first-attempt 'hello world' resource. Noticed the log is something<br>
like:<br>
<br>
2014-11-26 15:38:30.251 INFO heat.engine.plugins.helloworld [-]<br>
[pradipm]:Inside handle_create<br>
2014-11-26 15:38:30.257 INFO heat.engine.plugins.helloworld [-]<br>
[pradipm]:Inside _set_param_values<br>
2014-11-26 15:38:31.259 INFO heat.engine.plugins.helloworld [-]<br>
[pradipm]:Inside check_create_complete<br>
2014-11-26 15:38:44.227 INFO heat.engine.plugins.helloworld<br>
[req-9979deb9-f911-4df4-bdf8-<u></u>ecc3609f054b None demo] [pradipm]:Inside<br>
HelloWorld ctor<br>
2014-11-26 15:38:44.234 INFO heat.engine.plugins.helloworld<br>
[req-9979deb9-f911-4df4-bdf8-<u></u>ecc3609f054b None demo] [pradipm]:Inside<br>
_resolve_attribute<br>
<br>
<br>
<br>
<br>
The constructor (ctor) is getting called in the flow after the<br>
create-resource. So though understanding the flow would help.<br>
</blockquote>
<br></div></div>
That's... surprising. I suspect it isn't the same object though.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    def __init__(self, controller, deserializer, serializer=None):<br>
</blockquote>
<br></span>
BTW that isn't the signature for Resource.__init__. It's<br>
<br>
  def __init__(self, name, definition, stack):<br>
<br>
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).<br>
<br>
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.<br>
<br>
cheers,<br>
Zane.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>