Re: kill-controller, unregister, destroy-controller

2016-09-02 Thread Mark Ramm-Christensen (Canonical.com) 
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

Re: kill-controller, unregister, destroy-controller

2016-09-02 Thread Casey Marshall 
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

Re: kill-controller, unregister, destroy-controller

2016-09-02 Thread Nate Finch 
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

Re: kill-controller, unregister, destroy-controller

2016-09-02 Thread roger peppe 
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

2016-09-02 Thread roger peppe 
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-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>

--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/
mailman/listinfo/juju-dev
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: kill-controller, unregister, destroy-controller

2016-09-01 Thread Mark Ramm-Christensen (Canonical.com) 
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

2016-09-01 Thread Mark Ramm-Christensen (Canonical.com) 
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-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>> mailman/listinfo/juju-dev
>>>
>>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: kill-controller, unregister, destroy-controller

2016-09-01 Thread Tom Barber 
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

2016-09-01 Thread Nick Veitch 
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

2016-09-01 Thread Nick Veitch 
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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: kill-controller, unregister, destroy-controller

2016-09-01 Thread Marco Ceppi 
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

2016-09-01 Thread Marco Ceppi 
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-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: kill-controller, unregister, destroy-controller

2016-09-01 Thread Mark Ramm-Christensen (Canonical.com) 
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-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: kill-controller, unregister, destroy-controller

2016-09-01 Thread Mark Ramm-Christensen (Canonical.com) 
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

kill-controller, unregister, destroy-controller

2016-09-01 Thread Marco Ceppi 
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-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

kill-controller, unregister, destroy-controller

2016-09-01 Thread Marco Ceppi 
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