On 18/12/13 05:21, Thomas Herve wrote:
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.
Quite right, my mistake, and I can definitely see how it would not have
looked suspicious at the time. I can easily imagine though that there
might be a bug raised in the future saying we need to add some magic
dependencies to [3] to make sure the DHCP agent is selected before any
instances/ports get created. Actually there's already an inline comment
from the author in patch set 1 of [4] that says "I will add dependency
between subnet and NetDHCPAgent."
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.
That's true, although I suspect it may only be working by coincidence
now. It also seems to me that we should have a consistent approach for
selecting agents. This resource does nothing but connect two other
resources together in a way that, if it makes any difference at all,
makes the dependency resolution worse not better. (Contrast this with
VolumeAttachment or EIPAssociation, which exist to solve some specific
dependency issues.) Conceptually, it is just a property of the Network IMO.
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?
I haven't seen that justification advanced anywhere in relation to this
particular resource type, but maybe I missed it. In any event, if you
want to use a Router defined outside of the template, you should also
assign it to the correct agent outside of the template. It's difficult
to get upset about that, especially given that it needs to be done
before you use the Router for anything anyway. Basically there's no
there's no safe way to do this other than at the time you create the
router... that's the nice thing about not hacking the dependencies -
when they're all explicit in the template then everything works the same
way whether it's created in Heat or not, in the same template or not.
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
