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 <[email protected]> wrote: > On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) < > [email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >>> mailman/listinfo/juju-dev >>> >>>
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
