kill-controller, unregister, destroy-controller

Fri Sep 2 17:33:36 UTC 2016

Exactly.

On Friday, September 2, 2016, Casey Marshall <casey.marshall at canonical.com>
wrote:

> My main use case for killing controllers is development & testing. For
> this, I have a script that force deletes all the juju-* LXC containers, and
> then unregisters all controllers with cloud: lxd. It's *much* faster than
> waiting for each juju controller to tear itself down. It's also nothing I'd
> provide casually to end users.
>
> I think it should be possible, but not trivial, to destroy controllers and
> everything in them. It's not a bad thing to have to type a long command or
> flag name to do something so destructive -- or write a script to do
> precisely what I want. Feels like my use case for destroying controllers
> isn't really as a normal Juju user -- I'm (ab)using Juju with a developer &
> QA tester's mindset.
>
> -Casey
>
> On Fri, Sep 2, 2016 at 6:15 AM, roger peppe <roger.peppe at canonical.com
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>> <javascript:_e(%7B%7D,'cvml','Juju-dev at lists.ubuntu.com');>
>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>> an/listinfo/juju-dev
>>>>>
>>>>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> <javascript:_e(%7B%7D,'cvml','Juju-dev at lists.ubuntu.com');>
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> <javascript:_e(%7B%7D,'cvml','Juju-dev at lists.ubuntu.com');>
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>

-- 
--Mark Ramm (mobile edition)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160902/5da430ab/attachment.html>