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

Zane Bitter zbitter at redhat.com
Tue Mar 8 15:57:31 UTC 2016

On 08/03/16 10:40, 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]
>> In the meantime, we need to find and squash every instance of this
>> problem
>> wherever we can like you said.
> It might also be a good idea to caution against unchecked API client
> invocations in
> http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html
> until a real fix for the problem is in place. Also, that document does
> not even
> mention the add_dependencies() method, leaving plugin developers that
> much more
> room to come up with dodgy code that does weird stuff in
> add_dependencies() or
> even omits it entirely.

It's best if they *do* omit it entirely. The only reason we override it 
in the Neutron resources is that the Neutron API is terrible for 
orchestration purposes[1]. It adds a bunch of invisible, fragile magic 
that breaks in subtle ways when e.g. resources are moved into nested 
stacks. The default implementation provides everything that we *ought* 
to need, so if we document anything I think it should be that plugin 
developers should not touch add_dependencies() at all.

If they must, though, then the relevant guidelines should be to ensure 
that any exceptions raised:

1) are deterministic; and
2) should prevent the stack from being created.

[1] Obligatory rant: 

> I haven't written any plugins so far, but I
> suppose I
> could update that part of the documentation - I've become rather
> familiar this part of the code while fixing
> <https://bugs.launchpad.net/bugs/1442121>.
> If I wanted to add a section on add_dependencies() and its pitfalls to
> pluginguide.rst, how would I go about it? Just submit a change with a
> "Partial-Bug: #1442121" or is that big enough to require a spec?

Definitely not big enough to require a spec IMO.


More information about the OpenStack-dev mailing list