Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm new to Juju and Openstack and currently deploying two- and three-node openstack test environment using Juju manual provider. At my first attempt I tried to deploy services to my hosts using --to key for juju deploy.

I realized something is going wrong when Juju failed to create relation between Keystone and MySQL deployed on the same host. To deploy services I used the following syntax:

juju deploy keystone --to 1   
juju deploy mysql --to 1

Some googling gave me this question on askubuntu and this guide.

So, as I understand, the correct way to deploy services in manual environment is using lxc containers for services being deployed to the same host (if these services can work in containers, of course).

Although I see such advantages of lxc like service independency and isolation, I still don't understand why services deployed by Juju MUST be isolated in containers. Is it a Juju design flaw or temporary solution?

Is there any way to deploy a couple of services to the same host without lxc?

I think it can be done by specifying config file for each service being deployed, but this would eliminate nearly all Juju "magic" and simplicity...

share|improve this question
Consider maybe changing this question to "Why must Juju charms be isolated in containers?" or "Must Juju charms be isolated in containers?" or something like that? If I understand your question correctly, I don't think it is specific to manual provisioning. – Robie Basak Aug 6 '14 at 19:19
Thank you, on second thought it really seems like charm-specific way of deployment which is not specific for manual provider. – user312137 Aug 7 '14 at 16:20
It's not really specific to OpenStack, either. OpenStack and OpenStack-related charms might have caused you to ask the question, but really the question and answer apply to all charms. – Robie Basak Aug 8 '14 at 11:31
I understand that. I mentioned Openstack in my question because I was quite confused at first when realized that charms should be deployed into containers. Official Openstack install guide assume engineers to deploy services side by side and it works without any problems. – user312137 Aug 8 '14 at 11:46

Juju itself doesn't care. It is up to the charms that you deploy to handle the situation, or not. So this isn't really treated as a problem at all; it's merely a difference between what Juju supports, what charms typically support, and accepted best practice.

I don't think this answer is specific to the manual provider. It applies to all providers.

Most charms assume that they "own" the machine (or container) that they are deployed to, and in the past this was the only way to deploy them.

This isolation makes charms easier to develop and test. It eliminates the need for charm developers to worry about sharing resources with other charms. A modular deployment makes it easier to manage complexity. By limiting interactions between charms to Juju relations, they can remain clean and well understood. Charm authors do not have to worry about making "system"-level changes that might adversely impact other charms; it is up to the containerization to handle this correctly. This eliminates a whole class of charm bugs where one charm adversely affects another.

So, in practice, charms should be deployed to their own containers at a minimum, unless they are specifically designed to work together. Conflicts that arise when two charms are deployed to the same machine without putting them in containers will generally not be treated as bugs.

This shouldn't affect much. LXC is lightweight.

None of this stops you writing your own charms, or modifying existing charms, to permit them to be deployed to the same machine or container. Juju will permit it, but it is then up to the charms to ensure that they don't conflict.

Is it a Juju design flaw or temporary solution?

No - it's not really a Juju thing at all; it's the chosen best practice amongst charm authors, and relates to decisions made about what deployment configurations charms should and should not support.

There are some edge cases where it is useful, and not difficult to support (eg. the Juju GUI running on the bootstrap node), so Juju permits it. I believe that there are no plans for Juju's support to change.

share|improve this answer
Ok, the need for containerization is really charm-specific. I understand that containers are really good way to isolate service environment and make it independent of other services. For example guys in Mirantis made this in Fuel 5.0 - they use docker to isolate each component of Fuel. I just never thought about containers as a way to isolate service environment, for me they always was lightweight kind of virtualization. Maybe because I'm not a programmer. I've got one more question. What exactly does "Most charms assume that they "own" the machine (or container)" mean? – user312137 Aug 7 '14 at 16:43
This means that 1) a charm assumes that no other charm will interfere with any operations that it has set up on its system; and 2) that it may do what it likes to the system it is running on without concern for any other charm. Does that make it clearer? – Robie Basak Aug 8 '14 at 11:30
Not really, some example would be great. I wonder what changes to system shall charm make to break everything? As I mentioned in comment to my question, all those services work together happily without any kind of containerization or isolation and even without any precautions. And most of them really does not do anything special to the system. For example, I hardly can imagine how Keystone can iterfere with MySQL. Running each service in a container looks like a good practice, but I hardly can tell that it's necessary. – user312137 Aug 8 '14 at 11:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.