Evaluating Juju for use in a large system

[Clint Byrum]

Excerpts from Torin Sandall's message of 2012-09-01 15:06:29 -0700:
> Clint,
> 
> Thanks for the prompt reply.
> 
> One other question I have is, does Juju provide a way to set service
> unit specific configuration when the units are being added? I see two
> ways this could work:
> 

The way to do this now is in the service level configuration. I have
been working on a rewrite of the CEPH charm and it requires that only
one machine do an initial "bootstrap" of the ceph mon database, so I
set something like:

juju set ceph-mon bootstrap-unit="ceph-mon/0"

Which, once set, is used to do that initial leader duty, and then
is ignored.

> 1) you have some global configuration which has areas for specific
> service units. Of course these areas would need to be keyed by the
> service unit name, so there would need to be a mechanism for
> specifying the service unit name when you deploy or add-unit.
> 
> 2) you have the ability to set service unit specific configuration
> when you deploy or add-unit.
> 
> I don't think either of these approaches are supported in Juju today,
> but maybe I'm missing something and there's another way to handle it.
> 
> The use case which brought this to mind was deploying Cassandra with
> Juju, e.g., you want to manually assign the token a given Cassandra
> service instance bootstraps with.
> 

Right, service level configs are the right place to do this now. Changing
them will fire the config-changed hook on all units, and they can then
all decide whether or not to act on it.

I'd argue that the cassandra use case should be automated though. Is there
any reason the Cassandra units can't just generate their tokens as UUIDs?