On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth <ian.bo...@canonical.com> wrote:
> So, I haven't been involved directly in a lot of the discussion, but my 2c > is: > > +1 to juju ensure-ha > > Users don't give a f*ck about how Juju achieves HA, they just want to know > their > data will survive a node outage. What Juju does under the covers to make > that > happen, what jobs are run on what nodes etc - that's for Juju to care > about. > 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. 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. I'm not really keen on ensure-ha due to the magical nature, but if it's just a stop gap... I guess. +1 to high level, namespaced services (juju:api, juju:db etc) > > This is a step above ensure-ha for more advanced users, but one which still > presents the solution space in terms any IS person involved in managing > things > like scalable web services understands. ie there's the concept of services > which > process requests and those which store data, and those which <insert role > here>. > If the volume of incoming requests are such that the load on the api > servers is > high while the database is still coping ok, "juju add-unit juju:api -n 3" > can be > used to solve that efficiently, and vice versa. So it's all about mapping > what > Juju does to terms and concepts already understood, and getting the level > of > abstraction correct so the solution is usable by the target audience. > > Anything that involves exposing things like jobs etc is not the right way > of > looking at it IMO. > 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. Cheers, Andrew
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
