<div dir="ltr">On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<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">So, I haven't been involved directly in a lot of the discussion, but my 2c is:<br>

<br>
+1 to juju ensure-ha<br>
<br>
Users don't give a f*ck about how Juju achieves HA, they just want to know their<br>
data will survive a node outage. What Juju does under the covers to make that<br>
happen, what jobs are run on what nodes etc - that's for Juju to care about.<br></blockquote><div> </div><div>I'm not so sure about that. I expect there'll be users who wants to know *exactly* how it works, because otherwise they won't feel they can trust it with their services. That's not to say that ensure-ha can't be trusted - just that some users will want to know what it's doing under the covers. Speculative, but based on past experience with banks, insurance companies, etc.<br>
</div><div><br></div><div>Another thing to consider is that one person's HA is not the next person's. I may want to disperse my state servers across multiple regions (were that supported); you might find this costs too much in inter-region traffic. What happens if I have a temporary outage in one region - where does ensure-ha automatically spin up a new one? What happens when the original comes back? Each of these things are things people may want to do differently, because they each have different trade-offs.</div>
<div><br></div><div>I'm not really keen on ensure-ha due to the magical nature, but if it's just a stop gap... I guess.</div><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">

+1 to high level, namespaced services (juju:api, juju:db etc)<br>
<br>
This is a step above ensure-ha for more advanced users, but one which still<br>
presents the solution space in terms any IS person involved in managing things<br>
like scalable web services understands. ie there's the concept of services which<br>
process requests and those which store data, and those which <insert role here>.<br>
If the volume of incoming requests are such that the load on the api servers is<br>
high while the database is still coping ok, "juju add-unit juju:api -n 3" can be<br>
used to solve that efficiently, and vice versa. So it's all about mapping what<br>
Juju does to terms and concepts already understood, and getting the level of<br>
abstraction correct so the solution is usable by the target audience.<br>
<br>
Anything that involves exposing things like jobs etc is not the right way of<br>
looking at it IMO.<br></blockquote><div><br></div><div>I had suggested something very similar (add-machine --state) at SFO to what Roger's suggested, but I can see the arguments against it. Overloading add-unit seems like a decent alternative.</div>
<div><br></div><div>Cheers,</div><div>Andrew</div></div></div></div>