Exactly. On Friday, September 2, 2016, Casey Marshall <[email protected]> wrote:
> 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] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) < >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[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] >>>> <javascript:_e(%7B%7D,'cvml','[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] >>>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/juju-dev >>>>> >>>>> >> >> -- >> Juju-dev mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju-dev >> >> >> >> -- >> Juju-dev mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju-dev >> >> > -- --Mark Ramm (mobile edition)
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
