Juju constraints unbinds your machines

This week, William “I code more than you will ever be able to” Reade announced that Juju has a new feature called ‘Constraints’.

This is really, really cool and brings juju into a new area of capability for deploying big and little sites.

To be clear, this allows you to abstract things pretty effectively.

Consider this:

juju deploy mysql --constraints mem=10G
juju deploy statusnet --constraints cpu=1

This will result in your mysql service being on an extra large instance since it has 15GB of RAM. Your statusnet instances will be m1.small’s since that will have just 1 ECU.

Even cooler than this is now if you want a mysql slave in a different availability zone:

juju deploy mysql --constraints ec2-zone=a mysql-a
juju deploy mysql --constraints ec2-zone=b mysql-b
juju add-relation mysql-a:master mysql-b:slave
juju add-relation statusnet mysql-a

Now if mysql-a goes down

juju remove-relation statusnet mysql-a
juju add-relation statusnet mysql-b

Much and more is possible, but this really does make juju even more compelling as a tool for simple, easy deployment. Edit: fixed ec2-zone to be the single character, per William’s feedback.

17 thoughts on “Juju constraints unbinds your machines

  1. So the constraints are tied specifically to aws’s concept of zones? What if you want to deploy via juju to an openstack cloud? Do the constraints map over? Or do you have ot keep a different set of constraints in mind?


  2. Pingback: Ubuntu developers: Clint Byrum (SpamapS): Juju constraints unbinds your machines | Linux-Support.com

  3. Right now the EC2 API doesn’t have a way to ask for a list of the instance types and their characteristics, so the EC2 API provider embeds the Amazon types. If your openstack cloud implements the same types (called flavors in openstack), this will work via the EC2 compatibility. Even then, the cpu may mean something different, since “ECU” is fairly hard to approximate perfectly. If not, you must use the instance-type constraint and infer the mem/cpu/etc yourself.

    There could (should?) be a native OpenStack API provider written for juju, which can use the list of flavors available. As yet though, there is no native OpenStack provider that I know of.

  4. Just a few notes:

    1) Aww, Clint, I’m blushing :) .

    2) You should use “ec2-zone=a” — deployments are per-region, so the “us-east-1″ bit is redundant. (Hm, it seems I didn’t mention that in the docs; sorry. I’ll go fix that now.)

    3) Sad to say, time pressure prevented us from coming up with a nice solution for OpenStack clouds; for now, non-AWS ec2 providers don’t expose any useful constraints :( . We do have plans — hence the generic(-looking) arch/cpu/mem/instance-type constraints, that will come to be meaningful in plenty of different environments — but I can’t say precisely when you’ll be able to use them outside AWS.

    ec2-zone is a special case, because the implementation is very definitely ec2-specific [0]. Hopefully we’ll be able to deprecate it in favour of a more generic zone constraint at some point in the future, but we’re not there yet.

    4) The question of an independent OpenStack provider is an interesting one; I’m not entirely happy with the special cases in the current “ec2″ provider, but nor am I happy with the serious potential for duplication in an “openstack” one. I’m not sure what direction we should be taking at this stage.

    [0] as opposed to the others, which are merely *coincidentally* ec2-specific.

  5. William,

    Is the full list of supported contraints listed able?
    At the very list as the concept is expanded to include openstack, there should be a way to list out the full lexicon of understood constrain types group by cloud type/provider. And quite possibly a way for admins to extend the constraint list for constraints that match their private cloud configuration.


  6. William,

    Actually forget the complexity of OpenStack for a second since its a different API entirelly right.

    Does the constrain concepts successfully map into private Euca cloud deployments to any extent at present? Is there a different provider for private Euca instance handling than aws handling even though they share a core API?

    Being able to see examples of juju tooling working against a private cloud instance and then seeing what it takes to rescript the same juju interactions when migrating to Amazon’s public cloud would be very instructive. Right now all the juju stuff I’m seeing is being tuned specifically for public (at scale) AWS deployments. I’m not getting a sense of how the scripting needs to be adjusted to cross the (pre-deployment) private/ (deployment) public cloud threshold. Something to consider.


  7. All constraints currently implemented are documented here:


    The same problem exists for Eucalyptus as does for OpenStack. There is no way to ask the eucalyptus services what “m1.small” or “foo5.bellhop” actually mean. If the eucalyptus cluster has kept a 1:1 ratio with Amazon’s types, then cpu/mem will work.

    The only bits that might need rescripting are very simple argument substitutions. So your AWS deploy might be

    juju deploy foo –constraints mem=6G

    but the private cloud that has no xlarge instance type, would either leave it off or maybe would do:

    juju deploy foo –constraints instance-type=my.xlargeequiv

    I think its also reasonable to expect that eventually maas will expose things like mem/cpu in its API as well (if it doesn’t already, I haven’t looked).

  8. Hi Jef

    1) At present, your only options on euca/openstack are the default-instance-type/default-image-id environment settings. They work (even if they’d be better named force-* than default-*), but they are really a poor substitute.

    2) We currently have a single “ec2″ provider, that can be specialised to work with other clouds that share an API. It’s not clear whether, or how, we should be splitting that up.

    3) Given that instance types vary across clouds, the instance-type constraint will be of limited utility when writing scripts that need to work against different clouds. This means that a user scripting against multiple clouds should favour arch/cpu/mem constraints (which will translate) over explicit instance-type constraints; but, assuming you eschew cloud-specific instance-type constraints, the cloud you’re targeting shouldn’t make any difference at all.

    4) On the understanding that this is *highly* subject to change, we’re currently leaning towards the idea of adding a “resource-info-uri” setting which points at a description of the environment’s resources in a provider-agnostic format; that is, essentially, a list of instance-types and images with capabilities/requirements. This lets us *expand* the set of relevant constraints, but it doesn’t make it very easy for a user to expose *arbitrary* constraints on their own private ec2-like cloud. (And we haven’t really considered how zones fit into all this… ec2′s per-account zone mappings are a touch inconvenient here.)

    However, I’m not sure that arbitrary constraints are a great fit for ec2-like private clouds in the first place: they seem like an idea far better suited to bare-metal deployments, so on that front your best bet is to keep an eye on MAAS development; I’m expecting awesome things to come out of that.

    I hope that clarifies things a little; did I miss anything?

  9. William,

    I take it the resource URI concept is something that will be centralized/maintained by Canonical and will define capabilities/constraints for public cloud providers.

    Consider providing a mechanism where local juju instances with access to a private cloud to copy/extend that resource URI in a way that provides local API override for private pre-deployment/development clouds which are meant to burst services into the cloud provider. ec2-like private clouds could certainly mimic amazon’s specific zone concepts. Even if its a noop that just logs a zone request as part of pre-deployment testing. Layered resource URI handling maybe were Canonical’s canonical resource URI defines the public clouds and then the local network’s resource URI handles making the local private cloud mimic the appropropriate public cloud target.


  10. Jef

    Thanks very much for the use case — I actually hadn’t considered zone constraints in that context, but I absolutely see where you’re coming from. We certainly have some way to go before we can support cross-cloud deployments, but I’ll do my best to figure out zone handling in a way that won’t cause problems later on ;) .

  11. Pingback: Ubuntu Weekly Newsletter Issue 262 | Ubuntu Linux FAQs

  12. You ll discover easy tips for getting started with your Rcm Bussiness. If you have some technical expertise when it comes to making money from your rcm bussiness, the basis of your payment always depend on the creative solutions you develop for your clients, subcontractors, and business meals. But you have to make after having children. Article writing may be the simplest and valued way to market a product which is already created.

  13. The reality is 4 out of 100 small buswinesses succeed beyond 10 years.
    What Visioning EntailsA va home loans qualificatons vision is more than one way that youu can use it
    to constructive ends, or you caan waste mind power annd time
    on useless arguments that go nowhere. There are a number of perfectly plausible explanations for not meeting their commitments; they have become experts at explaining away their va home loans
    qualifications failures.

  14. Greetings from Idaho! I’m bored to tears at work so
    I decided to browse your website on my iphone during lunch break.
    I really like the knowledge you present here and can’t wait to
    take a look when I get home. I’m shocked at how fast your
    blog loaded on my phone .. I’m not even using WIFI, just 3G ..

    Anyways, fantastic blog!

    my web site – top eleven hack (Ryder)

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>