Relation ordering: Does it matter?

[Gustavo Niemeyer]

Hi Clint,

> 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?

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.