[openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

Zane Bitter zbitter at redhat.com
Tue Mar 8 17:26:53 UTC 2016


On 08/03/16 08:03, Johannes Grassler wrote:
> Hello,
>
> On 03/07/2016 04:48 PM, Zane Bitter wrote:
>> On 04/03/16 04:35, Johannes Grassler wrote:
> [Uncaught client exceptions in resource plugins' add_dependencies()
> methods]
>> Yes, you're right and this sucks. That's not the only problem we've
>> had in
>> this area recently - for example there was also:
>>
>> https://bugs.launchpad.net/heat/+bug/1536515.
>>
>> The fact that we have to have these hacked in implicit dependencies at
>> all is
>> terrible, but we really need to make sure they can't break basic
>> operations
>> like loading a stack from the DB so we can show or delete it. The
>> ideal would
>> be:
>>
>> * We can guarantee to catch all (non-exit) exceptions, no matter what
>> kind of
>> crazy stuff people write in add_dependencies() * The plugin developer
>> doesn't
>> have to do anything special to get this behaviour
>
> Just these two are a tall order already. One could have the client plugins
> default to ignoring 404s (maybe by adding a `ignore_defaults` keyword
> argument
> to the client_plugin() method that defaults to True).
>
> That will break third-party plugins that need to handle this exception
> themselves for one reason or another. Are there such plugins, or could
> there
> conceivably be such plugins? I can't think of a likely scenario off the
> top of
> my head, but since I'm not familiar with any third party plugins that
> may not
> mean much.
>
> Also, and probably more serious, it may require a potentially largish
> number of
> adaptations to core heat code in places where this behaviour is undesirable
> (and that might in turn cause new bugs).
>
>> * The code remains backwards compatible with any third-party resource
>> plugins
>> circulating out there
>
> ...and that rules out handling the exception at a higher level (i.e.
> whereever
> add_dependencies() is called). Doing that creates a lot of possibilities
> to end
> up with a messy dependency graph.
>
>> * We always add as many dependencies as possible (i.e. all
>> non-exception-raising dependencies are added)
>
> That pretty much means code in the add_dependcies() method, and the only
> feasible way I see of influencing this code is finding a way to
> selectively get
> the client plugins to default to ignoring dependencies.
>
>> * Genuine dependency problems (e.g. non-existent target of
>> get_resource/get_attr) are still surfaced, preferably on CREATE only
>
> Ignoring the 404s at a higher level may be feasible in the DELETE case,
> but I'm
> not sure how bad a problem a possibly incomplete dependency graph
> creates for
> stack-delete: is it a complete show stopper or just a matter of issuing
> multiple stack-delete requests until all resources are gone?

I think you're being a little too pessimistic. I was going to explain 
one approach, but it turned out to be easier to just submit a patch:

https://review.openstack.org/290027

I believe this satisfies requirements 1, 2, and 4. I agree that there's 
no way we can really tackle 3 as far as third-party plugins go, but at 
least all explicit dependencies are guaranteed to be added. For the 
implicit ones, it's up to plugin authors not to screw it up.

BTW I created https://bugs.launchpad.net/heat/+bug/1554625 to cover this 
larger issue (as opposed to the specific problem you are fixing in bug 
1442121); that would probably be a good one to reference in your docs 
changes.

cheers,
Zane.



More information about the OpenStack-dev mailing list