How do I deploy jenkins and jenkins-slave if they have mismatching series?

Question

Note: I'm running this on 3 Ubuntu trusty VM's on my OS X laptop over VMWare Fusion.

I am a juju newbie and having some trouble with setting up jenkins-slave. I have a bootstrap machine, and 2 other machines. Jenkins (master) is successfully installed on machine 1. When I try to deploy jenkins-salve I get the error message:

juju deploy -n 1 jenkins-slave
cannot assign unit "jenkins-slave/0" to new machine: use "juju add-machine ssh:[user@]<host>" to provision machines

I also tried:

juju remove-service jenkins-slave
juju deploy jenkins-slave --to 2
Added charm "cs:precise/jenkins-slave-7" to the environment.
ERROR cannot assign unit "jenkins-slave/0" to machine 2: series does not match

It makes no sense, since before attempting to deploy jenkins, I added two machines:

juju add-machine ssh:machine1
juju add-machine ssh:machine2

both successfully finished. Here's my status output

juju status
environment: manual
machines:
"0":
agent-state: started
agent-version: 1.20.14
dns-name: thebat
instance-id: 'manual:'
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
state-server-member-status: has-vote
"1":
agent-state: started
agent-version: 1.20.14
dns-name: elemental
instance-id: manual:elemental
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
"2":
agent-state: started
agent-version: 1.20.14
dns-name: terrifying
instance-id: manual:terrifying
series: trusty
hardware: arch=amd64 cpu-cores=1 mem=979M
services:
jenkins:
charm: cs:trusty/jenkins-2
exposed: false
units:
  jenkins/0:
    agent-state: started
    agent-version: 1.20.14
    machine: "1"
    open-ports:
    - 8080/tcp
    public-address: elemental
jenkins-slave:
charm: cs:precise/jenkins-slave-7
exposed: false
units:
  jenkins-slave/0:
    agent-state: pending

Answer 1

The answer is quite simple, yet very unlikely. The charm for jenkins-slave is a precise charm, which means it can only be installed on a precise Ubuntu VM.

While this only seems obvious after an entire day with juju, I believe it is a major problem with this tool. Chef / Puppet, etc are not flavor dependent, so why is juju flavor version dependent. It's a major lack of planning in my opinion.

Answer 2

You are using the manual provider, which means you have to manually manage and match the charm series with the series deployed on the unit. If you used, e.g., the local provider (the documentation provides a predefined Vagrant image which has been tested to work on OS X), Juju would automatically manage the unit allocation—including the series—for you so that you would not run into this issue.

The series defined for a charm is the version of Ubuntu that the charm has been tested on and is known to work with. It is entirely possible that the charm will work with a newer series, and in many cases the same charm is submitted for both series. (There has also been some discussion of supporting multi-series charms, where the supported series are defined in the charm's metadata.yaml.)

If you find a charm that is only available for a specific series but you really want to run it on a different series (with the caveat that it may not function correctly), you can always branch the charm from Launchpad into a local directory structure of <series>/<charm-name> and deploy it using juju deploy local:<series>/<charm-name>. (This is the same process that a charm author would use to being making the charm support a new series. If you do this, and are able to get the charm to work, certainly the charm maintainer would likely appreciate you submitting your changes to allow the charm to support the new series.)

Note that the series restriction only applies to the machine upon which that charm is deployed. As long as two charms support the same interface, they can be related and work together, even if they are running on different series.