kill-controller, unregister, destroy-controller

Nate Finch nate.finch at canonical.com
Fri Sep 2 15:24:41 UTC 2016


This is one of the reasons we always make you type out the controller name
for destroy controller.  Because

juju destroy-controller production-website

should ring a bell.  Simply adding a long flag doesn't really help you
remember if you're killing something important or not, because you always
have to type the same flag for every controller.

This is also why I just always use kill-controller... it's like
destroy-controller --destroy-all-models except you don't need the flag and
it's easier to type even disregarding the flag.  I'm sure I'm not the only
one that will figure this out and just avoid destroy-controller, which
defeats the purpose of trying to make it safer.

I agree with Roger.... we should be encouraging people to put blocks on
important controllers, and not rely on typing out long things that aren't
actually helpful.



On Fri, Sep 2, 2016 at 7:16 AM roger peppe <roger.peppe at canonical.com>
wrote:

> It seems to me that this kind of thing is exactly what "blocks" are
> designed for. An explicit unblock command seems better to me than either an
> explicit flag or an extra prompt, both of which are vulnerable to typing
> without thinking. Particularly if "throwaway" controllers created for
> testing purposes are not blocked by default, so you don't get used to to
> typing "unblock" all the time.
>
> On 1 Sep 2016 16:14, "Mark Ramm-Christensen (Canonical.com)" <
> mark.ramm-christensen at canonical.com> wrote:
>
> I get the desire to remove friction everywhere we can, but unless
> destroying controllers is a regular activity, I actually think SOME
> friction is valuable here.
>
> If controllers are constantly getting into a wedged state where they must
> be killed, that's likely a product of a fast moving set of betas, and
> should be addressed *directly* rather than as they say "applying lipstick
> to a pig"
>
> On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi <marco.ceppi at canonical.com>
> wrote:
>
>> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
>> mark.ramm-christensen at canonical.com> wrote:
>>
>>> I believe keeping the --destroy-all-models flag is helpful in keeping
>>> you from accidentally destroying a controller that is hosting important
>>> models for someone without thinking.
>>>
>>
>> What happens if I destroy-controller without that flag? Do I have to go
>> into my cloud portal to kill those instances? Is there any way to recover
>> from that to get juju reconnected? If not, it's just a slower death.
>>
>>
>>> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi <marco.ceppi at canonical.com>
>>> wrote:
>>>
>>>> Hey everyone,
>>>>
>>>> I know we've had discussions about this over the past few months, but
>>>> it seems we have three commands that overlap pretty aggressively.
>>>>
>>>> Using Juju beta16, and trying to 'destroy' a controller it looks like
>>>> this now:
>>>>
>>>> ```
>>>> root at ubuntu:~# juju help destroy-controller
>>>> Usage: juju destroy-controller [options] <controller name>
>>>>
>>>> ...
>>>>
>>>> Details:
>>>> All models (initial model plus all workload/hosted) associated with the
>>>> controller will first need to be destroyed, either in advance, or by
>>>> specifying `--destroy-all-models`.
>>>>
>>>> Examples:
>>>>     juju destroy-controller --destroy-all-models mycontroller
>>>>
>>>> See also:
>>>>     kill-controller
>>>>     unregister
>>>> ```
>>>>
>>>> When would you ever want to destroy-controller and not
>>>> destroy-all-models? I have to specify that flag everytime, it seems it
>>>> should just be the default behavior. Kill-controller seems to do what
>>>> destroy-controller --destroy-all-models does but more aggressively?
>>>>
>>>> Finally, unregister and destroy-controller (without
>>>> --destroy-all-models) does the same thing. Can we consider dropping the -
>>>> very long winded almost always required - flag for destroy-controller?
>>>>
>>>> Finally, there used to be a pretty good amount of feedback during
>>>> destroy-controller, while it was rolling text, I at least knew what was
>>>> happening. Now it's virtually silent. Given it runs for quite a long time,
>>>> can we get some form of feedback to the user back into the command?
>>>>
>>>> ```
>>>> root at ubuntu:~# juju destroy-controller --destroy-all-models cabs
>>>> WARNING! This command will destroy the "cabs" controller.
>>>> This includes all machines, applications, data and other resources.
>>>>
>>>> Continue? (y/N):y
>>>> ERROR failed to destroy controller "cabs"
>>>>
>>>> If the controller is unusable, then you may run
>>>>
>>>>     juju kill-controller
>>>>
>>>> to forcibly destroy the controller. Upon doing so, review
>>>> your cloud provider console for any resources that need
>>>> to be cleaned up.
>>>>
>>>> ERROR cannot connect to API: unable to connect to API: websocket.Dial
>>>> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no
>>>> route to host
>>>> root at ubuntu:~# juju kill-controller cabs
>>>> WARNING! This command will destroy the "cabs" controller.
>>>> This includes all machines, applications, data and other resources.
>>>>
>>>> Continue? (y/N):y
>>>> Unable to open API: open connection timed out
>>>> Unable to connect to the API server. Destroying through provider.
>>>> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh:
>>>> Failure sending request for Service Principal
>>>> 83d638b0-841c-4bd1-9e7c-868cae3393f4: StatusCode=0 -- Original Error: http:
>>>> nil Request.URL
>>>> root at ubuntu:~# juju bootstrap cabs azure
>>>> ERROR controller "cabs" already exists
>>>> ```
>>>>
>>>> Marco
>>>>
>>>> --
>>>> Juju-dev mailing list
>>>> Juju-dev at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>
>>>>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160902/14375f04/attachment.html>


More information about the Juju mailing list