adding placement directives for ensure-availability

[Nate Finch]

Sorry I didn't list out the full details of the placement directives.  It's
basically just a subset of what is allowed for juju deploy:

A directive for ensure-availability is

> <container_type> | <container_type>:<machine_id> | <maas_node_name> |
> "default"


A lone container type indicates juju should create a new machine with a
container of the specified type, and put the state server in that container.

If you have a container type with a machine id specified, it'll create a
new container on that machine and put the state server in that container.

If you specify maas node name, the maas node with that name will be added
to the environment and used for the state server.

Note that the above is already all implemented by the placement directive
code, the ensure-availability code just needs to be tweaked so that it'll
work correctly (currently, only maas node name is supported by
ensure-availability).

If you specify "default", it'll use the default placement policy of
creating a new machine and putting the state server on that machine.  This
is a new placement directive that we're suggesting because of the unique
problems when specifying multiple placement directives for a single
command. I'm open to calling this something other than "default" if someone
has a better idea.

ensure-availability --to takes a comma-delimited list of these directives,
one per state server that is to be created.


As for the changes to the CLI, it is orthogonal to this feature request.
It actually has almost nothing to do with this, other than the fact that
this particular flag demonstrates one of the ways the current UX is
sub-optimal.  The implementation for this feature is required to satisfy
Landscape's needs, regardless of what the UX looks like.



On Tue, Feb 24, 2015 at 2:20 PM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> That doesn't seem to address either point.
>
> 1) What's the full format of the parameter of --to, with all possible
> details?
>
> 2) Why is a hack being considered, when we don't even know what the
> alternative design would look like? If we don't know how it would look
> like, we cannot really compare how hard it would be to implement it.
>
>
> On Tue, Feb 24, 2015 at 4:16 PM, Nate Finch <nate.finch at canonical.com>
> wrote:
> > Briefly, the problem with ensure-availability is that it does too much.
> It
> > converts a non-HA environment into an HA environment.  If you're already
> in
> > HA and you specify a larger number of servers, it'll add servers.  If
> some
> > servers are down, it'll start new ones and remove the down ones.
> >
> > There are plans to split the command into multiple commands, so that
> it's a
> > little easier to understand what it'll do in any particular case.
> However,
> > that work is much bigger than what we are proposing here.
> >
> > This proposal simply fixes a use case that is tripping up the Landscape
> > team, which is that they want to make their deployment more dense... with
> > the option to replace a downed state server with a container on an
> existing
> > machine in the environment.
> >
> > On Tue, Feb 24, 2015 at 12:40 PM, Gustavo Niemeyer
> > <gustavo.niemeyer at canonical.com> wrote:
> >>
> >> Hi Nate,
> >>
> >> On Tue, Feb 24, 2015 at 2:24 PM, Nate Finch <nate.finch at canonical.com>
> >> wrote:
> >> (...)
> >> > To support this, we need a way to say "use the default placement
> >> > policy".
> >> > For this, we propose the keyword "default".  Thus, to fix the above
> >> > example,
> >> > Bill would type this:
> >> >
> >> >> $ juju ensure-availability --to lxc:1,default
> >> >> <success output here>
> >>
> >> What's the full format of the parameter of --to, with all possible
> >> details?
> >>
> >> > Note that this change in no way fixes all of HA's UX problems, and
> that
> >> > it
> >> > actually makes some of the problems a lot more obvious (such as the
> fact
> >> > that the number of placements you need can be different even for the
> >> > same
> >> > command, depending on the state of the environment).  This will be
> fixed
> >> > when we revamp the CLI, but for now we'll have to live with it.
> >>
> >> I don't have much context on the problem, but it seems like the
> >> proposal is a change in the design of the CLI. If there are known
> >> problems on the current design, the change might well fix it instead
> >> of making it worse?
> >>
> >>
> >> gustavo @ http://niemeyer.net
> >
> >
>
>
>
> --
> gustavo @ http://niemeyer.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150224/41de4b09/attachment.html>