Open Stack

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 <zbitter at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141127/edef10c3/attachment.html>