Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-07 12:40 AM, John Meinel wrote:
> 2. We move CI towards making kill-controller fail the test suite.
> If destroy doesn't do everything they want, then we have a bug and
> it should be telling developers that.

e.g. exit status 0 = "I successfully destroyed without resorting to
the provider", status 1 = "I had to resort to the provider to
destroy", status 2+ = "I did not destroy"?

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBmk4AAoJEK84cMOcf+9hjwgH/RqcX5OqVKx7SoxCbjnbj7sk
O5UKWCbn00F2LsGxfuwM3jL94dXFO0q854BHWSBsjOJUD3i4CdKAlI9MYBkCYOk6
CEYnG8U+12LG+g56tAVEGLhYJ/wlA7hJVr/64xlQw1AiNliqKpNWaLftTMGUs6DC
gUQ06EEqkrFQwyh6A0DB0c5FbpX9sA5W+TpGsJJz+TTsJVxBycaLJQF06ZbyxREX
LEar/v8sr+4uZia+OrJofynGUVxt5Ub6p4+XNBnMF4oWkg2kYjmTNnGduUFv9mKk
bLuIYrOJzz6l8ZiTn6VrPI7Ztad+6+CIPcITaw+s3wMZ8pCT0zRNNk6OxZREXcs=
=hyhy
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[roger peppe]

My 2p:

FWIW I also would have no idea which was stronger, kill-controller
or destroy-controller. Assuming we do really want a separate command,
a variant of "destroy-controller" might be more intuitive, e.g.
"destroy-controller-with-prejudice", "destroy-controller-regardless"...

If fact I think this command will always need to remain around
and available to normal users, because people will always have
ways of managing instances behind Juju's back.
For example, people can terminate ec2 instances directly in the AWS console - it
might be inadvisable but it happens. The cloud is a complex
environment and things can fail (even if we write Juju perfectly)
in many ways.

My vote would be for a single command (destroy-controller)
which attempts to "do the right thing"
in all circumstances. Before attempting the shutdown and before
prompting the user for confirmation, it would try to connect to the API.
If it fails to connect to the API, the interactive confirmation prompt
would say something like "Cannot connect to controller. Do you want
to forcefully destroy all instances and other associated resources?",
different from the usual prompt.

With the --force flag, it would also try to connect to the controller
before destroying resources (same as kill-controller now).
With -y but without --force, it would not fall back to destroying
resources directly.

That way the confirmation message actually contains some useful info -
you get some feedback as to what's going on and we don't have
two subtly differently named commands.

  cheers,
rog.

On 7 April 2016 at 05:54, Andrew Wilkins  wrote:
> On Thu, Apr 7, 2016 at 12:40 PM John Meinel  wrote:
>>
>> Another aspect of this is actually that we made kill-controller "safe".
>> The fact that it does a "clean" shutdown first and then tries harder means I
>> have little motivation to use anything else. Also, for whatever reason I
>> find kill-controller easier to remember and type.
>>
>> Given Rick's fair position that having to kill I'd a sign of failure on
>> our part, what if:
>> 1. We stop being safe. People will be forced into a juju
>> destroy-controller || juju kill-controller position but that let's us
>> separate concerns.
>> 2. We move CI towards making kill-controller fail the test suite. If
>> destroy doesn't do everything they want, then we have a bug and it should be
>> telling developers that.
>
> SGTM. That will go further to discouraging kill-controller except when
> really necessary.
>>
>> 3. I personally like "forget-controller" over purge, and I don't like
>> "destroy, but don't actually destroy" type of forgetting.
>>
>> John
>> =:->
>>
>> On Apr 7, 2016 4:36 AM, "Rick Harding"  wrote:
>>>
>>>
>>>
>>> On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins
>>>  wrote:

 On Wed, Apr 6, 2016 at 11:28 PM Rick Harding
  wrote:
>
> I strongly feel that we're avoiding and dancing around the issue.
>
> The user should NEVER EVER have to use kill-controller. If someone
> types that we've failed to build Juju to the standards to which I feel we
> all should expect us to live up to. There is only ONE way for a user to 
> take
> down a controller, destroy-controller.


 I think it would be better if we hid kill-controller, but it's clear
 from the bugs that people *are* using kill-controller and expecting it to 
 be
 more or less safe to use.
>>>
>>>
>>> But this comes back to what started this. People are using it because
>>> destroy-model isn't working for them. It's one part bug that it's not the
>>> reverse of bootstrap in its current form and one part that we've broken
>>> cleanup between betas so folks are looking for something that works. People
>>> are looking for it because they've got no choice.
>>>
>>>

 What about this scenario:
 - Alice bootstraps, and adds user Bob with admin access.
 - Bob registers the controller.
 
 - The controller is still running and available, but Bob no longer needs
 access to it.

 How does Bob remove the controller from his client without destroying
 it? He's an admin, so "destroy-controller" will happily destroy everything.

 If we add a flag to destroy-controller to only clean up the cache, then
 "oops, I forgot to add the flag" and now all the models are gone.

>>>
>>> Agree that this is a mess. This is part that we don't have a way to give
>>> folks access without making them admins. I've got this towards the top of
>>> our 16.10 roadmap. I'd rather we did something temp with a plugin here or
>>> the like until we can get a real solution in place. This does bring up how
>>> this is going to work with other hosted model solutions.
>>>
>
> I don't feel that adding another command for another way to remove a
> controller from list-controllers is something 

Re: Unable to kill-controller

[Andrew Wilkins]

On Thu, Apr 7, 2016 at 12:40 PM John Meinel  wrote:

> Another aspect of this is actually that we made kill-controller "safe".
> The fact that it does a "clean" shutdown first and then tries harder means
> I have little motivation to use anything else. Also, for whatever reason I
> find kill-controller easier to remember and type.
>
> Given Rick's fair position that having to kill I'd a sign of failure on
> our part, what if:
> 1. We stop being safe. People will be forced into a juju
> destroy-controller || juju kill-controller position but that let's us
> separate concerns.
> 2. We move CI towards making kill-controller fail the test suite. If
> destroy doesn't do everything they want, then we have a bug and it should
> be telling developers that.
>
SGTM. That will go further to discouraging kill-controller except when
really necessary.

> 3. I personally like "forget-controller" over purge, and I don't like
> "destroy, but don't actually destroy" type of forgetting.
>
> John
> =:->
> On Apr 7, 2016 4:36 AM, "Rick Harding"  wrote:
>
>>
>>
>> On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding 
>>> wrote:
>>>
 I strongly feel that we're avoiding and dancing around the issue.

 The user should NEVER EVER have to use kill-controller. If someone
 types that we've failed to build Juju to the standards to which I feel we
 all should expect us to live up to. There is only ONE way for a user to
 take down a controller, destroy-controller.

>>>
>>> I think it would be better if we hid kill-controller, but it's clear
>>> from the bugs that people *are* using kill-controller and expecting it to
>>> be more or less safe to use.
>>>
>>
>> But this comes back to what started this. People are using it because
>> destroy-model isn't working for them. It's one part bug that it's not the
>> reverse of bootstrap in its current form and one part that we've broken
>> cleanup between betas so folks are looking for something that works. People
>> are looking for it because they've got no choice.
>>
>>
>>
>>> What about this scenario:
>>> - Alice bootstraps, and adds user Bob with admin access.
>>> - Bob registers the controller.
>>> 
>>> - The controller is still running and available, but Bob no longer needs
>>> access to it.
>>>
>>> How does Bob remove the controller from his client without destroying
>>> it? He's an admin, so "destroy-controller" will happily destroy everything.
>>>
>>> If we add a flag to destroy-controller to only clean up the cache, then
>>> "oops, I forgot to add the flag" and now all the models are gone.
>>>
>>>
>> Agree that this is a mess. This is part that we don't have a way to give
>> folks access without making them admins. I've got this towards the top of
>> our 16.10 roadmap. I'd rather we did something temp with a plugin here or
>> the like until we can get a real solution in place. This does bring up how
>> this is going to work with other hosted model solutions.
>>
>>
>>> I don't feel that adding another command for another way to remove a
 controller from list-controllers is something we want to do and we
 especially don't want to do it this week as we try to freeze 2.0 for
 release.

 If folks think I'm missing a point please reach out to me and lets move
 this to a high-bandwidth discussion, but I wanted to share the original
 design/thought on the destroy vs kill controller commands. I want everyone
 to share the feeling that if our users ever type kill-controller into their
 terminals we've failed them and realize that.

>>>
>>> If you like, we can leave it as-is for 2.0 -- no command to clean up the
>>> cache -- and talk about it at the next sprint.
>>>
>>
>> I think that's best. I'd love to stop and figure this out right, but with
>> everything breathing down our neck I fear we'll make a mistake we're stuck
>> with until 3.0.
>>
>>
>>
>> --
>> 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: Unable to kill-controller

[John Meinel]

Another aspect of this is actually that we made kill-controller "safe". The
fact that it does a "clean" shutdown first and then tries harder means I
have little motivation to use anything else. Also, for whatever reason I
find kill-controller easier to remember and type.

Given Rick's fair position that having to kill I'd a sign of failure on our
part, what if:
1. We stop being safe. People will be forced into a juju destroy-controller
|| juju kill-controller position but that let's us separate concerns.
2. We move CI towards making kill-controller fail the test suite. If
destroy doesn't do everything they want, then we have a bug and it should
be telling developers that.
3. I personally like "forget-controller" over purge, and I don't like
"destroy, but don't actually destroy" type of forgetting.

John
=:->
On Apr 7, 2016 4:36 AM, "Rick Harding"  wrote:

>
>
> On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding 
>> wrote:
>>
>>> I strongly feel that we're avoiding and dancing around the issue.
>>>
>>> The user should NEVER EVER have to use kill-controller. If someone types
>>> that we've failed to build Juju to the standards to which I feel we all
>>> should expect us to live up to. There is only ONE way for a user to take
>>> down a controller, destroy-controller.
>>>
>>
>> I think it would be better if we hid kill-controller, but it's clear from
>> the bugs that people *are* using kill-controller and expecting it to be
>> more or less safe to use.
>>
>
> But this comes back to what started this. People are using it because
> destroy-model isn't working for them. It's one part bug that it's not the
> reverse of bootstrap in its current form and one part that we've broken
> cleanup between betas so folks are looking for something that works. People
> are looking for it because they've got no choice.
>
>
>
>> What about this scenario:
>> - Alice bootstraps, and adds user Bob with admin access.
>> - Bob registers the controller.
>> 
>> - The controller is still running and available, but Bob no longer needs
>> access to it.
>>
>> How does Bob remove the controller from his client without destroying it?
>> He's an admin, so "destroy-controller" will happily destroy everything.
>>
>> If we add a flag to destroy-controller to only clean up the cache, then
>> "oops, I forgot to add the flag" and now all the models are gone.
>>
>>
> Agree that this is a mess. This is part that we don't have a way to give
> folks access without making them admins. I've got this towards the top of
> our 16.10 roadmap. I'd rather we did something temp with a plugin here or
> the like until we can get a real solution in place. This does bring up how
> this is going to work with other hosted model solutions.
>
>
>> I don't feel that adding another command for another way to remove a
>>> controller from list-controllers is something we want to do and we
>>> especially don't want to do it this week as we try to freeze 2.0 for
>>> release.
>>>
>>> If folks think I'm missing a point please reach out to me and lets move
>>> this to a high-bandwidth discussion, but I wanted to share the original
>>> design/thought on the destroy vs kill controller commands. I want everyone
>>> to share the feeling that if our users ever type kill-controller into their
>>> terminals we've failed them and realize that.
>>>
>>
>> If you like, we can leave it as-is for 2.0 -- no command to clean up the
>> cache -- and talk about it at the next sprint.
>>
>
> I think that's best. I'd love to stop and figure this out right, but with
> everything breathing down our neck I fear we'll make a mistake we're stuck
> with until 3.0.
>
>
>
> --
> 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: Unable to kill-controller

[Andrew Wilkins]

On Thu, Apr 7, 2016 at 8:36 AM Rick Harding 
wrote:

