> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev