relations on unit level

[Stuart Bishop]

On 19 May 2014 16:40, Tudor Rogoz <rogoz at adobe.com> wrote:

> The charm that I'm implementing depends on the mongodb charm.What i want to
> achieve is to link each unit from my service to a different unit from the
> mongodb service.For as i understood juju supports relations on the service
> level, and this means that all the units from my service will connect to
> each unit from the mongodb service.As an use case for my needs, if i deploy
> my service with 5 units and a mongodb service with 3 units and link them, i
> want that 3 (random) units from my service to connect to separate 3 mongodb
> units.

This seems strange to me, and I can't really see why you would
structure things this way. Will all the units actually work, including
the two not connected to mongodb? You might want to post more details
so we can suggest alternative architectures, for example using a load
balancer or proxy of some kind.


> I can deploy separate service instances using my charm and link to separate
> mongo database services and probably will work, but i want to accomplish
> this on units level.
>
> Any ideas, suggestions?

When you add the relation, every unit in your charm will be related to
every unit in the mongodb charm. That doesn't mean that all your units
actually need to make use of every mongodb unit. They can choose to
talk to a single mongodb unit, or no mongodb units at all. You would
need to use a peer relation in your charm for your units to coordinate
with each other, informing each other which mongodb unit they have
elected to communicate with. This is non-trivial though; because you
cannot control the order that units join the relation, and because
multiple units may be joining the relation simultaneously, and you
have no locking or 'master' unit to coordinate things, you will need
to deal with conflicts.

You would need a method like the following to select a mongodb unit to use:

    if have mongodb unit:
        inspect peer relation
        choose random mongodb unit not already in use, or none
        advertise use of mongodb unit on peer relation
    else:
        inspect peer relation
        if other unit is also using my mongodb unit:
            if unit number of other unit less than my unit number: #
Resolve conflict
                choose random mongodb unit not already in use, or none
                advertise use of mongodb unit on peer relation

You would need to invoke this from your mongodb relation-joined,
relation-changed and relation-departed hooks so it gets invoked when
new mongodb units are added and removed, and you would need to invoke
this from your peer relation-joined, relation-changed and
relation-departed hooks so it gets invoked when new units in your
service are added and removed.

As an extra bit of complexity I didn't put in the above pseudo code,
your mongodb unit selection algorithm needs to be smart enough to
realize if it is running in a peer relation-departed hook and to
consider any units claimed by the departing peer as free mongodb
units.

-- 
Stuart Bishop <stuart.bishop at canonical.com>