> On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding 
>> wrote:
>>
>>> I strongly feel that we're avoiding and dancing around the issue.
>>>
>>> The user should NEVER EVER have to use kill-controller. If someone types
>>> that we've failed to build Juju to the standards to which I feel we all
>>> should expect us to live up to. There is only ONE way for a user to take
>>> down a controller, destroy-controller.
>>>
>>
>> I think it would be better if we hid kill-controller, but it's clear from
>> the bugs that people *are* using kill-controller and expecting it to be
>> more or less safe to use.
>>
>
> But this comes back to what started this. People are using it because
> destroy-model isn't working for them. It's one part bug that it's not the
> reverse of bootstrap in its current form and one part that we've broken
> cleanup between betas so folks are looking for something that works. People
> are looking for it because they've got no choice.
>
>
>
>> What about this scenario:
>> - Alice bootstraps, and adds user Bob with admin access.
>> - Bob registers the controller.
>> 
>> - The controller is still running and available, but Bob no longer needs
>> access to it.
>>
>> How does Bob remove the controller from his client without destroying it?
>> He's an admin, so "destroy-controller" will happily destroy everything.
>>
>> If we add a flag to destroy-controller to only clean up the cache, then
>> "oops, I forgot to add the flag" and now all the models are gone.
>>
>>
> Agree that this is a mess. This is part that we don't have a way to give
> folks access without making them admins. I've got this towards the top of
> our 16.10 roadmap. I'd rather we did something temp with a plugin here or
> the like until we can get a real solution in place. This does bring up how
> this is going to work with other hosted model solutions.
>

FWIW, you can add users without making them a controller admin. They're
only a controller admin if they have write-access to the "admin" model,
which is not a necessity for obtaining access to other models.


>
>> I don't feel that adding another command for another way to remove a
>>> controller from list-controllers is something we want to do and we
>>> especially don't want to do it this week as we try to freeze 2.0 for
>>> release.
>>>
>>> If folks think I'm missing a point please reach out to me and lets move
>>> this to a high-bandwidth discussion, but I wanted to share the original
>>> design/thought on the destroy vs kill controller commands. I want everyone
>>> to share the feeling that if our users ever type kill-controller into their
>>> terminals we've failed them and realize that.
>>>
>>
>> If you like, we can leave it as-is for 2.0 -- no command to clean up the
>> cache -- and talk about it at the next sprint.
>>
>
> I think that's best. I'd love to stop and figure this out right, but with
> everything breathing down our neck I fear we'll make a mistake we're stuck
> with until 3.0.
>

OK.

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

Re: Unable to kill-controller

[Rick Harding]

On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins 
wrote:

> On Wed, Apr 6, 2016 at 11:28 PM Rick Harding 
> wrote:
>
>> I strongly feel that we're avoiding and dancing around the issue.
>>
>> The user should NEVER EVER have to use kill-controller. If someone types
>> that we've failed to build Juju to the standards to which I feel we all
>> should expect us to live up to. There is only ONE way for a user to take
>> down a controller, destroy-controller.
>>
>
> I think it would be better if we hid kill-controller, but it's clear from
> the bugs that people *are* using kill-controller and expecting it to be
> more or less safe to use.
>

But this comes back to what started this. People are using it because
destroy-model isn't working for them. It's one part bug that it's not the
reverse of bootstrap in its current form and one part that we've broken
cleanup between betas so folks are looking for something that works. People
are looking for it because they've got no choice.



> What about this scenario:
> - Alice bootstraps, and adds user Bob with admin access.
> - Bob registers the controller.
> 
> - The controller is still running and available, but Bob no longer needs
> access to it.
>
> How does Bob remove the controller from his client without destroying it?
> He's an admin, so "destroy-controller" will happily destroy everything.
>
> If we add a flag to destroy-controller to only clean up the cache, then
> "oops, I forgot to add the flag" and now all the models are gone.
>
>
Agree that this is a mess. This is part that we don't have a way to give
folks access without making them admins. I've got this towards the top of
our 16.10 roadmap. I'd rather we did something temp with a plugin here or
the like until we can get a real solution in place. This does bring up how
this is going to work with other hosted model solutions.


> I don't feel that adding another command for another way to remove a
>> controller from list-controllers is something we want to do and we
>> especially don't want to do it this week as we try to freeze 2.0 for
>> release.
>>
>> If folks think I'm missing a point please reach out to me and lets move
>> this to a high-bandwidth discussion, but I wanted to share the original
>> design/thought on the destroy vs kill controller commands. I want everyone
>> to share the feeling that if our users ever type kill-controller into their
>> terminals we've failed them and realize that.
>>
>
> If you like, we can leave it as-is for 2.0 -- no command to clean up the
> cache -- and talk about it at the next sprint.
>

I think that's best. I'd love to stop and figure this out right, but with
everything breathing down our neck I fear we'll make a mistake we're stuck
with until 3.0.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Andrew Wilkins]

On Wed, Apr 6, 2016 at 11:28 PM Rick Harding 
wrote:

> I strongly feel that we're avoiding and dancing around the issue.
>
> The user should NEVER EVER have to use kill-controller. If someone types
> that we've failed to build Juju to the standards to which I feel we all
> should expect us to live up to. There is only ONE way for a user to take
> down a controller, destroy-controller.
>

I think it would be better if we hid kill-controller, but it's clear from
the bugs that people *are* using kill-controller and expecting it to be
more or less safe to use.


> If a user has models running on that controller we've given them a flag to
> safely say "I know I have stuff running, but I don't care" with the current
> stuff running on there.
>
> I completely understand that destroy-controller is not the reverse of
> bootstrap. We've filed a bug for that and should correct the bug rather
> than moving to other commands and processes to deal with that.
>
> https://bugs.launchpad.net/juju-core/+bug/1563615
>
> kill-controller is a top secret tool we keep in our back pockets for
> emergency debugging when crap that's beyond our planning/control has
> occurred and we've not yet updated destroy-controlller to be able to handle
> that. It should not be in the main docs, release notes, etc. It's
> dangerous, folks should be discouraged from ever using it. Even when we do
> use it, we should be saying things like "Well, destroy-controller seems to
> be broken, we've got this potentially messy/risky way of trying to work
> around it that we can try...but..."
>
> As for the user case where a user registers on someone else's controller
> and wants to no longer have that controller appear, then we should update
> destroy-controller to handle that. There's only ONE way to remove a
> controller from your list, destroy-controller. We should be able to note
> that the user requesting destroy-controller does not have sufficient access
> to remove it and tell them "You've got these models running on this
> controller". And if they want to destroy with the flag to remove all their
> models, then we should do that and remove it from their system. If they
> have no running models, we should note that we're removing that
> controller's information from their system. If there's user confusion we
> can look at a message "You are not the controller admin, removing the
> controller information from your cache" or the like.
>

What about this scenario:
- Alice bootstraps, and adds user Bob with admin access.
- Bob registers the controller.

- The controller is still running and available, but Bob no longer needs
access to it.

How does Bob remove the controller from his client without destroying it?
He's an admin, so "destroy-controller" will happily destroy everything.

If we add a flag to destroy-controller to only clean up the cache, then
"oops, I forgot to add the flag" and now all the models are gone.

I don't feel that adding another command for another way to remove a
> controller from list-controllers is something we want to do and we
> especially don't want to do it this week as we try to freeze 2.0 for
> release.
>
> If folks think I'm missing a point please reach out to me and lets move
> this to a high-bandwidth discussion, but I wanted to share the original
> design/thought on the destroy vs kill controller commands. I want everyone
> to share the feeling that if our users ever type kill-controller into their
> terminals we've failed them and realize that.
>

If you like, we can leave it as-is for 2.0 -- no command to clean up the
cache -- and talk about it at the next sprint.

Cheers,
Andrew


> Thanks
>
> Rick
>
> On Wed, Apr 6, 2016 at 11:02 AM Cheryl Jennings <
> cheryl.jenni...@canonical.com> wrote:
>
>> Another relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1566426
>>
>> Maybe kill-controller tries to destroy through the API, but has a time
>> out if things get "stuck" where it will fall back to the provider.  I was
>> joking when I suggested yesterday in IRC that we should bring back --force
>> for kill-controller, but maybe we need it (or at least a timeout).
>>
>> On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch 
>> wrote:
>>
>>> Oh I see.  Yes, I agree that we should always try the right way first
>>> and only use the provider if necessary (especially if using the provider
>>> leaves garbage around).
>>>
>>> It seems like there's no reason why we couldn't make a --force flag do
>>> it that way in 2.0 (aside from time constraints).
>>>
>>> On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley <
>>> aaron.bent...@canonical.com> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 2016-04-06 10:45 AM, Nate Finch wrote:
 > Wait, didn't destroy-environment --force fall back to the provider?
 > I thought that was the whole point of --force

 No, it didn't fall back.  It uses the provider unconditionally,
 without trying a 

Re: Unable to kill-controller

[Anastasia Macmood]

I am guessing that we have already covered the other side of destroying
controllers

1. If I am using someone else's controller and the admin of this
controller destroys it, I get notified and I know I need to "purge" it
2. If I am an admin of the controller that other users are using, when I
destroy it, I get notified that "other users are using this
controller... are you sure you want to destroy it?"...

On 07/04/16 07:54, Alexis Bruemmer wrote:
> Any reason why destroy-controller and kill-controller would not also
> remove the local reference (purge-controller)?
>
> On Wed, Apr 6, 2016 at 1:54 PM, Tim Penhey  > wrote:
>
> On 06/04/16 23:13, Nick Veitch wrote:
> > Sure, I am just concerned about a proliferation of commands to
> do the
> > same (ultimately) task
> >
> > destroy-controller
>
> The most correct way to take down a controller.
>
> > kill-controller
>
> The OMG it is broken, please do as much as you can and I know I'm
> going
> to have to manually check any resources left around that it couldn't
> clean up.
>
> > forget/purge-controller
>
> Remove local references to the controller.
>
>
> Not really the same things at all.
>
> Tim
>
>
> >
> >
> >
> > On 6 April 2016 at 11:59, Horacio Duran
> 
> >  >>
> wrote:
> >
> > The issue I see with that approach is that in that case
> > kill-controller might be doing less than you expect instead
> of more,
> > suppose the controller is having transient issues and kill
> > controller cannot reach the cloud for deletion, this would
> forget
> > the controller and leave it in the cloud, forget-controller
> instead
> > tells us very clearly what is going to happen, the change is
> going
> > to be local and not affect the controller.
> > My 2c
> >
> >
> > On Wednesday, 6 April 2016, Nick Veitch
> 
> >  >> wrote:
> >
> > just my tuppence
> >
> > instead of having another command, can't we just add
> this as an
> > option to kill-controller?
> >
> > juju kill-controller --cleanup 
> >
> >
> >
> > On 6 April 2016 at 11:05, Horacio Duran
> >  > wrote:
> >
> >
> > I might be biased by years of apt-get but purge makes me
> > think that you are going to do what kill is supposed
> to do,
> > forget sound more aligned whit what you are really
> aiming to.
> >
> > On Wednesday, 6 April 2016, Andrew Wilkins
> >  > wrote:
> >
> > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings
> >  > wrote:
> >
> > Relevant bug:
> > 
> https://bugs.launchpad.net/juju-core/+bug/1553059
> >
> > We should provide a way to clean up controllers
> > without making the user manually edit juju's
> files.
> >
> >
> > Unless anyone objects, or has a better spelling,
> I will
> > be adding a command to do this:
> >
> > juju purge-controller 
> >
> > The command will require a "-y" or prompt for
> > confirmation, like kill-controller. It will not
> attempt
> > to destroy the controller, it will just remove the
> > details of it from the client.
> >
> > (Alternative suggestion for spelling: "juju
> > forget-controller". Purge-controller may suggest
> that
> > we're purging a controller of its contents,
> rather than
> > purging the controller from the client?)
> >
> > Cheers,
> > Andrew
> >
> > On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch
> >  > wrote:
> >
> > This just happened to me, too. 
> Kill-controller
> > needs to work if at all possible. 
> That's the
> > whole point.  And yes, users may not 

Re: Unable to kill-controller

[Andrew Wilkins]

On Thu, Apr 7, 2016 at 3:25 AM Aaron Bentley 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2016-04-06 01:41 PM, Nate Finch wrote:
> > I'd much prefer giant warning text:
> >
> > DANGER!!! USE THIS COMMAND ONLY AS A LAST RESORT!! IT MAY LEAVE
> > RESOURCES RUNNING IN YOUR CLOUD!  ALWAYS TRY destroy-controller
> > FIRST!
>
> I don't see why this warning is needed.  kill-controller always tries
> destroy-controller first anyhow.  If kill-controller does leave
> resources lying around, that was the best case anyhow.
>

