adding placement directives for ensure-availability

[Gustavo Niemeyer]

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