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 .

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

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?

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).