[openstack-dev] [Heat] Neutron resources and hidden dependencies

Thomas Herve thomas.herve at enovance.com
Wed Dec 18 10:21:19 UTC 2013


> At the design summit we had a discussion[1] about redesigning Neutron
> resources to avoid the need for hidden dependencies (that is to say,
> dependencies which cannot be inferred from the template).
> 
> Since then we've got close to fixing one of those issues[2] (thanks
> Bartosz!), but the patch is currently held up by a merge conflict
> because... we managed to add two more[3][4].

Sorry, I'm one of the reviewer of those, and [4] was a bit suspicious indeed, but it sounded like the best solution. [3] doesn't add dependencies, though. 

> There's also another patch currently under review[5] that adds the most
> impressively complex hidden dependencies we've yet seen (though,
> fortunately, the worst of this is actually redundant and can be removed
> without effect).
> 
> I know that due to the number of Neutron resources that currently
> override add_dependencies(), this may look like a normal part of a
> resource implementation. However, this is absolutely not the case. If
> you feel the need to override add_dependencies() for any reason then
> some part of the design is wrong. If you feel the need to do it for any
> reason other than not breaking existing soon-to-be-deprecated wrong
> designs (i.e. RouterGateway), then your part of the design is the part
> that's wrong.
> 
> Core reviewers should treat any attempt to override add_dependencies()
> as a red flag IMO.
> 
> It's unfortunate that many parts of the Neutron API are not great,
> especially that some pretty core functionality is currently balkanised
> into various 'extensions' that don't have a coherent interface.
> Nevertheless, that just means that we need to work harder to come up
> with resource designs that express the appropriate relationships between
> resources *in the template*, not with hidden relationships in the code.
> This means that orchestration will actually work regardless of whether
> all of the related resources are defined in the same template, and in
> fact regardless of whether they are defined in templates at all.
> 
> I'd like to propose that we revert NetDHCPAgent and RouterL3Agent (which
> are somewhat misnamed, and serve only to connect a Net or Router to an
> existing agent, not to create an agent) and replace them with properties
> on the Net and Router classes, respectively.

I'm not sure about NetDHCPAgent, as it doesn't add a dependency. Regarding RouterL3Agent, the only objection I have is if you want to use a router defined outside of the template, which if I remember correctly was the justification of this class. Do we have an answer for that?

Thanks,

-- 
Thomas



More information about the OpenStack-dev mailing list