Greetings Shilpa, I'm cross posting this to the juju mailing list, as there are probably others who have had, or have the same question about using a single charm, with multiple supporting roles. I would highly encourage you to engage the mailing list as you develop questions about Juju, so that other users may chime in with their experience.
With regard to changing how the charm deploys/interacts at runtime based on relations. It's been noted that while this may ease some of the maintenance burden of the charm author - this also causes confusion to users when they are deploying the stack. If this is along the lines of needing a service group leader, and each additional node becomes a follower unit participating in the cluster, I would encourage you to use the leadership features of juju https://jujucharms.com/docs/stable/authors-charm-leadership If you need to do raidcally different configuration of the software based on what 'role' the charm is deployed as, it may be worth investigating the work required to split the charm into layers, abstract the base delivery of the software into a shared layer, and encapsulating the 'roles' into an additional layer, and outputting 2 charms. As that will have a clear definition of how to deploy the software, especially when you distribute the recommended setup as a bundle. Now that i've spoken my peace against a single charm with multiple roles, in the spirit of answering the original question: To do this you will need to have a few concerns lined out before hand, such as what messaging you need to give to your user - if the user only deploys the LSF charm by itself, with no additional units, should it do anything? as in deploy in standalone mode - If the user adds units, will this depend on leader data? - If we need this secondary "role" to be related to enable the workload in its most basic form, what messaging is required to do so? With the pre-reqs sorted, and plotted - i'm going to assume the answer to the last bullet point was "we need the secondary role, and we have a relation for lsf-controller and lsf-node. both are encapsulated in the same charm As you deploy the LSF charm, you can check for the present of the relation. In reactive this is fairly trivial, as relations consume interfaces, and these interfaces establish states on the unit to identify that indeed the relationship is present. Looking over the HTTP interface, as an example - we see that the interface sets a state for the relation consuming the interface to .available. https://github.com/juju-solutions/interface-http/blob/master/provides.py#L12 You can then decorate a method body on the receiving side with this: @when('lsf-controller.available') setup_controller(){ # method body to setup the controller } @when('lsf-node.available') setup_node(){ # method body to setup the node } Each body is basically responsible for executing the setup portion that is specific to configuring the LSF daemon for that 'role'. and you've encapsulated 2 different roles in the same charm, dictated by relationships. All the best, Charles Charles Butler <[email protected]> - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com On Mon, Dec 14, 2015 at 12:35 PM, Shilpa Kaul <[email protected]> wrote: > Hi Charles, > > I am working on IBM Platform LSF charm where I have to implement different > hosts types of LSF to form a LSF Cluster. I was going through the juju docs > where I read about the topic : charms-service-groups - Roles where services > acquire a role at runtime based on the relations that are joined. Hadoop > charm is an example where this role concept is implemented.I am not so > clear that how services can acquire role at run time?. > What I could understand is that I can deploy one charm but different > service names and then having relations between these services. > > I was thinking to implement something similar for my LSF charm ,where I > have one charm , say ibm-platform-lsf > juju > deploy ibm-platform-lsf lsf-master > juju > deploy ibm-platform-lsf lsf-server > juju > deploy ibm-platform-lsf lsf-master-candidate > > So based upon the host type, I am deploying one single charm, but > different service names during deployment and then adding relations among > them, for example > juju > add-relation lsf-server:server-host lsf-master:master-host > > I believe Hadoop charm is also implemented like this , please let me know > if my understanding is correct. > > Also, if this is the case ie deploying one charm but different service > names, then how we can do this type of deployment through Juju GUI, where > we cannot define a specific service name during drag and drop of charms on > GUI. > > > > Thanks and Regards, > Shilpa Kaul > IBM India Pvt. Ltd > Seat # EGLC 6F B067, > C-Block, Embassy Golf Link, > Intermediate Ring Road, Bangalore > Email : [email protected] > Mobile : 9900054908 >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
