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.
__________________________________________________________________________
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
