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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
