Relation ordering: Does it matter?
gustavo.niemeyer at canonical.com
Tue Feb 7 03:02:54 UTC 2012
> Upon establishing the database relation, there is nothing to signal to
> juju that it should try again, the keystone<->compute relationship is
> broken until an administrator uses 'juju resolved ...'.
This is the key problem we have to fix, and it's been on our TODO
since inception: commands such as relation-get and relation-set must
work out of band, outside of any hooks. We want that for a number of
reasons, but one of the problems it will solve is the one you're
reporting. Once the provider is ready to serve, it can simply set a
relation option to awake the consumer.
> We could just enforce that 'provides' relationships won't do anything
> until a 'requires' relation exists. However, this will only narrow the
> race window. Between creating the relationship, and it actually being
> configured, the agents might still try to join the two together.
> I think we need a way to flag a relationship as being in a steady
> state. This seems quite doable given the information we have.
Introducing ordering and heuristics about stability of relations is a
rabbit hole. Just to point a few issues that come to mind as I write:
- Relations are optional, so they may become steady simply because the
admin hasn't finished the add-relation commands yet.
- Another consequence of optional relations is that services generally
will work without the requirements alive, in many cases. We shouldn't
make them unavailable just because a given relation isn't around.
- Machines stop/die and get restarted. No matter what order we
establish relations, the software has to know how to reestablish
itself to a live instance on the other side.
- It's easy to find different use cases that require a different
notion of ordering requirements.
- Loops may easily happen depending on the topology
> Adam's been using with success for openstack deployment.
Adam, would allowing relation-set to be run out of band solve the
problem you have?
-- I'm not absolutely sure of anything.
More information about the Juju