[openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete
zbitter at redhat.com
Tue Mar 8 17:26:53 UTC 2016
On 08/03/16 08:03, Johannes Grassler wrote:
> 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()
>> 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:
>> 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
>> like loading a stack from the DB so we can show or delete it. The
>> ideal would
>> * We can guarantee to catch all (non-exit) exceptions, no matter what
>> kind of
>> crazy stuff people write in add_dependencies() * The plugin developer
>> 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
> 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
> 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
>> circulating out there
> ...and that rules out handling the exception at a higher level (i.e.
> 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:
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
More information about the OpenStack-dev