[openstack-dev] [heat] Backup resources and properties in the delete-path
Steve Baker
sbaker at redhat.com
Thu Sep 10 21:44:30 UTC 2015
On 11/09/15 05:02, Zane Bitter wrote:
> On 10/09/15 12:53, Steven Hardy wrote:
>> Hi all,
>>
>> So, I've been battling with $subject for the last few days ref [1][2].
>>
>> The problem I have is that out TestResource references several
>> properties
>> in the delete (check_delete_complete) path[4], which it turns out
>> doesn't
>> work very well if those properties refer to parameters via get_param,
>> and
>> the parameter in the template is added/removed between updates which
>> fail[3].
>>
>> Essentially, the confusing dance we do on update with backup stacks and
>> backup resources bites us, because the backed-up resource ends up
>> referring
>> to a parameter which doesn't exist (either in
>> stack.Stack._delete_backup_stack on stack-delete, or in
>> update.StackUpdate._remove_backup_resource on stack-update.)
>>
>> As far as I can tell, referencing properties in the delete path is
>> the main
>> problem here, and it's something we don't do at all AFAICS in any other
>> resources - the normal pattern is only to refer to the resource_id in
>> the
>> delete path, and possibly the resource_data (which will work OK after
>> [5]
>> lands)
>>
>> So the question is, is it *ever* valid to reference self.properties
>> in the delete path?
>
> I think it's fine to say 'no'.
>
I know of a case where this is not no.
For a SoftwareDeployment which has work to do during DELETE the
properties need to be accessed to get the config containing the DELETE
work. There were convergence functional tests failing because the
properties were not populated during delete:
https://bugs.launchpad.net/heat/+bug/1483946
>> If the answer is no, can we fix TestResource by e.g
>> storing the properties in resource_data instead?
>
> They're already stored as self._stored_properties_data; you could just
> reference that instead. (The 'right' way would probably be to use
> "self.frozen_definition().properties(self.properties_schema,
> self.context)", but this is a test resource we're talking about.)
>
>> If we do expect to allow/support refering to properties in the delete
>> path,
>> the question becomes how to we make it work with the backup resource
>> update
>> mangling we do atm? I've posted a hacky workaround for the delete
>> path in
>> [2], but I don't yet have a solution for the failure on update in
>> _remove_backup_resource, is it worth expending the effort to work
>> that out
>> or is TestResource basically doing the wrong thing?
>>
>> Any ideas much appreciated, as I'd like to clarify the best path forward
>> before burning a bunch more time on this :)
>>
>> Thanks!
>>
>> Steve
>>
>> [1] https://review.openstack.org/#/c/205754/
>> [2] https://review.openstack.org/#/c/222176/
>> [3] https://bugs.launchpad.net/heat/+bug/1494260
>> [4]
>> https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/heat/test_resource.py#L209
>> [5] https://review.openstack.org/#/c/220986/
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list