On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) < mark.ramm-christen...@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.ce...@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@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@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@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@ubuntu:~# juju bootstrap cabs azure >> ERROR controller "cabs" already exists >> ``` >> >> Marco >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >>
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev