13 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?

   -jef

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.

   -jef

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.

   -jef

7. All constraints currently implemented are documented here:

   https://juju.ubuntu.com/docs/constraints.html

   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.

   -jef

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. It’s fantastic that you are getting thoughts from this paragraph as well as from our discussion made at this place.

13. If you want to get a good deal from this piece of
    writing then you have to apply these techniques to your won
    webpage.