Open Stack

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

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.

The Route resource has not yet been merged, so we can discuss in the 
review the best course of action - which IMO is to:
(a) Fix the Neutron API to allow atomic updates to the route table; and
(b) Use a reference to a RouterInterface as the nexthop value, to ensure 
that routes are not created before their nexthops are available.

cheers,
Zane.

[1] https://etherpad.openstack.org/p/icehouse-summit-heat-exorcism
[2] https://review.openstack.org/#/c/60118/
[3] https://review.openstack.org/#/c/59626/8
[4] https://review.openstack.org/#/c/61388/3
[5] https://review.openstack.org/#/c/41044/