Comment 12 for bug 806241

We're currently sprinting on deploying OpenStack with Orchestra + JuJu, and this is absolutely the most critical bug to our current deployment.

We're trying to develop reusable charms for the ~10-ish moving parts to the OpenStack infrastructure. We'd like to develop fundamental units that represent each of the core components, and use the power of JuJu to scale them out, and develop real High Availability of OpenStack.

To do this, we'd use individual charms for MySQL, RabbitMQ, Nova-Compute, Swift, Swift-Proxy, Nova-API, Glance, Keystone, Dash, Scheduler, Network, etc. Some of these are meant to be co-located, or should be to optimize hardware usage. Unlike EC2, where you have as many systems as you're willing to pay for, our physical network has hard limits to a physical number of systems. We *must* be more careful and conservative about what gets deployed where. As noted above, we need to co-locate the MySQL, RabbitMQ, and a couple of other services, as these physical systems are quite capable of running multiple services.

At this point, we're having to develop custom charms for each and every topology or deployment combination that we need. It's really quite unfortunate to have to snapshot/steal the charm bits and combine them into new charms every time we need a combination of services on a given system.

Would it be possible to raise the priority of this bug? Co-located charms are essential to using JuJu to deploy complex systems -- specifically, OpenStack, in our current use case. Thanks.