kill-controller, unregister, destroy-controller

[Marco Ceppi]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160901/dbd65df7/attachment.html>