More info on juju

[Gustavo Niemeyer]

> No answer yet but that would be very useful since our project is going to
> start soon.

Sounds good. Let's see then..

>>> I would like to install a cluster where one node will be a master and the
>>> other the slaves.
>>> I would like those to collaborate in some way - for example if using NFS
>>> I would like the slave to mount a filesystem from the master.
>>>
>>> I will have a charm for the master and one for the slaves.
>>> I will probably install on the slave first and then on the slaves.

You don't have to worry about ordering in those terms. It is possible
to have two charms with a relation between them, and then just wait
until a given setting is made available via the relation. For example,
inside a mynfs-relation-joined in the slave, one may have:

    MASTER=`relation-get exported-location`
    if [ -z "$MASTER" ]; then
        exit # Not yet available.
    fi

Juju guarantees that if that relation changes, the hook will be called again.

>>> How can I send some information from the master to the slaves - actual
>>> hostname for example ?

Within the mynfs-relation-joined hook (assuming the relation is named
mynfs), you add something such as:

    relation-set exported-location="$ADDR"

Then, all the slaves participating in that relation will have their
mynfs-relation-changed hook called.

>>> What If I wanted also the master to know the hostname from the slaves ?

For that specific need, juju actually helps already by injecting the
private-address setting into the relation. You can always do the above
even then, regardless of that.

>>> Shall I use a 2 steps install procedure ?

It shouldn't be necessary, as described above.

>>> I started looking at the hadoop charm which should somehow have a similar
>>> requirements - but I did not see something of that sort.

Maybe it wasn't obvious, but it should be there I suspect.

I hope this helps. Please let us know if you need further details.


gustavo @ http://niemeyer.net