Open Stack

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?

Cheers,

Johannes

-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany