This is one of the reasons we always make you type out the controller name for destroy controller. Because
juju destroy-controller production-website should ring a bell. Simply adding a long flag doesn't really help you remember if you're killing something important or not, because you always have to type the same flag for every controller. This is also why I just always use kill-controller... it's like destroy-controller --destroy-all-models except you don't need the flag and it's easier to type even disregarding the flag. I'm sure I'm not the only one that will figure this out and just avoid destroy-controller, which defeats the purpose of trying to make it safer. I agree with Roger.... we should be encouraging people to put blocks on important controllers, and not rely on typing out long things that aren't actually helpful. On Fri, Sep 2, 2016 at 7:16 AM roger peppe <roger.pe...@canonical.com> wrote: > 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/mailman/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-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
