Orchestrating a patch installation scenario in a application sever cluster

[Kapil Thangavelu]

On Sun, May 26, 2013 at 11:20 PM, Denis Weerasiri <ddweerasiri at gmail.com>wrote:

> Thanks Kapil,
> Please see my comments inline.
>
> On Fri, May 24, 2013 at 10:23 PM, Kapil Thangavelu <
> kapil.thangavelu at canonical.com> wrote:
>
>> The intra service unit coordination for a round robin activity is best
>> served by a peer relation. The signalling of the patch application/change
>> needs to be done externally via the client api atm, ie. changing the
>> service configuration to denote a vcs revision or patch file.
>>
> I was under impression, it is not possible to define explicit "peer"
> relations among service units belong to a same service.
>

That's a misunderstanding then, its a core juju capability used by many
charms. Typical usage of a peer relation atm is for nosql databases to
coordinate replication services/token rings (mongodb, cassandra).

Some examples (see relation hooks for behaviour associated).
https://bazaar.launchpad.net/~charmers/charms/precise/mongodb/trunk/view/head:/metadata.yaml
https://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/view/head:/metadata.yaml

Peer relations are intra-service only, and are automatically established at
service deployment time.

And it is possible to define explicit peer relations among different
> services.
>

Inter-service relations use the client/server label, the real difference
between the two relation types post establishment is really just that..
peer rels are between units of one service, and client/server are between
units of different services. Also one can address (relation-ids) and
mutate/retrieve data of a relation from within a different hook. ie.
relation-x (or config-changed) mutating relation settings of relation-y,
that are observed by remote units of relation-y.


So is this round robin behaviour for inter service unit
> coordination implicitly defined for each service unit in the system?
>
>
No. A charm would need to declare the peer relation in its metadata, and
implement the communication protocol of round robin on top of the relation
facilities.

cheers,
Kapil



> A subordinate isn't needed. Subordinates are helpful for generic or
>> ancillary features, but structuring core functionality of another service
>> there tends to obfuscate the charm and the usage imo.
>>
>> cheers,
>> Kapil
>>
>>
>> On Tue, May 21, 2013 at 9:26 AM, Denis Weerasiri <ddweerasiri at gmail.com>wrote:
>>
>>> Hi,
>>> I am trying to realize the following patch installation scenario in a
>>> application cluster fronted with a load-balancer.
>>> Let's assume I use Puppet like a configuration management tool to
>>> install the patch in each node.
>>>
>>> Here is the scenario
>>>
>>>    - The cluster is consist of two nodes named A and B.
>>>    - First stop the node A and install the patch using a puppet
>>>    manifest and restart the node A
>>>    - Then stop the node B and install the patch using a puppet manifest
>>>    and restart the node B
>>>    - So the application is available 100% at all the times
>>>
>>> The problem is, how can I write a charm to automate this patch
>>> installation scenario, where *Juju should be able to
>>> propagate life-cycle changes in one service unit in Node A to the other
>>> service unit in Node B*.
>>> When I went through the Juju doc, I found about subordinate services
>>> which may solve my problem
>>> https://juju.ubuntu.com/docs/subordinate-services.html . Is this the
>>> correct way of automating this patch installation scenario?
>>> Or how is it possible to propagate life-cycle changes in one service
>>> unit to the another service unit?
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Denis
>>> ----------------------------------------------------------
>>> *Denis Weerasiri*
>>> *
>>> *
>>> <http://wso2.com/>**** <http://wso2.com/>*site: **
>>> https://sites.google.com/site/ddweerasiri/*<https://sites.google.com/site/ddweerasiri/>
>>> *blog: **http://ddweerasiri.blogspot.com*<http://ddweerasiri.blogspot.com/>
>>> *
>>> twitter: **http://twitter.com/ddweerasiri*<http://twitter.com/ddweerasiri>
>>> *
>>> linked-in: **http://lk.linkedin.com/in/ddweerasiri*<http://lk.linkedin.com/in/ddweerasiri>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
>
> --
> Thanks,
> Denis
> ----------------------------------------------------------
> *Denis Weerasiri*
> *
> *
>  <http://wso2.com/>**** <http://wso2.com/>*site: **
> https://sites.google.com/site/ddweerasiri/*<https://sites.google.com/site/ddweerasiri/>
> *blog: **http://ddweerasiri.blogspot.com*<http://ddweerasiri.blogspot.com/>
> *
> twitter: **http://twitter.com/ddweerasiri*<http://twitter.com/ddweerasiri>
> *
> linked-in: **http://lk.linkedin.com/in/ddweerasiri*<http://lk.linkedin.com/in/ddweerasiri>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130528/467cfdc7/attachment-0001.html>