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-christen...@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.ce...@canonical.com> wrote: > 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-...@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/juju-dev >>> >>> -- Juju-dev mailing list juju-...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/juju-dev
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
