Open Stack

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'.

> 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
>