[openstack-dev] [Heat] Do we need to clean up resource_id after deletion?

Christopher Armstrong chris.armstrong at rackspace.com
Tue Nov 12 17:49:38 UTC 2013


On Tue, Nov 12, 2013 at 7:47 AM, Zane Bitter <zbitter at redhat.com> wrote:

> On 02/11/13 05:30, Clint Byrum wrote:
>
>> Excerpts from Christopher Armstrong's message of 2013-11-01 11:34:56
>> -0700:
>>
>>> Vijendar and I are trying to figure out if we need to set the resource_id
>>> of a resource to None when it's being deleted.
>>>
>>> This is done in a few resources, but not everywhere. To me it seems
>>> either
>>>
>>> a) redundant, since the resource is going to be deleted anyway (thus
>>> deleting the row in the DB that has the resource_id column)
>>> b) actively harmful to useful debuggability, since if the resource is
>>> soft-deleted, you'll not be able to find out what physical resource it
>>> represented before it's cleaned up.
>>>
>>> Is there some specific reason we should be calling resource_id_set(None)
>>> in
>>> a check_delete_complete method?
>>>
>>>
>> I've often wondered why some do it, and some don't.
>>
>> Seems to me that it should be done not inside each resource plugin but
>> in the generic resource handling code.
>>
>> However, I have not given this much thought. Perhaps others can provide
>> insight into why it has been done that way.
>>
>
> There was a time in the very early days of Heat development when deleting
> something that had already disappeared usually resulted in an error (i.e.
> we mostly weren't catching NotFound exceptions). I expect this habit dates
> from that era.
>
> I can't think of any reason we still need this, and I agree that it seems
> unhelpful for debugging.
>
> cheers,
> Zane.
>
>
Thanks Zane and others who have responded. My recent patch (now already
merged) won't delete the resource_id.


-- 
IRC: radix
Christopher Armstrong
Rackspace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131112/b171eb20/attachment.html>


More information about the OpenStack-dev mailing list