-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-11-08 14:15, roger peppe wrote: > On 8 November 2013 08:47, Mark Canonical Ramm-Christensen > <mark.ramm-christen...@canonical.com> wrote: >> I have a few high level thoughts on all of this, but the key >> thing I want to say is that we need to get a meeting setup next >> week for the solution to get hammered out. >> >> First, conceptually, I don't believe the user model needs to >> match the implementation model. That way lies madness -- users >> care about the things they care about and should not have to >> understand how the system works to get something basic done. >> See: >> http://www.amazon.com/The-Inmates-Are-Running-Asylum/dp/0672326140 >> for reasons why I call this madness. >> >> For that reason I think the path of adding a --jobs flag to >> add-machine is not a move forward. It is exposing implementation >> detail to users and forcing them into a more complex conceptual >> model. >> >> Second, we don't have to boil the ocean all at once. An >> "ensure-ha" command that sets up additional server nodes is >> better than what we have now -- nothing. Nate is right, the box >> need not be black, we could have an juju ha-status command that >> just shows the state of HA. This is fundamentally different >> than changing the behavior and meaning of add-machines to know >> about juju jobs and agents and forcing folks to think about >> that. >> >> Third, we I think it is possible to chart a course from ensure-ha >> as a shortcut (implemented first) to the type of syntax and >> feature set that Kapil is talking about. And let's not kid >> ourselves, there are a bunch of new features in that proposal: >> >> * Namespaces for services * support for subordinates to state >> services * logging changes * lifecycle events on juju "jobs" * >> special casing the removal of services that would kill the >> environment * special casing the stats to know about HA and warn >> for even state server nodes >> >> I think we will be adding a new concept and some new syntax when >> we add HA to juju -- so the idea is just to make it easier for >> users to understand, and to allow a path forward to something >> like what Kapil suggests in the future. And I'm pretty solidly >> convinced that there is an incremental path forward. >> >> Fourth, the spelling "ensure-ha" is probably not a very good >> idea, the cracks in that system (like taking a -n flag, and >> dealing with failed machines) are already apparent. >> >> I think something like Nick's proposal for "add-manager" would be >> better. Though I don't think that's quite right either. >> >> So, I propose we add one new idea for users -- a state-server. >> >> then you'd have: >> >> juju management --info juju management --add juju management >> --add --to 3 juju management --remove-from > > This seems like a reasonable approach in principle (it's > essentially isomorphic to the --jobs approach AFAICS which makes me > happy). > > I have to say that I'm not keen on using flags to switch the basic > behaviour of a command. The interaction between the flags can then > become non-obvious (for example a --constraints flag might be > appropriate with --add but not --remove-from). > > Ah, but your next message seems to go along with that. > > So, to couch your proposal in terms that are consistent with the > rest of the juju commands, here's how I see it could look, in terms > of possible help output from the commands: > > usage: juju add-management [options] purpose: Add Juju management > functionality to a machine, or start a new machine with management > functionality. Any Juju machine can potentially participate as a > Juju manager - this command adds a new such manager. Note that > there should always be an odd number of active management machines, > otherwise the Juju environment is potentially vulnerable to > network partitioning. If a management machine fails, a new one > should be started to replace it.
I would probably avoid putting such an emphasis on "any machine can be a manager machine". But that is my personal opinion. (If you want HA you probably want it on dedicated nodes.) > > options: --constraints (= ) additional machine constraints. > Ignored if --to is specified. -e, --environment (= "local") juju > environment to operate in --series (= "") the Ubuntu series of the > new machine. Ignored if --to is specified. --to (="") the id of the > machine to add management to. If this is not specified, a new > machine is provisioned. > > usage: juju remove-management [options] <machine-id> purpose: > Remove Juju management functionality from the machine with the > given id. The machine itself is not destroyed. Note that if there > are less than three management machines remaining, the operation of > the Juju environment will be vulnerable to the failure of a single > machine. It is not possible to remove the last management machine. > I would probably also remove the machine if the only thing on it was the management. Certainly that is how people want us to do "juju remove-unit". > options: -e, --environment (= "local") juju environment to operate > in > > As a start, we could implement only the add-management command, and > not implement the --to flag. That would be sufficient for our HA > deliverable, I believe. The other features could be added in time > or according to customer demand. The main problem with this is that it feels slightly too easy to add just 1 machine and then not actually have HA (mongo stops allowing writes if you have a 2-node cluster and lose one, right?) John =:-> > >> I know this is not following the add-machine format, but I think >> it would be better to migrate that to something more like this: >> >> juju machine --add > > If we are going to do that, I think we should probably change all > the commands at once - consistency is good. > > If we do the above, could we drop "juju ensure-ha" entirely, given > the fact that the above commands are both easier to implement (I > think!) and more powerful? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Cygwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ8vYQACgkQJdeBCYSNAAMv7ACeJ7N8g5MeV3XE230/qjAcYE8m kUgAoLrJ0L1vD9zzszwgFHgI8G/gomJO =rl+3 -----END PGP SIGNATURE----- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
