Open Stack

Hello,

On 03/08/2016 04:57 PM, Zane Bitter wrote:
> On 08/03/16 10:40, 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()
>> 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
[...]

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

I never saw the Neutron API that way before (I guess I just got used to the
unintuitive bits), but seeing it spelled out in your rant makes it very
obvious, yes. I didn't know that was the root cause for overriding
add_dependencies() and that very ignorance of mine...

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

...suggests mentioning that much is probably a good idea (lest somebody pick
one of the Neutron plugins as a template to base their own resource plugin
on).

> Definitely not big enough to require a spec IMO.

Yes, I can see that, given how it's not something plugin writers should do
anyway. Then I'll just write a little paragraph cautioning against overriding
add_dependcies() and add a Related-Bug: line.

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