kill-controller, unregister, destroy-controller
Mark Ramm-Christensen (Canonical.com)
mark.ramm-christensen at canonical.com
Thu Sep 1 13:59:15 UTC 2016
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.
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-dev/attachments/20160901/568fb179/attachment.html>
More information about the Juju-dev
mailing list