On 07/11/13 09:11, David Cheney wrote: > +1 (million), this solution keeps coming up, and I still feel it is > the right one. > > On Thu, Nov 7, 2013 at 7:07 AM, Kapil Thangavelu > <[email protected]> wrote: >> >> instead of adding more complexity and concepts, it would be ideal if we >> could reuse the primitives we already have. ie juju environments have three >> user exposed services, that users can add-unit / remove-unit etc. they have >> a juju prefix and therefore are omitted by default from status listing. >> That's a much simpler story to document. how do i scale my state server.. >> juju add-unit juju-db... my provisioner juju add-unit juju-provisioner. >> >> -k
NOTE: removed [email protected] from the recipients; PLEASE DON'T CROSS-POST Seriously! For future direction I agree with this. We talked about the idea behind having the core parts of juju exposed as special services with units. We talked about using namespaces. I recall that Gustavo's point at the time is that we don't *need* this to get HA, and that we can get HA much simpler to start with. I fully support an approach where we have a simple command to get us over the initial hump of managing support. juju ensure-ha (note: not ensure-ha-state) This brings up multiple manager nodes. I like the idea that we treat manager nodes as special, and that destroy-machine on them doesn't work the same way. Consider this: juju boostrap juju ensure-ha later machine-2 (a manager node goes down) juju ensure-ha removes machine-2, and brings up machine-x to take it's place. I was talking with William, and I think we both agreed that we don't want to restart manager nodes by magic, but wait for user intervention. Now, looking to the future: We would have services like: juju:db juju:api juju:something-else (for the other manager worker tasks) bootstrap would then give machine-0 with a unit of each of these. ensure-ha would bring up new machines with units of each of these. A user could add two more api servers by going: juju add-unit juju:api -n 2 I think this gives us a clean, and understandable way of doing things, but we SHOULD NOT do this first. Tim -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
