On 8 November 2013 11:31, Gustavo Niemeyer <gust...@niemeyer.net> wrote: > These are *very* good points, Mark. Taking them to heart will > definitely lead into a good direction for the overall feature > development. > > It sounds like we should avoid using a "management" command for > anything in juju, though. Most things in juju are about management one > way or the other, so "juju management" becomes very unclear and hard > to search for. > > Instead, the command might be named after what we've been calling them: > > juju add-state-server -n 2
I'm not sure that state-server is the right name here. For a start there are two kinds of state servers, mongo and API, which we may want to scale independently as they have totally different characteristics, and the management workers (provisioner, etc) also fall under the same umbrella. "Management" has been the best I've seen so far, though I do realise it is overly generic. Other suggestions? Are you suggesting that we also have "destroy-state-server", BTW? > It's easy to error if current + n is not a good number. That seems reasonable. Do you think this needs to be transactional? That is, if current is 2 and two people concurrently do add-state-server -n 1, should one of those requests necessarily fail? My inclination is we don't need to worry too much - but YMMV. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
