Shared controller in 2.0-rc2 user management appears broken

[Charles Butler]

I have several users defined in my controller:

charles@failbowl ~$ juju users
CONTROLLER: container-lab

NAME DISPLAY NAME ACCESS DATE CREATED LAST CONNECTION
admin* admin superuser 2016-09-29 just now
bcsaller superuser 2016-09-29 2016-09-29
kwmonroe superuser 2016-09-29 2016-09-29

When sharing this controller, most users we able to access and query the controller nearly instantly. My colleague mbruzek waited a few days and is now prompted for a password that he is unable to satisfy. I thought I would remove and re-add his user:

charles@failbowl ~$ juju remove-user mbruzek
WARNING! This command will remove the user "mbruzek" from the "container-lab" controller.

Continue (y/N)? y
ERROR "mbruzek" user not found

charles@failbowl ~$ juju add-user mbruzek
ERROR failed to create user: user already exists

charles@failbowl ~$ juju --version
2.0-rc2-xenial-amd64

As you can see, neither removing nor adding the account works, and its not listed in the users output. I'm not certain how this situation was created, but it appears the user management functions of a model can be a bit flakey.

[Matt Bruzek (mbruzek)]

Please take a look at this one, we would like to share controllers.

Here are the errors Chuck mentioned I was having with the login. I didn't know the password that Juju was looking for so I tried several different ones and never got it to work:

mbruzek@warhorse:~$ juju list-controllers
Use --refresh to see the latest information.

CONTROLLER MODEL USER ACCESS CLOUD/REGION MODELS MACHINES HA VERSION
amazon controller admin@local superuser aws/us-west-2 2 1 none 2.0-rc1
container-lab - mbruzek@local login - - - 2.0-rc1
containers* admin@local/container-ci - - - - - (unknown)

mbruzek@warhorse:~$ juju switch container-lab
containers:admin@local/container-ci -> container-lab (controller)

mbruzek@warhorse:~$ juju status
ERROR no model in focus

Please use "juju models" to see models available to you.
You can set current model by running "juju switch"
or specify any other model on the command line using the "-m" flag.

mbruzek@warhorse:~$ juju list-models
please enter password for mbruzek@local on container-lab:
ERROR cannot list models: invalid entity name or password
mbruzek@warhorse:~$ juju list-models
please enter password for mbruzek@local on container-lab:
ERROR cannot list models: invalid entity name or password
mbruzek@warhorse:~$ juju switch amazon
container-lab (controller) -> amazon:admin@local/controller

[Charles Butler (lazypower)]

Additonally, I am unable to view the user that appears to be "stuck" in my controller

$ juju show-user mbruzek
ERROR mbruzek: permission denied

$ juju show-user
user-name: admin
display-name: admin
access: superuser
date-created: 2016-09-29
last-connection: just now

$ juju show-user bcsaller
user-name: bcsaller
access: superuser
date-created: 2016-09-29
last-connection: 2016-09-29

[Alexis Bruemmer (alexis-bruemmer)]

Charles,

Is the environment still up? If so can you please grab the controller logs for us? If not can you provide details on how you created the environment that dropped the user.

[Charles Butler (lazypower)]

Alexis, the controller is still up, however, the controller is under active use.

Would those logs still be useful? There's going to be a bunch of data to sift through, or I can (maybe) share it with an engineer to reproduce/fetch the logs as required...

Let me know how you'd like to proceed and I can accommodate.

[Paul Gear (paulgear)]

Seems like this shouldn't be incomplete...

[Cory Johns (johnsca)]

This is partially duplicated in https://bugs.launchpad.net/juju/+bug/1630728 in which it has been asserted that the non-obvious behavior of remove-user is in fact intended

[Anastasia (anastasia-macmood)]

Marking as Won't Fix for Juju 2.0 as we are not planning another 2.0.x release.

[Horacio Durán (hduran-8)]

Is this bug still going on? I think this was caused by user having been delete which can not be reverted and that is intentional.

[Anastasia (anastasia-macmood)]

It does look like this experience is related mostly to our current management of deleted users. I am marking this as a duplicate of bug # 1630728 as the answer to that bug will resolve/avoid described scenario.