Groups of Services

Juju deploys units of a service from a charm. The simplest way to do this is

juju deploy mysql

which will take the latest version of the MySQL charm straight from the store and create a single service unit.

By default, Juju creates a unit of a service named after the charm; mysql in the above example.

You can specify the name for the service when deploying:

juju deploy mysql wikidb

which will create a unit of the wikidb service. It creates the unit exactly as before, except instead of mysql, the service is called wikidb.

Why specify names for services? The simplest reason is organizational. It lets you stay organized as your infrastructure gets more complex:

juju deploy mysql website-db
juju deploy mysql app-master-db
juju deploy mysql app-slave-db -n2

But there are other reasons to do this: service groups, which are nothing other than named services. They are called out as a separate feature because they're quite useful in a few different ways.

Roles

Some services acquire a role at runtime based on the relations that are joined.

A great example of this is the hadoop charm. It can instantiate services

juju deploy hadoop namenode
juju deploy hadoop datacluster -n40

which are identical at this point except for the service name that Juju's using for the various units.

These services acquire roles at relation-time via

juju add-relation namenode:namenode datacluster:datanode
juju add-relation namenode:jobtracker datacluster:tasktracker

The relations determine the service role.

Another example of this is mysql replication.

juju deploy mysql masterdb
juju deploy mysql slavedb -n2

where the different services are related to each other

juju add-relation masterdb:master slavedb:slave

and to other services via

juju deploy mediawiki mywiki
juju add-relation mywiki:db masterdb:db
juju add-relation mywiki:slave slavedb:db

Upgrade Groups and/or Config Groups

There are also interesting use-cases for breaking large services down into separate groups of units. Instead of a single 5000-node hadoop service named hadoop-slave, you might build that cluster from multiple smaller service groups.

juju deploy hadoop hadoop-master
juju deploy hadoop hadoop-slave-A -n2500
juju deploy hadoop hadoop-slave-B -n2500
juju add-relation hadoop-master:namenode hadoop-slave-A:datanode
juju add-relation hadoop-master:namenode hadoop-slave-B:datanode
...

These service groups can be managed independently by Juju for upgrades and configuration

juju set hadoop-slave-B some_param=new_value

This technique can potentially be a way for Juju to manage rolling upgrades for a service. Of course, this depends heavily on the services in question and how well they support version management, schema changes, etc.