Targetted machine deployment with Juju

As I blogged previously, its possible to deploy multiple charms to a single physical server using KVM, Juju and MAAS with the virtme charm.

With earlier versions of Juju it was also possible to use the ‘jitsu deploy-to’ hack to deploy multiple charms onto a single server without any separation; however this had some limitations specifically around use of ‘juju add-unit’ which just did crazy things and made this hack not particularly useful in real-world deployments.  It also does not work with the latest versions of Juju which no longer use Zookeeper for co-ordination.

As of the latest release of Juju (available in this PPA and in Ubuntu Saucy), Juju now has native support for specifying which machine a charm should be deployed to:

juju bootstrap --constraints="mem=4G"
juju deploy --to 0 mysql
juju deploy --to 0 rabbitmq-server

This will result in an environment with a bootstrap machine (0) which is also running both mysql and rabbitmq:

$ juju status
machines:
  "0":
    agent-state: started
    agent-version: 1.11.4
    dns-name: 10.5.0.41
    instance-id: 37f3e394-007c-42b9-8bde-c14ae41f50da
    series: precise
    hardware: arch=amd64 cpu-cores=2 mem=4096M
services:
  mysql:
    charm: cs:precise/mysql-26
    exposed: false
    relations:
      cluster:
      - mysql
    units:
      mysql/0:
        agent-state: started
        agent-version: 1.11.4
        machine: "0"
        public-address: 10.5.0.41
  rabbitmq-server:
    charm: cs:precise/rabbitmq-server-12
    exposed: false
    relations:
      cluster:
      - rabbitmq-server
    units:
      rabbitmq-server/0:
        agent-state: started
        agent-version: 1.11.4
        machine: "0"
        public-address: 10.5.0.41

Note that you need to know the identifier of the machine that you are going to “deploy –to” – in all deployments, machine 0 is always the bootstrap node so the above example works nicely.

As of the latest release of Juju, the ‘add-unit’ command also supports the –to option, so its now possible to specifically target machines when expanding service capacity:

juju deploy --constraints="mem=4G" openstack-dashboard
juju add-unit --to 1 rabbitmq-server

I should now have a second machine running both the openstack-dashboard service and a second unit of the rabbitmq-server service:

$ juju status
machines:
  "0":
    agent-state: started
    agent-version: 1.11.4
    dns-name: 10.5.0.44
    instance-id: 99a06a9b-a9f9-4c4a-bce3-3b87fbc869ee
    series: precise
    hardware: arch=amd64 cpu-cores=2 mem=4096M
  "1":
    agent-state: started
    agent-version: 1.11.4
    dns-name: 10.5.0.45
    instance-id: d1c6788a-d120-44c3-8c55-03aece997fd7
    series: precise
    hardware: arch=amd64 cpu-cores=2 mem=4096M
services:
  mysql:
    charm: cs:precise/mysql-26
    exposed: false
    relations:
      cluster:
      - mysql
    units:
      mysql/0:
        agent-state: started
        agent-version: 1.11.4
        machine: "0"
        public-address: 10.5.0.44
  openstack-dashboard:
    charm: cs:precise/openstack-dashboard-9
    exposed: false
    relations:
      cluster:
      - openstack-dashboard
    units:
      openstack-dashboard/0:
        agent-state: started
        agent-version: 1.11.4
        machine: "1"
        public-address: 10.5.0.45
  rabbitmq-server:
    charm: cs:precise/rabbitmq-server-12
    exposed: false
    relations:
      cluster:
      - rabbitmq-server
    units:
      rabbitmq-server/0:
        agent-state: started
        agent-version: 1.11.4
        machine: "0"
        public-address: 10.5.0.44
      rabbitmq-server/1:
        agent-state: started
        agent-version: 1.11.4
        machine: "1"
        public-address: 10.5.0.45

These two features make it much easier to deploy complex services such as OpenStack which use a large number of charms on a limited number of physical servers.

There are still a few gotchas:

  • Charms are running without any separation, so its entirely possible for Charms to stamp all over each others configuration files and try to bind to the same network ports.
  • Not all of the OpenStack Charms are compatible with the latest version of Juju – this is being worked on – checkout the OpenStack Charmers branches on Launchpad.

Juju is due to deliver a feature that will provide full separation of services using containers which will resolve the separation challenge.

For the OpenStack Charms, the OpenStack Charmers team will be aiming to limit file-system conflicts as much as possible – specifically in charms that won’t work well in containers such as nova-compute, ceph and quantumneutron-gateway because they make direct use of kernel features and network/storage devices.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 157 other followers

%d bloggers like this: