Propagating state change to multiple peers
gustavo.niemeyer at canonical.com
Wed Jul 13 21:20:09 UTC 2011
> I believe that may solve my issue. If I follow, I can 'relation-list' to
> find out how many service units in the relation. On addition of a new peer,
> I can update configuration and for each unit in 'relation-list', use
> 'relation-set' to export my new config and in turn cause relation-changed to
> be fired on each peer?
You don't even need that. The peer relation is established
automatically with all the serv uce units of the given service that
As an example, let's say there's a riak formula declaring a peer
relation. When you first deploy the service, it will have a service
unit with a relation that isn't paired yet. Then, when you do
add-unit on that service, both units will get a <name>-relation-joined
event, and will be able to talk to each other. If you add-unit again,
the the two initial units will get a notification that a third one has
joined, and the third one will also be told it's participating in a
relation with the other units. So no work is necessary "out of band"
to let the units know that they are part of a ring within the service.
> I was not aware peer relations differed from regular require/provide
> relations. Is this documented somewhere?
There's not a lot of details, even because it doesn't differ that much
from a normal relation, but it is documented at:
We should improve this with the outcome of this conversation.
-- I never filed a patent.
More information about the Ensemble