multiple charms on the same VM

[Mark Shuttleworth]

On 20/09/13 02:14, David Cheney wrote:
> See the "Deploying to specific machines" section of
> https://juju.ubuntu.com/docs/charms-deploying.html
>
> Please read the "Considerations" section below that one and understand
> that charm authors do not consider this method of deployment when
> writing their charms.

The way to think of this is that putting two charms in the same
filesystem runs the risk of inadvertent collisions between them (say
they both try to rewrite /etc/foo.conf !). Some charms (subordinates)
are designed to fit into space where another charm has the lead. Other
pairs or sets of charms may work (even well) this way because they were
designed and tested this way... but YMMV.

A better way to divide up the horsepower of a single VM is with
containers, which are like chroots on steroids without the rage. Juju is
making it very easy to create a new container on a given VM and put
something in it. So you can say (paraphrasing from memory):


 # get me a new VM on the cloud with default instance type etc, say this
is machine 2
 juju add-machine
 
 # make a new LXC container on that machine. This will be machine 2/lxc/0
 juju add-machine lxc:2

 # put mysql into that container
 juju deploy mysql --to 2/lxc/0

 # make a second LXC container on the machine, it will be 2/lxc/1, and
put WP on it
 juju add-machine lxc:2
 juju deploy wordpress --to 2/lxc/0


The net effect is a single VM with wordpress and mysql running in it,
but isolated in separate parts of the filesystem that cannot overlap.
There is a fair amount of dot-connecting to do in this picture, but it
should give you an idea of what's possible now on physical deployments
with MAAS and what's coming to cloudy deployments on EC2 / Azure /
OpenStack etc

Mark