It is the best case, but only if you're intentional about kill vs. destroy.
If you're not, then you may be accidentally leaking manual machines, for
example.


> > In fact, if I were feeling sneaky, I might accept -y and still make
> > them confirm, since they're obviously just banging out the command
> > without thinking.
>
> That would break this command such that QA could not use it.  We would
> be very vexed.
>
> Aaron
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJXBWKaAAoJEK84cMOcf+9h6xMH/27hpIV0NqaGxOttJWPZBlGK
> qNybd9JGSMQy3cmaHyPTNqZFcq3Qw+nCPrT3SNVCpl+AnnspGA2uysZ61jejds4Y
> QG0246mluC7O3TMOEBlPSqU5ezJST0X3f+hrpTEj6f0yym6LAZ96daozsqbvbLAP
> 33lqBJS2kT/5JvC3A1iPM/YyZbBDpJPgrlSoNfDvTVFdj4/3R0UkLADIHrG0ZcGR
> umW+BsIWsuPyTOM+hCO8mNr2gS6i4+KwIcus7Np7rPdDdExsHrcthPilHmvg4KQn
> /9tMJTViRnLmjXSdHRFLSnmF4eAau5VuApaLara1hfPWYRpBF4IhlPJEXb3vi+o=
> =tmNe
> -END PGP SIGNATURE-
>
> --
> 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: Unable to kill-controller

[Andrew Wilkins]

On Thu, Apr 7, 2016 at 5:55 AM Alexis Bruemmer <
alexis.bruem...@canonical.com> wrote:

> Any reason why destroy-controller and kill-controller would not also
> remove the local reference (purge-controller)?
>

Destroy/kill will always do that. The question is only whether we should
have an additional command to remove, but not also kill/destroy.


> On Wed, Apr 6, 2016 at 1:54 PM, Tim Penhey 
> wrote:
>
>> On 06/04/16 23:13, Nick Veitch wrote:
>> > Sure, I am just concerned about a proliferation of commands to do the
>> > same (ultimately) task
>> >
>> > destroy-controller
>>
>> The most correct way to take down a controller.
>>
>> > kill-controller
>>
>> The OMG it is broken, please do as much as you can and I know I'm going
>> to have to manually check any resources left around that it couldn't
>> clean up.
>>
>> > forget/purge-controller
>>
>> Remove local references to the controller.
>>
>>
>> Not really the same things at all.
>>
>> Tim
>>
>>
>> >
>> >
>> >
>> > On 6 April 2016 at 11:59, Horacio Duran > > > wrote:
>> >
>> > The issue I see with that approach is that in that case
>> > kill-controller might be doing less than you expect instead of more,
>> > suppose the controller is having transient issues and kill
>> > controller cannot reach the cloud for deletion, this would forget
>> > the controller and leave it in the cloud, forget-controller instead
>> > tells us very clearly what is going to happen, the change is going
>> > to be local and not affect the controller.
>> > My 2c
>> >
>> >
>> > On Wednesday, 6 April 2016, Nick Veitch > > > wrote:
>> >
>> > just my tuppence
>> >
>> > instead of having another command, can't we just add this as an
>> > option to kill-controller?
>> >
>> > juju kill-controller --cleanup 
>> >
>> >
>> >
>> > On 6 April 2016 at 11:05, Horacio Duran
>> >  wrote:
>> >
>> >
>> > I might be biased by years of apt-get but purge makes me
>> > think that you are going to do what kill is supposed to do,
>> > forget sound more aligned whit what you are really aiming
>> to.
>> >
>> > On Wednesday, 6 April 2016, Andrew Wilkins
>> >  wrote:
>> >
>> > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings
>> >  wrote:
>> >
>> > Relevant bug:
>> >  https://bugs.launchpad.net/juju-core/+bug/1553059
>> >
>> > We should provide a way to clean up controllers
>> > without making the user manually edit juju's files.
>> >
>> >
>> > Unless anyone objects, or has a better spelling, I will
>> > be adding a command to do this:
>> >
>> > juju purge-controller 
>> >
>> > The command will require a "-y" or prompt for
>> > confirmation, like kill-controller. It will not attempt
>> > to destroy the controller, it will just remove the
>> > details of it from the client.
>> >
>> > (Alternative suggestion for spelling: "juju
>> > forget-controller". Purge-controller may suggest that
>> > we're purging a controller of its contents, rather than
>> > purging the controller from the client?)
>> >
>> > Cheers,
>> > Andrew
>> >
>> > On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch
>> >  wrote:
>> >
>> > This just happened to me, too.  Kill-controller
>> > needs to work if at all possible.  That's the
>> > whole point.  And yes, users may not hit
>> > specific problems, but devs do, and that wastes
>> > our time trying to figure out how to manually
>> > clean up the garbage.
>> >
>> > On Mon, Apr 4, 2016 at 8:33 AM Rick Harding
>> >  wrote:
>> >
>> > On Sun, Apr 3, 2016 at 6:56 PM Andrew
>> > Wilkins 
>> wrote:
>> >
>> > In a non-beta release we would make sure
>> > that the config changes aren't backwards
>> > incompatible.
>> >
>> >
>> > I think this is the key thing. I think that
>> > kill-controller is an exception to this
>> > rule. I think we should always at least give

Re: Unable to kill-controller

[Alexis Bruemmer]

Any reason why destroy-controller and kill-controller would not also remove
the local reference (purge-controller)?

On Wed, Apr 6, 2016 at 1:54 PM, Tim Penhey  wrote:

> On 06/04/16 23:13, Nick Veitch wrote:
> > Sure, I am just concerned about a proliferation of commands to do the
> > same (ultimately) task
> >
> > destroy-controller
>
> The most correct way to take down a controller.
>
> > kill-controller
>
> The OMG it is broken, please do as much as you can and I know I'm going
> to have to manually check any resources left around that it couldn't
> clean up.
>
> > forget/purge-controller
>
> Remove local references to the controller.
>
>
> Not really the same things at all.
>
> Tim
>
>
> >
> >
> >
> > On 6 April 2016 at 11:59, Horacio Duran  > > wrote:
> >
> > The issue I see with that approach is that in that case
> > kill-controller might be doing less than you expect instead of more,
> > suppose the controller is having transient issues and kill
> > controller cannot reach the cloud for deletion, this would forget
> > the controller and leave it in the cloud, forget-controller instead
> > tells us very clearly what is going to happen, the change is going
> > to be local and not affect the controller.
> > My 2c
> >
> >
> > On Wednesday, 6 April 2016, Nick Veitch  > > wrote:
> >
> > just my tuppence
> >
> > instead of having another command, can't we just add this as an
> > option to kill-controller?
> >
> > juju kill-controller --cleanup 
> >
> >
> >
> > On 6 April 2016 at 11:05, Horacio Duran
> >  wrote:
> >
> >
> > I might be biased by years of apt-get but purge makes me
> > think that you are going to do what kill is supposed to do,
> > forget sound more aligned whit what you are really aiming to.
> >
> > On Wednesday, 6 April 2016, Andrew Wilkins
> >  wrote:
> >
> > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings
> >  wrote:
> >
> > Relevant bug:
> >  https://bugs.launchpad.net/juju-core/+bug/1553059
> >
> > We should provide a way to clean up controllers
> > without making the user manually edit juju's files.
> >
> >
> > Unless anyone objects, or has a better spelling, I will
> > be adding a command to do this:
> >
> > juju purge-controller 
> >
> > The command will require a "-y" or prompt for
> > confirmation, like kill-controller. It will not attempt
> > to destroy the controller, it will just remove the
> > details of it from the client.
> >
> > (Alternative suggestion for spelling: "juju
> > forget-controller". Purge-controller may suggest that
> > we're purging a controller of its contents, rather than
> > purging the controller from the client?)
> >
> > Cheers,
> > Andrew
> >
> > On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch
> >  wrote:
> >
> > This just happened to me, too.  Kill-controller
> > needs to work if at all possible.  That's the
> > whole point.  And yes, users may not hit
> > specific problems, but devs do, and that wastes
> > our time trying to figure out how to manually
> > clean up the garbage.
> >
> > On Mon, Apr 4, 2016 at 8:33 AM Rick Harding
> >  wrote:
> >
> > On Sun, Apr 3, 2016 at 6:56 PM Andrew
> > Wilkins 
> wrote:
> >
> > In a non-beta release we would make sure
> > that the config changes aren't backwards
> > incompatible.
> >
> >
> > I think this is the key thing. I think that
> > kill-controller is an exception to this
> > rule. I think we should always at least give
> > the user the ability to remove their stuff
> > and start over with the new alpha/beta/rc
> > release. I'd like to ask us to explore
> > making kill-controller an exception to this
> > policy and that if tests prove 

Re: Unable to kill-controller

[Nate Finch]

I obviously wasn't clear. I was suggesting a --yes-i-really-mean-it flag on
kill-controller, but if you passed just -y we show the prompt anyway
(instead of erroring out on an unknown flsg).

My point with the big prompt was in response to Rick saying it should never
be needed and should only be used in extreme circumstances... If that's how
we feel, we should make sure the user knows it.

Many people have said on this thread that the difference between
kill-controller and destroy-controller is not immediately obvious.., and
we're the devs on the project. I'm just trying to make sure we make it
clear for users.

On Wed, Apr 6, 2016, 4:54 PM Tim Penhey  wrote:

> On 06/04/16 23:13, Nick Veitch wrote:
> > Sure, I am just concerned about a proliferation of commands to do the
> > same (ultimately) task
> >
> > destroy-controller
>
> The most correct way to take down a controller.
>
> > kill-controller
>
> The OMG it is broken, please do as much as you can and I know I'm going
> to have to manually check any resources left around that it couldn't
> clean up.
>
> > forget/purge-controller
>
> Remove local references to the controller.
>
>
> Not really the same things at all.
>
> Tim
>
>
> >
> >
> >
> > On 6 April 2016 at 11:59, Horacio Duran  > > wrote:
> >
> > The issue I see with that approach is that in that case
> > kill-controller might be doing less than you expect instead of more,
> > suppose the controller is having transient issues and kill
> > controller cannot reach the cloud for deletion, this would forget
> > the controller and leave it in the cloud, forget-controller instead
> > tells us very clearly what is going to happen, the change is going
> > to be local and not affect the controller.
> > My 2c
> >
> >
> > On Wednesday, 6 April 2016, Nick Veitch  > > wrote:
> >
> > just my tuppence
> >
> > instead of having another command, can't we just add this as an
> > option to kill-controller?
> >
> > juju kill-controller --cleanup 
> >
> >
> >
> > On 6 April 2016 at 11:05, Horacio Duran
> >  wrote:
> >
> >
> > I might be biased by years of apt-get but purge makes me
> > think that you are going to do what kill is supposed to do,
> > forget sound more aligned whit what you are really aiming to.
> >
> > On Wednesday, 6 April 2016, Andrew Wilkins
> >  wrote:
> >
> > On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings
> >  wrote:
> >
> > Relevant bug:
> >  https://bugs.launchpad.net/juju-core/+bug/1553059
> >
> > We should provide a way to clean up controllers
> > without making the user manually edit juju's files.
> >
> >
> > Unless anyone objects, or has a better spelling, I will
> > be adding a command to do this:
> >
> > juju purge-controller 
> >
> > The command will require a "-y" or prompt for
> > confirmation, like kill-controller. It will not attempt
> > to destroy the controller, it will just remove the
> > details of it from the client.
> >
> > (Alternative suggestion for spelling: "juju
> > forget-controller". Purge-controller may suggest that
> > we're purging a controller of its contents, rather than
> > purging the controller from the client?)
> >
> > Cheers,
> > Andrew
> >
> > On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch
> >  wrote:
> >
> > This just happened to me, too.  Kill-controller
> > needs to work if at all possible.  That's the
> > whole point.  And yes, users may not hit
> > specific problems, but devs do, and that wastes
> > our time trying to figure out how to manually
> > clean up the garbage.
> >
> > On Mon, Apr 4, 2016 at 8:33 AM Rick Harding
> >  wrote:
> >
> > On Sun, Apr 3, 2016 at 6:56 PM Andrew
> > Wilkins 
> wrote:
> >
> > In a non-beta release we would make sure
> > that the config changes aren't backwards
> > incompatible.
> >
> >
> > I think this is the key thing. I think that
> > 

Re: Unable to kill-controller

[Tim Penhey]

On 06/04/16 23:13, Nick Veitch wrote:
> Sure, I am just concerned about a proliferation of commands to do the
> same (ultimately) task
> 
> destroy-controller

The most correct way to take down a controller.

> kill-controller

The OMG it is broken, please do as much as you can and I know I'm going
to have to manually check any resources left around that it couldn't
clean up.

> forget/purge-controller

Remove local references to the controller.


Not really the same things at all.

Tim


> 
> 
> 
> On 6 April 2016 at 11:59, Horacio Duran  > wrote:
> 
> The issue I see with that approach is that in that case
> kill-controller might be doing less than you expect instead of more,
> suppose the controller is having transient issues and kill
> controller cannot reach the cloud for deletion, this would forget
> the controller and leave it in the cloud, forget-controller instead
> tells us very clearly what is going to happen, the change is going
> to be local and not affect the controller.
> My 2c
> 
> 
> On Wednesday, 6 April 2016, Nick Veitch  > wrote:
> 
> just my tuppence
> 
> instead of having another command, can't we just add this as an
> option to kill-controller?
> 
> juju kill-controller --cleanup 
> 
> 
> 
> On 6 April 2016 at 11:05, Horacio Duran
>  wrote:
> 
> 
> I might be biased by years of apt-get but purge makes me
> think that you are going to do what kill is supposed to do,
> forget sound more aligned whit what you are really aiming to.
> 
> On Wednesday, 6 April 2016, Andrew Wilkins
>  wrote:
> 
> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings
>  wrote:
> 
> Relevant bug:
>  https://bugs.launchpad.net/juju-core/+bug/1553059
> 
> We should provide a way to clean up controllers
> without making the user manually edit juju's files.
> 
> 
> Unless anyone objects, or has a better spelling, I will
> be adding a command to do this:
> 
> juju purge-controller 
> 
> The command will require a "-y" or prompt for
> confirmation, like kill-controller. It will not attempt
> to destroy the controller, it will just remove the
> details of it from the client.
> 
> (Alternative suggestion for spelling: "juju
> forget-controller". Purge-controller may suggest that
> we're purging a controller of its contents, rather than
> purging the controller from the client?)
> 
> Cheers,
> Andrew
> 
> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch
>  wrote:
> 
> This just happened to me, too.  Kill-controller
> needs to work if at all possible.  That's the
> whole point.  And yes, users may not hit
> specific problems, but devs do, and that wastes
> our time trying to figure out how to manually
> clean up the garbage.
> 
> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding
>  wrote:
> 
> On Sun, Apr 3, 2016 at 6:56 PM Andrew
> Wilkins  wrote:
> 
> In a non-beta release we would make sure
> that the config changes aren't backwards
> incompatible.
> 
> 
> I think this is the key thing. I think that
> kill-controller is an exception to this
> rule. I think we should always at least give
> the user the ability to remove their stuff
> and start over with the new alpha/beta/rc
> release. I'd like to ask us to explore
> making kill-controller an exception to this
> policy and that if tests prove we can't
> bootstrap on one beta and kill with trunk
> that it's a blocking bug for us.  
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 01:41 PM, Nate Finch wrote:
> I'd much prefer giant warning text:
> 
> DANGER!!! USE THIS COMMAND ONLY AS A LAST RESORT!! IT MAY LEAVE
> RESOURCES RUNNING IN YOUR CLOUD!  ALWAYS TRY destroy-controller
> FIRST!

I don't see why this warning is needed.  kill-controller always tries
destroy-controller first anyhow.  If kill-controller does leave
resources lying around, that was the best case anyhow.

> In fact, if I were feeling sneaky, I might accept -y and still make
> them confirm, since they're obviously just banging out the command
> without thinking.

That would break this command such that QA could not use it.  We would
be very vexed.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBWKaAAoJEK84cMOcf+9h6xMH/27hpIV0NqaGxOttJWPZBlGK
qNybd9JGSMQy3cmaHyPTNqZFcq3Qw+nCPrT3SNVCpl+AnnspGA2uysZ61jejds4Y
QG0246mluC7O3TMOEBlPSqU5ezJST0X3f+hrpTEj6f0yym6LAZ96daozsqbvbLAP
33lqBJS2kT/5JvC3A1iPM/YyZbBDpJPgrlSoNfDvTVFdj4/3R0UkLADIHrG0ZcGR
umW+BsIWsuPyTOM+hCO8mNr2gS6i4+KwIcus7Np7rPdDdExsHrcthPilHmvg4KQn
/9tMJTViRnLmjXSdHRFLSnmF4eAau5VuApaLara1hfPWYRpBF4IhlPJEXb3vi+o=
=tmNe
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Nate Finch]

So, I agree, we should never need to use kill controller... but sometimes
you might need it, like if someone SSH's into their controller and messes
it up, etc.

Right now, kill-controller is in all the help docs, i.e. juju help
commands... are we planning on changing that?  I'm not sure I'm on board
with having hidden commands, because they will invariably leak out, and
then we just have commands that everyone knows about, but that are
undocumented.

I'd much prefer giant warning text:

DANGER!!! USE THIS COMMAND ONLY AS A LAST RESORT!!
IT MAY LEAVE RESOURCES RUNNING IN YOUR CLOUD!  ALWAYS
TRY destroy-controller FIRST!

And make the flag to disable the "are you sure?" prompt something long and
annoying to type, not just -y, because that's too easy to just bang out
with muscle memory.

In fact, if I were feeling sneaky, I might accept -y and still make them
confirm, since they're obviously just banging out the command without
thinking.

-Nate



On Wed, Apr 6, 2016 at 11:21 AM Rick Harding 
wrote:

> I strongly feel that we're avoiding and dancing around the issue.
>
> The user should NEVER EVER have to use kill-controller. If someone types
> that we've failed to build Juju to the standards to which I feel we all
> should expect us to live up to. There is only ONE way for a user to take
> down a controller, destroy-controller.
>
> If a user has models running on that controller we've given them a flag to
> safely say "I know I have stuff running, but I don't care" with the current
> stuff running on there.
>
> I completely understand that destroy-controller is not the reverse of
> bootstrap. We've filed a bug for that and should correct the bug rather
> than moving to other commands and processes to deal with that.
>
> https://bugs.launchpad.net/juju-core/+bug/1563615
>
> kill-controller is a top secret tool we keep in our back pockets for
> emergency debugging when crap that's beyond our planning/control has
> occurred and we've not yet updated destroy-controlller to be able to handle
> that. It should not be in the main docs, release notes, etc. It's
> dangerous, folks should be discouraged from ever using it. Even when we do
> use it, we should be saying things like "Well, destroy-controller seems to
> be broken, we've got this potentially messy/risky way of trying to work
> around it that we can try...but..."
>
> As for the user case where a user registers on someone else's controller
> and wants to no longer have that controller appear, then we should update
> destroy-controller to handle that. There's only ONE way to remove a
> controller from your list, destroy-controller. We should be able to note
> that the user requesting destroy-controller does not have sufficient access
> to remove it and tell them "You've got these models running on this
> controller". And if they want to destroy with the flag to remove all their
> models, then we should do that and remove it from their system. If they
> have no running models, we should note that we're removing that
> controller's information from their system. If there's user confusion we
> can look at a message "You are not the controller admin, removing the
> controller information from your cache" or the like.
>
> I don't feel that adding another command for another way to remove a
> controller from list-controllers is something we want to do and we
> especially don't want to do it this week as we try to freeze 2.0 for
> release.
>
> If folks think I'm missing a point please reach out to me and lets move
> this to a high-bandwidth discussion, but I wanted to share the original
> design/thought on the destroy vs kill controller commands. I want everyone
> to share the feeling that if our users ever type kill-controller into their
> terminals we've failed them and realize that.
>
> Thanks
>
> Rick
>
> On Wed, Apr 6, 2016 at 11:02 AM Cheryl Jennings <
> cheryl.jenni...@canonical.com> wrote:
>
>> Another relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1566426
>>
>> Maybe kill-controller tries to destroy through the API, but has a time
>> out if things get "stuck" where it will fall back to the provider.  I was
>> joking when I suggested yesterday in IRC that we should bring back --force
>> for kill-controller, but maybe we need it (or at least a timeout).
>>
>> On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch 
>> wrote:
>>
>>> Oh I see.  Yes, I agree that we should always try the right way first
>>> and only use the provider if necessary (especially if using the provider
>>> leaves garbage around).
>>>
>>> It seems like there's no reason why we couldn't make a --force flag do
>>> it that way in 2.0 (aside from time constraints).
>>>
>>> On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley <
>>> aaron.bent...@canonical.com> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 2016-04-06 10:45 AM, Nate Finch wrote:
 > Wait, didn't destroy-environment --force fall back to the 

Re: Unable to kill-controller

[Rick Harding]

I strongly feel that we're avoiding and dancing around the issue.

The user should NEVER EVER have to use kill-controller. If someone types
that we've failed to build Juju to the standards to which I feel we all
should expect us to live up to. There is only ONE way for a user to take
down a controller, destroy-controller.

If a user has models running on that controller we've given them a flag to
safely say "I know I have stuff running, but I don't care" with the current
stuff running on there.

I completely understand that destroy-controller is not the reverse of
bootstrap. We've filed a bug for that and should correct the bug rather
than moving to other commands and processes to deal with that.

https://bugs.launchpad.net/juju-core/+bug/1563615

kill-controller is a top secret tool we keep in our back pockets for
emergency debugging when crap that's beyond our planning/control has
occurred and we've not yet updated destroy-controlller to be able to handle
that. It should not be in the main docs, release notes, etc. It's
dangerous, folks should be discouraged from ever using it. Even when we do
use it, we should be saying things like "Well, destroy-controller seems to
be broken, we've got this potentially messy/risky way of trying to work
around it that we can try...but..."

As for the user case where a user registers on someone else's controller
and wants to no longer have that controller appear, then we should update
destroy-controller to handle that. There's only ONE way to remove a
controller from your list, destroy-controller. We should be able to note
that the user requesting destroy-controller does not have sufficient access
to remove it and tell them "You've got these models running on this
controller". And if they want to destroy with the flag to remove all their
models, then we should do that and remove it from their system. If they
have no running models, we should note that we're removing that
controller's information from their system. If there's user confusion we
can look at a message "You are not the controller admin, removing the
controller information from your cache" or the like.

I don't feel that adding another command for another way to remove a
controller from list-controllers is something we want to do and we
especially don't want to do it this week as we try to freeze 2.0 for
release.

If folks think I'm missing a point please reach out to me and lets move
this to a high-bandwidth discussion, but I wanted to share the original
design/thought on the destroy vs kill controller commands. I want everyone
to share the feeling that if our users ever type kill-controller into their
terminals we've failed them and realize that.

Thanks

Rick

On Wed, Apr 6, 2016 at 11:02 AM Cheryl Jennings <
cheryl.jenni...@canonical.com> wrote:

> Another relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1566426
>
> Maybe kill-controller tries to destroy through the API, but has a time out
> if things get "stuck" where it will fall back to the provider.  I was
> joking when I suggested yesterday in IRC that we should bring back --force
> for kill-controller, but maybe we need it (or at least a timeout).
>
> On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch 
> wrote:
>
>> Oh I see.  Yes, I agree that we should always try the right way first and
>> only use the provider if necessary (especially if using the provider leaves
>> garbage around).
>>
>> It seems like there's no reason why we couldn't make a --force flag do it
>> that way in 2.0 (aside from time constraints).
>>
>> On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley <
>> aaron.bent...@canonical.com> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> On 2016-04-06 10:45 AM, Nate Finch wrote:
>>> > Wait, didn't destroy-environment --force fall back to the provider?
>>> > I thought that was the whole point of --force
>>>
>>> No, it didn't fall back.  It uses the provider unconditionally,
>>> without trying a normal destroy-controller first.
>>>
>>> Aaron
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
>>> TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
>>> ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
>>> LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
>>> XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
>>> WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
>>> =vm/H
>>> -END PGP SIGNATURE-
>>>
>>
>> --
>> 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 11:02 AM, Cheryl Jennings wrote:
> Another relevant bug:
> https://bugs.launchpad.net/juju-core/+bug/1566426
> 
> Maybe kill-controller tries to destroy through the API, but has a
> time out if things get "stuck" where it will fall back to the
> provider.

Interesting.  It does have a timeout for connecting to the API, and
it's a pretty short one.  But I guess we also want a timeout for the
destroy-controller API to succeed.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBSZpAAoJEK84cMOcf+9hRaoIAKUe5omkkhWeR1LcXvHGhXS1
Gi2gzo6Qz6cviJjcUv4ulNT+ZIHtwvdQDDLSIksMda8+i+FRZrX7c6owo+VDFxf3
4LjigyKsWWSLBHNxKIG6SaK8QZWeVrkjhuRDTJhu4gUHUepMh++grarj/Z92jn8J
tmHF8bHMyt6Pz9/pUjHzxLtmGy+K1GA088q+ec82qk7isZK+bEtsmkEqWSIbzKwo
tYeBrRHMS7zJe91AUX5ES4jp6ua28u7Ot3NfV2JrEYYD3D090aKtsI3IEDB65DgH
aJPD1CRzYhuLPmIQsiAlvPim6oiIQ7kTWKGRA5DxRxwG7sc+f6kVVsOFqXHoO2U=
=gqOt
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Cheryl Jennings]

Another relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1566426

Maybe kill-controller tries to destroy through the API, but has a time out
if things get "stuck" where it will fall back to the provider.  I was
joking when I suggested yesterday in IRC that we should bring back --force
for kill-controller, but maybe we need it (or at least a timeout).

On Wed, Apr 6, 2016 at 7:53 AM, Nate Finch  wrote:

> Oh I see.  Yes, I agree that we should always try the right way first and
> only use the provider if necessary (especially if using the provider leaves
> garbage around).
>
> It seems like there's no reason why we couldn't make a --force flag do it
> that way in 2.0 (aside from time constraints).
>
> On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 2016-04-06 10:45 AM, Nate Finch wrote:
>> > Wait, didn't destroy-environment --force fall back to the provider?
>> > I thought that was the whole point of --force
>>
>> No, it didn't fall back.  It uses the provider unconditionally,
>> without trying a normal destroy-controller first.
>>
>> Aaron
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
>> TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
>> ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
>> LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
>> XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
>> WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
>> =vm/H
>> -END PGP SIGNATURE-
>>
>
> --
> 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: Unable to kill-controller

[Nate Finch]

Oh I see.  Yes, I agree that we should always try the right way first and
only use the provider if necessary (especially if using the provider leaves
garbage around).

It seems like there's no reason why we couldn't make a --force flag do it
that way in 2.0 (aside from time constraints).

On Wed, Apr 6, 2016 at 10:48 AM Aaron Bentley 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2016-04-06 10:45 AM, Nate Finch wrote:
> > Wait, didn't destroy-environment --force fall back to the provider?
> > I thought that was the whole point of --force
>
> No, it didn't fall back.  It uses the provider unconditionally,
> without trying a normal destroy-controller first.
>
> Aaron
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
> TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
> ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
> LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
> XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
> WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
> =vm/H
> -END PGP SIGNATURE-
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 10:45 AM, Nate Finch wrote:
> Wait, didn't destroy-environment --force fall back to the provider?
> I thought that was the whole point of --force

No, it didn't fall back.  It uses the provider unconditionally,
without trying a normal destroy-controller first.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBSG5AAoJEK84cMOcf+9hzSQIAJ/vNKIa1/TnDSyvC2U9ApzW
TAEvSqaEUw0ZL2dl2tiNKTp3JPzcnCR4VKrBIsh1xi0hB1UNtJR+IW4O46gRI6ok
ZvA1cAvoJvRdmqf1ntNzYwHRSn/Tm82DGzixTPt0TcTn3KYrk13XpRJuxMbbvHDM
LfYG0zglGmVKUaWs4rBogh4H4OaiOIR8lORXSC8GRQjA1/C4c+FjIg+KeW5Yw2Ti
XnG87BPyJ1TtPGWxxeKAk4tnkZwnZKtJOnHU/IfvTFOpECdBjojWnnc6VbQ1um0H
WwjR6EcA4qxkkhND6ypIGkt9A4k3ZZvckCau52EgIn3pnwhk5OSw64MURJAEmn0=
=vm/H
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Nate Finch]

Wait, didn't destroy-environment --force fall back to the provider?  I
thought that was the whole point of --force

On Wed, Apr 6, 2016 at 10:24 AM Aaron Bentley 
wrote:

> On 2016-04-06 08:22 AM, Andrew Wilkins wrote:
> > What I would like to see is: * destroy-controller to take on a
> > --force flag, causing it to do what kill-controller does now, and
> > what destroy-environment --force used to do
>
> What kill-controller does now, where it attempts to use Juju, but
> falls back to the provider, is much more valuable to us in QA than
> what destroy-environment --force used to do.  We don't want to leak
> resources unnecessarily, but we do want things to die when we try to
> kill them.
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Aaron Bentley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2016-04-06 08:22 AM, Andrew Wilkins wrote:
> What I would like to see is: * destroy-controller to take on a
> --force flag, causing it to do what kill-controller does now, and
> what destroy-environment --force used to do

What kill-controller does now, where it attempts to use Juju, but
falls back to the provider, is much more valuable to us in QA than
what destroy-environment --force used to do.  We don't want to leak
resources unnecessarily, but we do want things to die when we try to
kill them.

Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXBRv5AAoJEK84cMOcf+9ho54H/iPRI5RpxT4kPoD3oJ3OXGAM
AjUrOcvghiik3K021yOzN4LIQm9dLdKv0rKZ0zYBW7EUaE2OUBt5HLSzINLMRXU/
T2qqTgDgu0iYWit06dp4jRyYiErGoENHCUciISXVMyGtk5xJPy+4kdcHZheq8jHW
WCtN07JNuMk6OUjQB4mDwKo1E0pEU36tKhPChFEceYT6O3OdCB66H+ZV+t1RlasR
2ktNeKg9bDjTu5/JwzOe4+eIFK8tvdgCRG1dmRXpQ6ewXN2IjFunkRVYkqc3RZcH
zphCjyuofv0CueuSSp1wbdQOxi6M05XyXb6czrdkkkgajqdTxXt2VI3JCMjrIgg=
=O5Bo
-END PGP SIGNATURE-

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

Re: Unable to kill-controller

[Nate Finch]

I agree with your assessment of the vocabulary, for what it's worth.

On Wed, Apr 6, 2016 at 9:41 AM Horacio Duran 
wrote:

> As a non English native myself I find destroy to be much more final than
> kill, to me destroy sounds like kill and then burn just in case, but I
> don't know if this extends to other non English speakers too.
>
> On Wednesday, 6 April 2016, Nate Finch  wrote:
>
>> Also +1 to Andrew's proposal.  In particular, the difference between kill
>> and destroy is pretty arbitrary from a vocabulary standpoint, so it's not
>> clear which one is the default and which one is the extreme measure.  A
>> flag on destroy is a lot more clear in that regard (and reduces the number
>> of commands needed).
>>
>> On Wed, Apr 6, 2016 at 8:41 AM Horacio Duran 
>> wrote:
>>
>>> Strong +1 to what Andrew just proposed
>>>
>>> On Wednesday, 6 April 2016, Andrew Wilkins 
>>> wrote:
>>>
 On Wed, Apr 6, 2016 at 7:35 PM Rick Harding 
 wrote:

> +1 to the -1 of a new command for this. I'd like to raise the
> discussion with the technical board as I'd like understand why the change
> the change that the team had to make made it impossible for 
> kill-controller
> to function and what we could do to allow the team to remove legacy code,
> but still be able to kill off things.
>

 Sorry, I probably should have started a new thread; this is orthogonal.
 Still worth talking about with the board, but orthogonal to removing
 details of a controller. You might "juju register" someone else's
 controller, and then want to remove it from your client without destroying
 it.

 I think the UX could do with rethinking. There's a few issues:
  (1) It's too easy to lose resources via kill-controller. See:
 https://bugs.launchpad.net/juju-core/+bug/1559701 and
 https://bugs.launchpad.net/juju-core/+bug/1566011
  (2) It's not clear from the name what kill-controller vs.
 destroy-controller is, and so it's easy to assume they either do the same
 thing, or just randomly choose one and run it. That leads to (1) happening
 more than we'd like or expect.
  (3) destroy-controller is harder to use than kill-controller for the
 standard case of destroying the controller and all of its hosted models.
 You have to pass "--destroy-all-models" to destroy-controller, which you
 don't have to pass to kill-controller. I don't understand the point of
 that, given that you're already asked whether you want to destroy the
 controller or not.

 What I would like to see is:
  * kill-controller to be dropped
  * destroy-controller's --destroy-all-models flag to be dropped, and
 implied by the accepted prompt (or -y)
  * destroy-controller to take on a --force flag, causing it to do what
 kill-controller does now, and what destroy-environment --force used to do
  * a new command to remove a controller from the client

 Why a new command? Because removing/forgetting is orthogonal to
 destroying. It's plain weird to say "kill-controller --forget" (or
 --cleanup, or whatever) if you're removing details of a live controller
 that you just don't want to use any more.

 Cheers,
 Andrew

 On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>> cheryl.jenni...@canonical.com> wrote:
>>
>>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>>
>>> We should provide a way to clean up controllers without making the
>>> user manually edit juju's files.
>>>
>>
>> Unless anyone objects, or has a better spelling, I will be adding a
>> command to do this:
>>
>> juju purge-controller 
>>
>> The command will require a "-y" or prompt for confirmation, like
>> kill-controller. It will not attempt to destroy the controller, it will
>> just remove the details of it from the client.
>>
>> (Alternative suggestion for spelling: "juju forget-controller".
>> Purge-controller may suggest that we're purging a controller of its
>> contents, rather than purging the controller from the client?)
>>
>> Cheers,
>> Andrew
>>
>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
>>> wrote:
>>>
 This just happened to me, too.  Kill-controller needs to work if at
 all possible.  That's the whole point.  And yes, users may not hit 
 specific
 problems, but devs do, and that wastes our time trying to figure out 
 how to
 manually clean up the garbage.

 On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
 rick.hard...@canonical.com> wrote:

Re: Unable to kill-controller

[Horacio Duran]

As a non English native myself I find destroy to be much more final than
kill, to me destroy sounds like kill and then burn just in case, but I
don't know if this extends to other non English speakers too.

On Wednesday, 6 April 2016, Nate Finch  wrote:

> Also +1 to Andrew's proposal.  In particular, the difference between kill
> and destroy is pretty arbitrary from a vocabulary standpoint, so it's not
> clear which one is the default and which one is the extreme measure.  A
> flag on destroy is a lot more clear in that regard (and reduces the number
> of commands needed).
>
> On Wed, Apr 6, 2016 at 8:41 AM Horacio Duran  > wrote:
>
>> Strong +1 to what Andrew just proposed
>>
>> On Wednesday, 6 April 2016, Andrew Wilkins > > wrote:
>>
>>> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding 
>>> wrote:
>>>
 +1 to the -1 of a new command for this. I'd like to raise the
 discussion with the technical board as I'd like understand why the change
 the change that the team had to make made it impossible for kill-controller
 to function and what we could do to allow the team to remove legacy code,
 but still be able to kill off things.

>>>
>>> Sorry, I probably should have started a new thread; this is orthogonal.
>>> Still worth talking about with the board, but orthogonal to removing
>>> details of a controller. You might "juju register" someone else's
>>> controller, and then want to remove it from your client without destroying
>>> it.
>>>
>>> I think the UX could do with rethinking. There's a few issues:
>>>  (1) It's too easy to lose resources via kill-controller. See:
>>> https://bugs.launchpad.net/juju-core/+bug/1559701 and
>>> https://bugs.launchpad.net/juju-core/+bug/1566011
>>>  (2) It's not clear from the name what kill-controller vs.
>>> destroy-controller is, and so it's easy to assume they either do the same
>>> thing, or just randomly choose one and run it. That leads to (1) happening
>>> more than we'd like or expect.
>>>  (3) destroy-controller is harder to use than kill-controller for the
>>> standard case of destroying the controller and all of its hosted models.
>>> You have to pass "--destroy-all-models" to destroy-controller, which you
>>> don't have to pass to kill-controller. I don't understand the point of
>>> that, given that you're already asked whether you want to destroy the
>>> controller or not.
>>>
>>> What I would like to see is:
>>>  * kill-controller to be dropped
>>>  * destroy-controller's --destroy-all-models flag to be dropped, and
>>> implied by the accepted prompt (or -y)
>>>  * destroy-controller to take on a --force flag, causing it to do what
>>> kill-controller does now, and what destroy-environment --force used to do
>>>  * a new command to remove a controller from the client
>>>
>>> Why a new command? Because removing/forgetting is orthogonal to
>>> destroying. It's plain weird to say "kill-controller --forget" (or
>>> --cleanup, or whatever) if you're removing details of a live controller
>>> that you just don't want to use any more.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <
 andrew.wilk...@canonical.com> wrote:

> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
> cheryl.jenni...@canonical.com> wrote:
>
>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>
>> We should provide a way to clean up controllers without making the
>> user manually edit juju's files.
>>
>
> Unless anyone objects, or has a better spelling, I will be adding a
> command to do this:
>
> juju purge-controller 
>
> The command will require a "-y" or prompt for confirmation, like
> kill-controller. It will not attempt to destroy the controller, it will
> just remove the details of it from the client.
>
> (Alternative suggestion for spelling: "juju forget-controller".
> Purge-controller may suggest that we're purging a controller of its
> contents, rather than purging the controller from the client?)
>
> Cheers,
> Andrew
>
> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
>> wrote:
>>
>>> This just happened to me, too.  Kill-controller needs to work if at
>>> all possible.  That's the whole point.  And yes, users may not hit 
>>> specific
>>> problems, but devs do, and that wastes our time trying to figure out 
>>> how to
>>> manually clean up the garbage.
>>>
>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
>>> rick.hard...@canonical.com> wrote:
>>>
 On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
 andrew.wilk...@canonical.com> wrote:

> In a non-beta release we would 

Re: Unable to kill-controller

[Nate Finch]

Also +1 to Andrew's proposal.  In particular, the difference between kill
and destroy is pretty arbitrary from a vocabulary standpoint, so it's not
clear which one is the default and which one is the extreme measure.  A
flag on destroy is a lot more clear in that regard (and reduces the number
of commands needed).

On Wed, Apr 6, 2016 at 8:41 AM Horacio Duran 
wrote:

> Strong +1 to what Andrew just proposed
>
> On Wednesday, 6 April 2016, Andrew Wilkins 
> wrote:
>
>> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding 
>> wrote:
>>
>>> +1 to the -1 of a new command for this. I'd like to raise the discussion
>>> with the technical board as I'd like understand why the change the change
>>> that the team had to make made it impossible for kill-controller to
>>> function and what we could do to allow the team to remove legacy code, but
>>> still be able to kill off things.
>>>
>>
>> Sorry, I probably should have started a new thread; this is orthogonal.
>> Still worth talking about with the board, but orthogonal to removing
>> details of a controller. You might "juju register" someone else's
>> controller, and then want to remove it from your client without destroying
>> it.
>>
>> I think the UX could do with rethinking. There's a few issues:
>>  (1) It's too easy to lose resources via kill-controller. See:
>> https://bugs.launchpad.net/juju-core/+bug/1559701 and
>> https://bugs.launchpad.net/juju-core/+bug/1566011
>>  (2) It's not clear from the name what kill-controller vs.
>> destroy-controller is, and so it's easy to assume they either do the same
>> thing, or just randomly choose one and run it. That leads to (1) happening
>> more than we'd like or expect.
>>  (3) destroy-controller is harder to use than kill-controller for the
>> standard case of destroying the controller and all of its hosted models.
>> You have to pass "--destroy-all-models" to destroy-controller, which you
>> don't have to pass to kill-controller. I don't understand the point of
>> that, given that you're already asked whether you want to destroy the
>> controller or not.
>>
>> What I would like to see is:
>>  * kill-controller to be dropped
>>  * destroy-controller's --destroy-all-models flag to be dropped, and
>> implied by the accepted prompt (or -y)
>>  * destroy-controller to take on a --force flag, causing it to do what
>> kill-controller does now, and what destroy-environment --force used to do
>>  * a new command to remove a controller from the client
>>
>> Why a new command? Because removing/forgetting is orthogonal to
>> destroying. It's plain weird to say "kill-controller --forget" (or
>> --cleanup, or whatever) if you're removing details of a live controller
>> that you just don't want to use any more.
>>
>> Cheers,
>> Andrew
>>
>> On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
 On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
 cheryl.jenni...@canonical.com> wrote:

> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>
> We should provide a way to clean up controllers without making the
> user manually edit juju's files.
>

 Unless anyone objects, or has a better spelling, I will be adding a
 command to do this:

 juju purge-controller 

 The command will require a "-y" or prompt for confirmation, like
 kill-controller. It will not attempt to destroy the controller, it will
 just remove the details of it from the client.

 (Alternative suggestion for spelling: "juju forget-controller".
 Purge-controller may suggest that we're purging a controller of its
 contents, rather than purging the controller from the client?)

 Cheers,
 Andrew

 On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
> wrote:
>
>> This just happened to me, too.  Kill-controller needs to work if at
>> all possible.  That's the whole point.  And yes, users may not hit 
>> specific
>> problems, but devs do, and that wastes our time trying to figure out how 
>> to
>> manually clean up the garbage.
>>
>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
>> rick.hard...@canonical.com> wrote:
>>
>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
 In a non-beta release we would make sure that the config changes
 aren't backwards incompatible.

>>>
>>> I think this is the key thing. I think that kill-controller is an
>>> exception to this rule. I think we should always at least give the user 
>>> the
>>> ability to remove their stuff and start over with the new alpha/beta/rc
>>> release. I'd like to ask us to explore making kill-controller an 
>>> exception
>>> to this policy and that if tests prove we can't bootstrap on one beta 
>>> and

Re: Unable to kill-controller

[Horacio Duran]

Strong +1 to what Andrew just proposed

On Wednesday, 6 April 2016, Andrew Wilkins 
wrote:

> On Wed, Apr 6, 2016 at 7:35 PM Rick Harding  > wrote:
>
>> +1 to the -1 of a new command for this. I'd like to raise the discussion
>> with the technical board as I'd like understand why the change the change
>> that the team had to make made it impossible for kill-controller to
>> function and what we could do to allow the team to remove legacy code, but
>> still be able to kill off things.
>>
>
> Sorry, I probably should have started a new thread; this is orthogonal.
> Still worth talking about with the board, but orthogonal to removing
> details of a controller. You might "juju register" someone else's
> controller, and then want to remove it from your client without destroying
> it.
>
> I think the UX could do with rethinking. There's a few issues:
>  (1) It's too easy to lose resources via kill-controller. See:
> https://bugs.launchpad.net/juju-core/+bug/1559701 and
> https://bugs.launchpad.net/juju-core/+bug/1566011
>  (2) It's not clear from the name what kill-controller vs.
> destroy-controller is, and so it's easy to assume they either do the same
> thing, or just randomly choose one and run it. That leads to (1) happening
> more than we'd like or expect.
>  (3) destroy-controller is harder to use than kill-controller for the
> standard case of destroying the controller and all of its hosted models.
> You have to pass "--destroy-all-models" to destroy-controller, which you
> don't have to pass to kill-controller. I don't understand the point of
> that, given that you're already asked whether you want to destroy the
> controller or not.
>
> What I would like to see is:
>  * kill-controller to be dropped
>  * destroy-controller's --destroy-all-models flag to be dropped, and
> implied by the accepted prompt (or -y)
>  * destroy-controller to take on a --force flag, causing it to do what
> kill-controller does now, and what destroy-environment --force used to do
>  * a new command to remove a controller from the client
>
> Why a new command? Because removing/forgetting is orthogonal to
> destroying. It's plain weird to say "kill-controller --forget" (or
> --cleanup, or whatever) if you're removing details of a live controller
> that you just don't want to use any more.
>
> Cheers,
> Andrew
>
> On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com
>> > wrote:
>>
>>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>>> cheryl.jenni...@canonical.com
>>> > wrote:
>>>
 Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059

 We should provide a way to clean up controllers without making the user
 manually edit juju's files.

>>>
>>> Unless anyone objects, or has a better spelling, I will be adding a
>>> command to do this:
>>>
>>> juju purge-controller 
>>>
>>> The command will require a "-y" or prompt for confirmation, like
>>> kill-controller. It will not attempt to destroy the controller, it will
>>> just remove the details of it from the client.
>>>
>>> (Alternative suggestion for spelling: "juju forget-controller".
>>> Purge-controller may suggest that we're purging a controller of its
>>> contents, rather than purging the controller from the client?)
>>>
>>> Cheers,
>>> Andrew
>>>
>>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch > wrote:

> This just happened to me, too.  Kill-controller needs to work if at
> all possible.  That's the whole point.  And yes, users may not hit 
> specific
> problems, but devs do, and that wastes our time trying to figure out how 
> to
> manually clean up the garbage.
>
> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
> rick.hard...@canonical.com
> > wrote:
>
>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com
>> >
>> wrote:
>>
>>> In a non-beta release we would make sure that the config changes
>>> aren't backwards incompatible.
>>>
>>
>> I think this is the key thing. I think that kill-controller is an
>> exception to this rule. I think we should always at least give the user 
>> the
>> ability to remove their stuff and start over with the new alpha/beta/rc
>> release. I'd like to ask us to explore making kill-controller an 
>> exception
>> to this policy and that if tests prove we can't bootstrap on one beta and
>> kill with trunk that it's a blocking bug for us.
>> --
>> Juju-dev mailing list
>> 

Re: Unable to kill-controller

[Andrew Wilkins]

On Wed, Apr 6, 2016 at 7:35 PM Rick Harding 
wrote:

> +1 to the -1 of a new command for this. I'd like to raise the discussion
> with the technical board as I'd like understand why the change the change
> that the team had to make made it impossible for kill-controller to
> function and what we could do to allow the team to remove legacy code, but
> still be able to kill off things.
>

Sorry, I probably should have started a new thread; this is orthogonal.
Still worth talking about with the board, but orthogonal to removing
details of a controller. You might "juju register" someone else's
controller, and then want to remove it from your client without destroying
it.

I think the UX could do with rethinking. There's a few issues:
 (1) It's too easy to lose resources via kill-controller. See:
https://bugs.launchpad.net/juju-core/+bug/1559701 and
https://bugs.launchpad.net/juju-core/+bug/1566011
 (2) It's not clear from the name what kill-controller vs.
destroy-controller is, and so it's easy to assume they either do the same
thing, or just randomly choose one and run it. That leads to (1) happening
more than we'd like or expect.
 (3) destroy-controller is harder to use than kill-controller for the
standard case of destroying the controller and all of its hosted models.
You have to pass "--destroy-all-models" to destroy-controller, which you
don't have to pass to kill-controller. I don't understand the point of
that, given that you're already asked whether you want to destroy the
controller or not.

What I would like to see is:
 * kill-controller to be dropped
 * destroy-controller's --destroy-all-models flag to be dropped, and
implied by the accepted prompt (or -y)
 * destroy-controller to take on a --force flag, causing it to do what
kill-controller does now, and what destroy-environment --force used to do
 * a new command to remove a controller from the client

Why a new command? Because removing/forgetting is orthogonal to destroying.
It's plain weird to say "kill-controller --forget" (or --cleanup, or
whatever) if you're removing details of a live controller that you just
don't want to use any more.

Cheers,
Andrew

On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins 
> wrote:
>
>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>> cheryl.jenni...@canonical.com> wrote:
>>
>>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>>
>>> We should provide a way to clean up controllers without making the user
>>> manually edit juju's files.
>>>
>>
>> Unless anyone objects, or has a better spelling, I will be adding a
>> command to do this:
>>
>> juju purge-controller 
>>
>> The command will require a "-y" or prompt for confirmation, like
>> kill-controller. It will not attempt to destroy the controller, it will
>> just remove the details of it from the client.
>>
>> (Alternative suggestion for spelling: "juju forget-controller".
>> Purge-controller may suggest that we're purging a controller of its
>> contents, rather than purging the controller from the client?)
>>
>> Cheers,
>> Andrew
>>
>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
>>> wrote:
>>>
 This just happened to me, too.  Kill-controller needs to work if at all
 possible.  That's the whole point.  And yes, users may not hit specific
 problems, but devs do, and that wastes our time trying to figure out how to
 manually clean up the garbage.

 On Mon, Apr 4, 2016 at 8:33 AM Rick Harding 
 wrote:

> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> In a non-beta release we would make sure that the config changes
>> aren't backwards incompatible.
>>
>
> I think this is the key thing. I think that kill-controller is an
> exception to this rule. I think we should always at least give the user 
> the
> ability to remove their stuff and start over with the new alpha/beta/rc
> release. I'd like to ask us to explore making kill-controller an exception
> to this policy and that if tests prove we can't bootstrap on one beta and
> kill with trunk that it's a blocking bug for us.
> --
> 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


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

Re: Unable to kill-controller

[Nate Finch]

I agree with Horacio, forget controller is good becsude it only does what
you expect, whereas failing to kill a controller but making it look like
success is bad.

Honestly, I think the problem is kill controller that should just go back
to being a flag on destroy controller.  Then we'd just have destroy and
forget.

On Wed, Apr 6, 2016, 6:59 AM Horacio Duran 
wrote:

> The issue I see with that approach is that in that case kill-controller
> might be doing less than you expect instead of more, suppose the controller
> is having transient issues and kill controller cannot reach the cloud for
> deletion, this would forget the controller and leave it in the cloud,
> forget-controller instead tells us very clearly what is going to happen,
> the change is going to be local and not affect the controller.
> My 2c
>
>
> On Wednesday, 6 April 2016, Nick Veitch  wrote:
>
>> just my tuppence
>>
>> instead of having another command, can't we just add this as an option to
>> kill-controller?
>>
>> juju kill-controller --cleanup 
>>
>>
>>
>> On 6 April 2016 at 11:05, Horacio Duran 
>> wrote:
>>
>>>
>>> I might be biased by years of apt-get but purge makes me think that you
>>> are going to do what kill is supposed to do, forget sound more aligned whit
>>> what you are really aiming to.
>>>
>>> On Wednesday, 6 April 2016, Andrew Wilkins 
>>> wrote:
>>>
 On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
 cheryl.jenni...@canonical.com> wrote:

> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>
> We should provide a way to clean up controllers without making the
> user manually edit juju's files.
>

 Unless anyone objects, or has a better spelling, I will be adding a
 command to do this:

 juju purge-controller 

 The command will require a "-y" or prompt for confirmation, like
 kill-controller. It will not attempt to destroy the controller, it will
 just remove the details of it from the client.

 (Alternative suggestion for spelling: "juju forget-controller".
 Purge-controller may suggest that we're purging a controller of its
 contents, rather than purging the controller from the client?)

 Cheers,
 Andrew

 On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
> wrote:
>
>> This just happened to me, too.  Kill-controller needs to work if at
>> all possible.  That's the whole point.  And yes, users may not hit 
>> specific
>> problems, but devs do, and that wastes our time trying to figure out how 
>> to
>> manually clean up the garbage.
>>
>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
>> rick.hard...@canonical.com> wrote:
>>
>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
 In a non-beta release we would make sure that the config changes
 aren't backwards incompatible.

>>>
>>> I think this is the key thing. I think that kill-controller is an
>>> exception to this rule. I think we should always at least give the user 
>>> the
>>> ability to remove their stuff and start over with the new alpha/beta/rc
>>> release. I'd like to ask us to explore making kill-controller an 
>>> exception
>>> to this policy and that if tests prove we can't bootstrap on one beta 
>>> and
>>> kill with trunk that it's a blocking bug for us.
>>> --
>>> 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
>>
>>
>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>>
>>
>>
>> --
>> Nick Veitch,
>> CDO Documentation
>> Canonical
>>
> --
> 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: Unable to kill-controller

[Rick Harding]

+1 to the -1 of a new command for this. I'd like to raise the discussion
with the technical board as I'd like understand why the change the change
that the team had to make made it impossible for kill-controller to
function and what we could do to allow the team to remove legacy code, but
still be able to kill off things.

On Tue, Apr 5, 2016 at 11:55 PM Andrew Wilkins 
wrote:

> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
> cheryl.jenni...@canonical.com> wrote:
>
>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>
>> We should provide a way to clean up controllers without making the user
>> manually edit juju's files.
>>
>
> Unless anyone objects, or has a better spelling, I will be adding a
> command to do this:
>
> juju purge-controller 
>
> The command will require a "-y" or prompt for confirmation, like
> kill-controller. It will not attempt to destroy the controller, it will
> just remove the details of it from the client.
>
> (Alternative suggestion for spelling: "juju forget-controller".
> Purge-controller may suggest that we're purging a controller of its
> contents, rather than purging the controller from the client?)
>
> Cheers,
> Andrew
>
> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
>> wrote:
>>
>>> This just happened to me, too.  Kill-controller needs to work if at all
>>> possible.  That's the whole point.  And yes, users may not hit specific
>>> problems, but devs do, and that wastes our time trying to figure out how to
>>> manually clean up the garbage.
>>>
>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding 
>>> wrote:
>>>
 On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
 andrew.wilk...@canonical.com> wrote:

> In a non-beta release we would make sure that the config changes
> aren't backwards incompatible.
>

 I think this is the key thing. I think that kill-controller is an
 exception to this rule. I think we should always at least give the user the
 ability to remove their stuff and start over with the new alpha/beta/rc
 release. I'd like to ask us to explore making kill-controller an exception
 to this policy and that if tests prove we can't bootstrap on one beta and
 kill with trunk that it's a blocking bug for us.
 --
 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
>>>
>>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Nick Veitch]

Sure, I am just concerned about a proliferation of commands to do the same
(ultimately) task

destroy-controller
kill-controller
forget/purge-controller



On 6 April 2016 at 11:59, Horacio Duran  wrote:

> The issue I see with that approach is that in that case kill-controller
> might be doing less than you expect instead of more, suppose the controller
> is having transient issues and kill controller cannot reach the cloud for
> deletion, this would forget the controller and leave it in the cloud,
> forget-controller instead tells us very clearly what is going to happen,
> the change is going to be local and not affect the controller.
> My 2c
>
>
> On Wednesday, 6 April 2016, Nick Veitch  wrote:
>
>> just my tuppence
>>
>> instead of having another command, can't we just add this as an option to
>> kill-controller?
>>
>> juju kill-controller --cleanup 
>>
>>
>>
>> On 6 April 2016 at 11:05, Horacio Duran 
>> wrote:
>>
>>>
>>> I might be biased by years of apt-get but purge makes me think that you
>>> are going to do what kill is supposed to do, forget sound more aligned whit
>>> what you are really aiming to.
>>>
>>> On Wednesday, 6 April 2016, Andrew Wilkins 
>>> wrote:
>>>
 On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
 cheryl.jenni...@canonical.com> wrote:

> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>
> We should provide a way to clean up controllers without making the
> user manually edit juju's files.
>

 Unless anyone objects, or has a better spelling, I will be adding a
 command to do this:

 juju purge-controller 

 The command will require a "-y" or prompt for confirmation, like
 kill-controller. It will not attempt to destroy the controller, it will
 just remove the details of it from the client.

 (Alternative suggestion for spelling: "juju forget-controller".
 Purge-controller may suggest that we're purging a controller of its
 contents, rather than purging the controller from the client?)

 Cheers,
 Andrew

 On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
> wrote:
>
>> This just happened to me, too.  Kill-controller needs to work if at
>> all possible.  That's the whole point.  And yes, users may not hit 
>> specific
>> problems, but devs do, and that wastes our time trying to figure out how 
>> to
>> manually clean up the garbage.
>>
>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
>> rick.hard...@canonical.com> wrote:
>>
>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
 In a non-beta release we would make sure that the config changes
 aren't backwards incompatible.

>>>
>>> I think this is the key thing. I think that kill-controller is an
>>> exception to this rule. I think we should always at least give the user 
>>> the
>>> ability to remove their stuff and start over with the new alpha/beta/rc
>>> release. I'd like to ask us to explore making kill-controller an 
>>> exception
>>> to this policy and that if tests prove we can't bootstrap on one beta 
>>> and
>>> kill with trunk that it's a blocking bug for us.
>>> --
>>> 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
>>
>>
>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>>
>>
>>
>> --
>> Nick Veitch,
>> CDO Documentation
>> Canonical
>>
>


-- 
Nick Veitch,
CDO Documentation
Canonical
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Horacio Duran]

The issue I see with that approach is that in that case kill-controller
might be doing less than you expect instead of more, suppose the controller
is having transient issues and kill controller cannot reach the cloud for
deletion, this would forget the controller and leave it in the cloud,
forget-controller instead tells us very clearly what is going to happen,
the change is going to be local and not affect the controller.
My 2c

On Wednesday, 6 April 2016, Nick Veitch  wrote:

> just my tuppence
>
> instead of having another command, can't we just add this as an option to
> kill-controller?
>
> juju kill-controller --cleanup 
>
>
>
> On 6 April 2016 at 11:05, Horacio Duran  > wrote:
>
>>
>> I might be biased by years of apt-get but purge makes me think that you
>> are going to do what kill is supposed to do, forget sound more aligned whit
>> what you are really aiming to.
>>
>> On Wednesday, 6 April 2016, Andrew Wilkins > > wrote:
>>
>>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>>> cheryl.jenni...@canonical.com> wrote:
>>>
 Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059

 We should provide a way to clean up controllers without making the user
 manually edit juju's files.

>>>
>>> Unless anyone objects, or has a better spelling, I will be adding a
>>> command to do this:
>>>
>>> juju purge-controller 
>>>
>>> The command will require a "-y" or prompt for confirmation, like
>>> kill-controller. It will not attempt to destroy the controller, it will
>>> just remove the details of it from the client.
>>>
>>> (Alternative suggestion for spelling: "juju forget-controller".
>>> Purge-controller may suggest that we're purging a controller of its
>>> contents, rather than purging the controller from the client?)
>>>
>>> Cheers,
>>> Andrew
>>>
>>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
 wrote:

> This just happened to me, too.  Kill-controller needs to work if at
> all possible.  That's the whole point.  And yes, users may not hit 
> specific
> problems, but devs do, and that wastes our time trying to figure out how 
> to
> manually clean up the garbage.
>
> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding <
> rick.hard...@canonical.com> wrote:
>
>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> In a non-beta release we would make sure that the config changes
>>> aren't backwards incompatible.
>>>
>>
>> I think this is the key thing. I think that kill-controller is an
>> exception to this rule. I think we should always at least give the user 
>> the
>> ability to remove their stuff and start over with the new alpha/beta/rc
>> release. I'd like to ask us to explore making kill-controller an 
>> exception
>> to this policy and that if tests prove we can't bootstrap on one beta and
>> kill with trunk that it's a blocking bug for us.
>> --
>> 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
>
>

>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> 
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
>
> --
> Nick Veitch,
> CDO Documentation
> Canonical
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Nick Veitch]

just my tuppence

instead of having another command, can't we just add this as an option to
kill-controller?

juju kill-controller --cleanup 



On 6 April 2016 at 11:05, Horacio Duran  wrote:

>
> I might be biased by years of apt-get but purge makes me think that you
> are going to do what kill is supposed to do, forget sound more aligned whit
> what you are really aiming to.
>
> On Wednesday, 6 April 2016, Andrew Wilkins 
> wrote:
>
>> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
>> cheryl.jenni...@canonical.com> wrote:
>>
>>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>>
>>> We should provide a way to clean up controllers without making the user
>>> manually edit juju's files.
>>>
>>
>> Unless anyone objects, or has a better spelling, I will be adding a
>> command to do this:
>>
>> juju purge-controller 
>>
>> The command will require a "-y" or prompt for confirmation, like
>> kill-controller. It will not attempt to destroy the controller, it will
>> just remove the details of it from the client.
>>
>> (Alternative suggestion for spelling: "juju forget-controller".
>> Purge-controller may suggest that we're purging a controller of its
>> contents, rather than purging the controller from the client?)
>>
>> Cheers,
>> Andrew
>>
>> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch 
>>> wrote:
>>>
 This just happened to me, too.  Kill-controller needs to work if at all
 possible.  That's the whole point.  And yes, users may not hit specific
 problems, but devs do, and that wastes our time trying to figure out how to
 manually clean up the garbage.

 On Mon, Apr 4, 2016 at 8:33 AM Rick Harding 
 wrote:

> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> In a non-beta release we would make sure that the config changes
>> aren't backwards incompatible.
>>
>
> I think this is the key thing. I think that kill-controller is an
> exception to this rule. I think we should always at least give the user 
> the
> ability to remove their stuff and start over with the new alpha/beta/rc
> release. I'd like to ask us to explore making kill-controller an exception
> to this policy and that if tests prove we can't bootstrap on one beta and
> kill with trunk that it's a blocking bug for us.
> --
> 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


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


-- 
Nick Veitch,
CDO Documentation
Canonical
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Horacio Duran]

I might be biased by years of apt-get but purge makes me think that you are
going to do what kill is supposed to do, forget sound more aligned whit
what you are really aiming to.

On Wednesday, 6 April 2016, Andrew Wilkins 
wrote:

> On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
> cheryl.jenni...@canonical.com
> > wrote:
>
>> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>>
>> We should provide a way to clean up controllers without making the user
>> manually edit juju's files.
>>
>
> Unless anyone objects, or has a better spelling, I will be adding a
> command to do this:
>
> juju purge-controller 
>
> The command will require a "-y" or prompt for confirmation, like
> kill-controller. It will not attempt to destroy the controller, it will
> just remove the details of it from the client.
>
> (Alternative suggestion for spelling: "juju forget-controller".
> Purge-controller may suggest that we're purging a controller of its
> contents, rather than purging the controller from the client?)
>
> Cheers,
> Andrew
>
> On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch > > wrote:
>>
>>> This just happened to me, too.  Kill-controller needs to work if at all
>>> possible.  That's the whole point.  And yes, users may not hit specific
>>> problems, but devs do, and that wastes our time trying to figure out how to
>>> manually clean up the garbage.
>>>
>>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding >> > wrote:
>>>
 On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
 andrew.wilk...@canonical.com
 > wrote:

> In a non-beta release we would make sure that the config changes
> aren't backwards incompatible.
>

 I think this is the key thing. I think that kill-controller is an
 exception to this rule. I think we should always at least give the user the
 ability to remove their stuff and start over with the new alpha/beta/rc
 release. I'd like to ask us to explore making kill-controller an exception
 to this policy and that if tests prove we can't bootstrap on one beta and
 kill with trunk that it's a blocking bug for us.
 --
 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
>>>
>>>
>>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Andrew Wilkins]

On Tue, Apr 5, 2016 at 2:29 AM Cheryl Jennings <
cheryl.jenni...@canonical.com> wrote:

> Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059
>
> We should provide a way to clean up controllers without making the user
> manually edit juju's files.
>

Unless anyone objects, or has a better spelling, I will be adding a command
to do this:

juju purge-controller 

The command will require a "-y" or prompt for confirmation, like
kill-controller. It will not attempt to destroy the controller, it will
just remove the details of it from the client.

(Alternative suggestion for spelling: "juju forget-controller".
Purge-controller may suggest that we're purging a controller of its
contents, rather than purging the controller from the client?)

Cheers,
Andrew

On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch  wrote:
>
>> This just happened to me, too.  Kill-controller needs to work if at all
>> possible.  That's the whole point.  And yes, users may not hit specific
>> problems, but devs do, and that wastes our time trying to figure out how to
>> manually clean up the garbage.
>>
>> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding 
>> wrote:
>>
>>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
 In a non-beta release we would make sure that the config changes aren't
 backwards incompatible.

>>>
>>> I think this is the key thing. I think that kill-controller is an
>>> exception to this rule. I think we should always at least give the user the
>>> ability to remove their stuff and start over with the new alpha/beta/rc
>>> release. I'd like to ask us to explore making kill-controller an exception
>>> to this policy and that if tests prove we can't bootstrap on one beta and
>>> kill with trunk that it's a blocking bug for us.
>>> --
>>> 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
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Ian Booth]

On 05/04/16 11:12, Andrew Wilkins wrote:
> On Mon, Apr 4, 2016 at 8:32 PM Rick Harding 
> wrote:
> 
>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> In a non-beta release we would make sure that the config changes aren't
>>> backwards incompatible.
>>>
>>
>> I think this is the key thing. I think that kill-controller is an
>> exception to this rule. I think we should always at least give the user the
>> ability to remove their stuff and start over with the new alpha/beta/rc
>> release. I'd like to ask us to explore making kill-controller an exception
>> to this policy and that if tests prove we can't bootstrap on one beta and
>> kill with trunk that it's a blocking bug for us.
>>
> 
> Generally agreed, but in this case I made the choice of improving the
> quality of the code base overall at the cost of breaking kill-controller in
> between betas. I think it's fair to have a temporary annoyance for
> developers and early adopters (of a beta only!) to improve the quality in
> the long term. Major, breaking versions don't come around very often, so
> we're trying to wipe the slate as clean as possible. The alternative is we
> continue building up cruft forever so we could support that one edge case
> that existed for 5 minutes.
>

To backup what Andrew said, we had the choice of an annoyance between betas for
early adopters/testers, vs a much larger effort and cost to develop extra code
and tests to support a very temporary edge case. We'd rather put our at capacity
development effort to finishing features for the release. Having said that, we
should have included in the releases notes an item to inform people that any
beta2 environments could only be killed with beta2 clients. We'll do better
communicating those beta limitations next time.


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

Re: Unable to kill-controller

[Andrew Wilkins]

On Mon, Apr 4, 2016 at 8:32 PM Rick Harding 
wrote:

> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> In a non-beta release we would make sure that the config changes aren't
>> backwards incompatible.
>>
>
> I think this is the key thing. I think that kill-controller is an
> exception to this rule. I think we should always at least give the user the
> ability to remove their stuff and start over with the new alpha/beta/rc
> release. I'd like to ask us to explore making kill-controller an exception
> to this policy and that if tests prove we can't bootstrap on one beta and
> kill with trunk that it's a blocking bug for us.
>

Generally agreed, but in this case I made the choice of improving the
quality of the code base overall at the cost of breaking kill-controller in
between betas. I think it's fair to have a temporary annoyance for
developers and early adopters (of a beta only!) to improve the quality in
the long term. Major, breaking versions don't come around very often, so
we're trying to wipe the slate as clean as possible. The alternative is we
continue building up cruft forever so we could support that one edge case
that existed for 5 minutes.

So I agree that kill-controller should always work. We should only need
provider configuration if it's not possible to destroy the provider via the
API; and provider configuration compatibility should not be an issue if
we're destroying via the API.

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

Re: Unable to kill-controller

[Cheryl Jennings]

Relevant bug:  https://bugs.launchpad.net/juju-core/+bug/1553059

We should provide a way to clean up controllers without making the user
manually edit juju's files.

On Mon, Apr 4, 2016 at 7:05 AM, Nate Finch  wrote:

> This just happened to me, too.  Kill-controller needs to work if at all
> possible.  That's the whole point.  And yes, users may not hit specific
> problems, but devs do, and that wastes our time trying to figure out how to
> manually clean up the garbage.
>
> On Mon, Apr 4, 2016 at 8:33 AM Rick Harding 
> wrote:
>
>> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> In a non-beta release we would make sure that the config changes aren't
>>> backwards incompatible.
>>>
>>
>> I think this is the key thing. I think that kill-controller is an
>> exception to this rule. I think we should always at least give the user the
>> ability to remove their stuff and start over with the new alpha/beta/rc
>> release. I'd like to ask us to explore making kill-controller an exception
>> to this policy and that if tests prove we can't bootstrap on one beta and
>> kill with trunk that it's a blocking bug for us.
>> --
>> 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
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Nate Finch]

This just happened to me, too.  Kill-controller needs to work if at all
possible.  That's the whole point.  And yes, users may not hit specific
problems, but devs do, and that wastes our time trying to figure out how to
manually clean up the garbage.

On Mon, Apr 4, 2016 at 8:33 AM Rick Harding 
wrote:

> On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> In a non-beta release we would make sure that the config changes aren't
>> backwards incompatible.
>>
>
> I think this is the key thing. I think that kill-controller is an
> exception to this rule. I think we should always at least give the user the
> ability to remove their stuff and start over with the new alpha/beta/rc
> release. I'd like to ask us to explore making kill-controller an exception
> to this policy and that if tests prove we can't bootstrap on one beta and
> kill with trunk that it's a blocking bug for us.
> --
> 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: Unable to kill-controller

[Rick Harding]

On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins 
wrote:

> In a non-beta release we would make sure that the config changes aren't
> backwards incompatible.
>

I think this is the key thing. I think that kill-controller is an exception
to this rule. I think we should always at least give the user the ability
to remove their stuff and start over with the new alpha/beta/rc release.
I'd like to ask us to explore making kill-controller an exception to this
policy and that if tests prove we can't bootstrap on one beta and kill with
trunk that it's a blocking bug for us.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Unable to kill-controller

[Andrew Wilkins]

On Sun, Apr 3, 2016 at 9:45 PM John Meinel  wrote:

> I'm not sure what happened, but I can't bootstrap, and I can't
> kill-controller to try again. I started out with "failing to get
> controller-uuid". I then manually killed the machines, but now I get
> "unable to get bootstrap information".
>
> Clearly there is *some* bootstrap information, or I would be able to "juju
> bootstrap", but apparently there isn't enough information so I can't "juju
> kill-controller".
>
> I feel like we're missing something in our implementation. I realize this
> is *probably* just version skew, where I was using one of the earlier dev
> releases, and then it broke against a new dev release. However, it also
> feels like we're missing a more fundamental "kill should make due with the
> information it has, and cleanup". "juju destroy-environment --force" was
> our old big hammer to wipe the slate clean. But now our attempts at wiping
> the state clean all seem to trip up at every turn. The best I've found is
> to "rm -rf ~/.local/share/juju" but that, of course, means I lose *all* of
> my controllers and my credentials.
>
> It feels like things like "kill-controller" shouldn't be "allowed" to
> fail. Throwing exceptions during cleanup is usually something that isn't
> helpful.
>

kill-controller will first try to kill via the API; if that fails, it does
the equivalent of "destroy-environment --force". I don't think there's much
else we can do, is there?

We currently need one of two things: valid API connection details, or the
bootstrap configuration. In either case, it's going to break if the
configuration is invalid. In your case, you've got a missing
"controller-uuid" attribute, which was added as a mandatory attribute
between beta releases. In a non-beta release we would make sure that the
config changes aren't backwards incompatible.

Cheers,
Andrew

Thoughts?
>
> John
> =:->
>
> --
> 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: Unable to kill-controller

[Nick Veitch]

I had exactly the same problem yesterday, but I put it down to having
probably created the controller with beta2 and trying to kill it with
beta3. I also resorted to the nuclear option in the end and deleted
everything - I guess I could have been more circumspect and removed the
particular parts causing issues, but it wasn't a setup I cared about.

I think you are right that kill-controller ought to do just that, by
whatever means necessary.

On 3 April 2016 at 14:45, John Meinel  wrote:

> I'm not sure what happened, but I can't bootstrap, and I can't
> kill-controller to try again. I started out with "failing to get
> controller-uuid". I then manually killed the machines, but now I get
> "unable to get bootstrap information".
>
> Clearly there is *some* bootstrap information, or I would be able to "juju
> bootstrap", but apparently there isn't enough information so I can't "juju
> kill-controller".
>
> I feel like we're missing something in our implementation. I realize this
> is *probably* just version skew, where I was using one of the earlier dev
> releases, and then it broke against a new dev release. However, it also
> feels like we're missing a more fundamental "kill should make due with the
> information it has, and cleanup". "juju destroy-environment --force" was
> our old big hammer to wipe the slate clean. But now our attempts at wiping
> the state clean all seem to trip up at every turn. The best I've found is
> to "rm -rf ~/.local/share/juju" but that, of course, means I lose *all* of
> my controllers and my credentials.
>
> It feels like things like "kill-controller" shouldn't be "allowed" to
> fail. Throwing exceptions during cleanup is usually something that isn't
> helpful.
>
> Thoughts?
>
> John
> =:->
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>


-- 
Nick Veitch,
CDO Documentation
Canonical
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev