My main use case for killing controllers is development & testing. For this, I have a script that force deletes all the juju-* LXC containers, and then unregisters all controllers with cloud: lxd. It's *much* faster than waiting for each juju controller to tear itself down. It's also nothing I'd provide casually to end users.
I think it should be possible, but not trivial, to destroy controllers and everything in them. It's not a bad thing to have to type a long command or flag name to do something so destructive -- or write a script to do precisely what I want. Feels like my use case for destroying controllers isn't really as a normal Juju user -- I'm (ab)using Juju with a developer & QA tester's mindset. -Casey On Fri, Sep 2, 2016 at 6:15 AM, roger peppe <[email protected]> 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)" < > [email protected]> 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 <[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/mailm >>>> an/listinfo/juju-dev >>>> >>>> > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/juju-dev > > > > -- > 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
