Evaluating Juju for use in a large system

[Torin Sandall]

Just so I understand, your solution is: add-unit first, determine the
service-unit id/name, then set the value in service configuration.
When service configuration changes, the new service-unit can "unblock"
and finish it's initialization.

This would seem to require the charm be written in a very specific
way, plus I'm not sure about how the sequencing w.r.t.
relation-joined/changed would work (though perhaps that's outside the
scope of this question.)

Would it not be easier for the user to be able to set the
configuration first and then add-unit with a parameter which relates
the new service-unit to the configuration value? E.g., set serviceX
foo=<some config>, add-unit serviceX config_key="foo".

-Torin

On Sun, Sep 2, 2012 at 10:26 AM, Clint Byrum <clint at ubuntu.com> wrote:
> 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?

Cassandra can automatically assign tokens, however it doesn't have
enough context to always make the right decision. AFAIK,  the best
practice is still to manually assign the tokens.