Orchestrating a patch installation scenario in a application sever cluster

[Denis Weerasiri]

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. And it is possible
to define explicit peer relations among different services.
So is this round robin behaviour for inter service unit
coordination implicitly defined for each service unit in the system?

>
> 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/20130527/5264465c/attachment.html>