unable to specify availability zone

Isn't this 'region'?

I don't think so, I tried to set the region as "us-east-1c" and got:

error: invalid region name "us-east-1c"

Note 'c' is the availability zone. Availability zones are distinct from regions in AWS, see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

This is an interesting use case that we hadn't considered, but I'm not sure we're in a position to support it in the immediate future; the most significant issue is that it's a provider-specific constraint; and each of those comes with a cost: that, while it makes juju more immediately valuable to a small number of people, it makes juju less valuable to everyone long-term, because it's a clear failure to express the concepts important to the user in a portable way.

So, "ec2-zone" is much too specific, and even "availability-zone" still isn't quite good enough; but, maybe, the ideas of "risk diversification" and "network distance" might effectively express the high-level goals enabled by zones, but in a manner suitable for use across clouds. We have mid-term plans to address both of these, but I'm not sure how well they address your use case; if you can spare the time, I'd like to know a little bit more about what you're doing, in case we can still come up with some neat refinement that solves your problems.

The reason we are using this is to have spread instances between Amazon HA zones (until Juju learns to do this itself). It works, although it makes juju status and juju-gui output harder to view.

The workaround is like this:

juju deploy --config config.yaml --constraints ec2-zone=a haproxy haproxy-a
juju deploy --config config.yaml --constraints ec2-zone=b haproxy haproxy-b

juju deploy --config config.yaml --repository charms --constraints ec2-zone=a local:apache2 apache-a
juju deploy --config config.yaml --repository charms --constraints ec2-zone=b local:apache2 apache-b

juju add-relation apache-a:balancer haproxy-a:website
juju add-relation apache-a:balancer haproxy-b:website

juju add-relation apache-b:balancer haproxy-a:website
juju add-relation apache-b:balancer haproxy-b:website

Please add support for ec2 zones again until there is another way to do this.

Thus, for us, this is a blocker currently for moving from juju to juju-core.

This should also cover ec2-instance-type as a constraint, generics aren't capable of distinguishing from several of the available instances, nor is it the most common form of addressing. (ie. go look up instance type definitions, and find an unambigious form spelling that with generics, vs just specifying the thing you want)

This is currently the last major issue wrt to pyjuju parity (generically provider specific constraints). Its absolutely nesc for a best practice cloud deployment to spread the app across zones. For now i suggest just ec2-zone, ec2-instance-type... people can hot swap service constraints.. Things like ec2-balanced can come later.

A missing availability zone constraint is a huge problem with regard to reserved instances. Reserved instances save a lot of money but they are bound to a specific availability zone. I cannot take advantage of that without explicit az placement of a machine.

So, even if juju was smart about spreading instances across az's it may still get it wrong as far as reserved instances are concerned.

Sadly, this is a blocker for us, too.

I suggest the following solution:
The availability zone is not really a service or environment constraint and as such not a constraint at all (I understand that constraints work only on these two levels). Rather it is related to the assignment of a unit to a machine which we'd like to require to be in a certain az. Thus, the new "--to" parameter seems a good place.

I suggest adding a new format to the --to parameter (used by deploy and add-unit) to specify the az instead of a specific machine. Since it is either one or the other, there shouldn't be an overlap. It depends on what the user is concerned about. So the calls would look like that:

juju deploy --to az:a mongodb
juju add-unit --to az:b mongodb

I'd also be happy to number the az's (1,2,3) and have the specific environment implementation translate as required (a,b,c for ec2). Environments that do not have az's simply ignore this parameter.

If we can agree to this I'd rename this bug accordingly as it is not about constraints anymore. If there really is an issue about specifying the instance type as a constraint, it should get its own bug. (I am happy with the generic constraints)

Sounds like a good idea. That would avoid e.g. apache-a and apache-b services in case you don't mind cross AZ network traffic.

Here we are talking about being able to specify provider/environment specific constraints. Which would spell this something like:

 juju deploy mongod --to amazon:us-east-1b

Yes, that would work for me, too. Fits in better with "lxc:"

Just an up vote for this. We are blocked on using this in production as well. EC2 highly recommends spreading out over multiple AZ's.

we need this for cloud foundry.. specifically to pin a service to an az (they use a separate service for each az and route appropriately in the app layer for failover).

Support for explicit AZ placement is available on trunk now, and will be in 1.19.4/1.20.0. Support for automatic spread across zones is in the works, and will hopefully be available at the same time.

Support for AZ constraints has not been implemented, so there will not be a way to pin an entire service to an AZ (yet?)

Hey Andrew, great news!

As mentioned before, I don't believe that service constraints are the right place for az placement. Spreading of units rather than concentration will be the most likely reason for wanting to specifying the az. So not being able to pin a service to an az is not a great loss in my eyes.

@Henning: no worries, mainly just wanted to make sure Kapil was aware of what is and isn't being done here.

FYI, automatic zone spread has just landed on trunk.

@hazmat: can you please log a separate issue detailing your requirements for AZ service constraints?

@axwalk filed bug:1360607 for az via constraints