kill-controller, unregister, destroy-controller
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] ... 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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: kill-controller, unregister, destroy-controller
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. On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi 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] > > ... > > 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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: kill-controller, unregister, destroy-controller
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 > 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] >> >> ... >> >> 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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: kill-controller, unregister, destroy-controller
On 1 September 2016 at 14:59, 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. > I agree, though actually all that happens is that after a while people type ' juju destroy-controller --destroy-all-models mycontroller' without thinking. Perhaps it would be better to have a confirmation: juju destroy-controller mycontroller This command will also destroy the following models: mymodel, myimportantmodel Proceed (y/n)? -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: kill-controller, unregister, destroy-controller
If you have models it just doesn't work. so it's actually more "life support" than slow death On 1 Sep 2016 15:05, "Marco Ceppi" 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 >> 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] >>> >>> ... >>> >>> 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 mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: kill-controller, unregister, destroy-controller
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 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 >> 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] >>> >>> ... >>> >>> 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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: kill-controller, unregister, destroy-controller
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 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 >> 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] >>> >>> ... >>> >>> 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
Re: kill-controller, unregister, destroy-controller
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 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 > 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 >>> 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] ... 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 Un
Re: kill-controller, unregister, destroy-controller
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 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 > 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 >>> 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] ... 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. ER
Re: kill-controller, unregister, destroy-controller
Exactly. On Friday, September 2, 2016, Casey Marshall 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 > 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 > > 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 >>> > 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] > > ... > > 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 include
Re: kill-controller, unregister, destroy-controller
On 2 September 2016 at 22:24, Nate Finch wrote: > > 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. > How about the other way around? Put blocks on controllers by default, with an option to create one without the block for ephemeral setups. This way 'destroy-controller' doesn't need any options or second guessing, because the user has already declared if it is important or not. -- Stuart Bishop -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju