using juju unregister is unclear for controller removed by hand

[Heather Lanigan]

$ juju kill-controller -t 0 --yes remote-tuesday
Unable to open API: open connection timed out
ERROR getting controller environ: getting environ using bootstrap config from client store: Get https://10.0.0.223:8443/1.0: EOF
$ juju controllers
Use --refresh flag with this command to see the latest information.

Controller Model User Access Cloud/Region Models Machines HA Version
remote-tuesday default admin superuser lxd-remote/default 2 1 none 2.5-beta1

I was trying to remove a remote lxd cloud and forgot shuttle was not running (which is needed for the config). However juju still failed to remove the local controller data.

[Richard Harding (rharding)]

Is the controller still there at all? If it's gone then the unregister command is meant to remove local cache data about a controller. Typically it's built to remove a controller you were granted access to that might have gone away and you need to clean your own record of it, but it might be the right fix for this as well.

[Heather Lanigan (hmlanigan)]

This was my controller, not one registered. If it can't be reached, I expect kill-controller to clean up the local info.

[Richard Harding (rharding)]

I understand, but is there anything running on the provider? kill-controller is for avoiding the controller API and going straight to the cloud provider to clean up resources/etc. If there's nothing on the API there's nothing that distinguishes issues with the cloud API vs "it's gone, let's clean up local stuff". I'm wondering the state of the remote cloud API endpoint to help on what the best path is in this case.

[Heather Lanigan (hmlanigan)]

The node and controller machines are gone. I can't ping the cloud api ip.

This happens with a MaaS Cloud as well.

[Richard Harding (rharding)]

My concern is having kill-controller make a decision when it cannot tell the cloud api is unreachable vs gone. It's up to the user to know that it's gone and use unregister in that case using current tooling. I personally am -1 on making the code JFDI something there that could lead to users thinking things are done and gone when their wifi was down, or a vpn wasn't up, or other issue that the user should be directed to look into vs just removing the local cache right away.

[Tim Penhey (thumper)]

I'm with Rick on this one. This is why we created the unregister command.

As mentioned, the problem could be intermittent, or just a weird failure. Removing information about the controller when we hit problems is likely to cause more problems than it fixes.

[John A Meinel (jameinel)]

I agree, unregister exists to say "don't try to clean anything up, just
record that everything is gone". While "kill-controller" assumes there
should be something to clean up.

On Wed, Aug 29, 2018 at 3:33 AM, Tim Penhey <email address hidden>
wrote:

> I'm with Rick on this one. This is why we created the unregister
> command.
>
> As mentioned, the problem could be intermittent, or just a weird
> failure. Removing information about the controller when we hit problems
> is likely to cause more problems than it fixes.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1789443
>
> Title:
> juju kill-controller fails when no connection to lxd remote provider
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1789443/+subscriptions
>

[Heather Lanigan (hmlanigan)]

Can we update the unregister help? Given that the controller wasn't registered, using unregister never came to mind.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.