<div dir="ltr">I think this is interesting, but there are a few bits of fallout we need to consider.<div><br></div><div>1) Just today I failed to bootstrap trunk with:</div><div>2014-06-14 04:11:47 ERROR juju.provider.common bootstrap.go:119 bootstrap failed: cannot start bootstrap instance: cannot run instances: The requested Availability Zone is currently constrained and we are no longer accepting new customer requests for t1/m1/c1/m2/m3 instance types. Please retry your request by not specifying an Availability Zone or choosing us-east-1c, us-east-1d, us-east-1e. (Unsupported)<br>
</div><div><br></div><div>My guess is that we used to not specify the AZ, so Amazon would just shuffle us off to whatever AZ wasn't overloaded. Now that we are picking one, it has a higher chance to fail.</div><div><br>
</div><div>2) If you have 2 services, you likely would rather them on the same AZ rather than spread across different AZ because of the different cost of network bandwidth. How do we manage multiple services? Do we just use a strictly deterministic ordering? (always sort the AZ names, round robin starting with the first one?)</div>
<div><br></div><div>I'm a bit concerned because of (1) that we'll again "deterministically fail". :)</div><div><br></div><div>John</div><div>=:-></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Jun 13, 2014 at 6:45 PM, Kapil Thangavelu <span dir="ltr"><<a href="mailto:kapil.thangavelu@canonical.com" target="_blank">kapil.thangavelu@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Fri, Jun 13, 2014 at 12:23 AM, Andrew Wilkins <span dir="ltr"><<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>I'm pleased to say that availability zone support for AWS and OpenStack has now landed on trunk, and will be available in 1.19.4. I'll write a blog post and maybe even some docs about it, but for now here's a brief description how you can use this feature.</div>
<div><br></div><div>FYI: not all OpenStacks are created equal. Yours may not support availability zones. HP's revamped HP Cloud offering does offer several availability zones in the US West region.</div><div><br></div>
<div>Explicit AZs</div><div>=========</div><div><br></div><div>When bootstrapping or adding a machine, you can specify the availability zone explicitly as a placement directive. e.g.<br></div><div><br></div><div> juju bootstrap --to zone=us-east-1b</div>
<div> juju add-machine zone=us-east-1c<br></div><div><br></div></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div></div><div><div>Automatic AZ spread</div><div>================</div></div><div><br></div><div>TL;DR: "juju deploy -n 10 <service>" will automatically and uniformly distribute the units to instances spread across the AZs within the region. Assuming the charm and service being charmed is well written, then you should be able to rest assured that IaaS downtime will not affect your application.</div>
<div><br></div><div>When adding machines without an AZ explicitly specified, or when adding units to a service, the ec2 and openstack providers will now automatically spread instances across all available AZs in the region. The spread is based on density of instance "distribution groups".</div>
<div><br></div><div>State servers compose a distribution group: when doing "juju ensure-availability", state servers will be spread across AZs. Each deployed service (e.g. mysql, redis, whatever) composes a separate distribution group; the AZ spread of one service does not affect the AZ spread of another service.</div>
<div><br></div></div></blockquote><div><br></div></div></div><div><div><br>Awesome, that's a pretty nice and simple abstraction.</div><div><br></div><div>Two caveats to be aware of, This potentially can cause an issue with our ongoing work for vpc support as subnets are bound to azs, but i may have azs without subnets in them. Also there are diminishing returns on azs, ie. most people don't use more than three for an app, even though they may have up to 5 available to them in a region. maximal az usage actually increases app likelihood of dealing with az outage or network partition. As noted privately, some services will still want explicit placement instead of implicit.</div>
<span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-k</div><div><br></div><div><br></div><div><br></div></font></span></div></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div>