Users not migrated with model migration

[Tom Haddon]

I recently migrated a model from one controller to another on the same cloud by following the instructions on https://docs.jujucharms.com/2.4/en/models-migrate. The source controller (and model) were on 2.4.7 and the target controller was on 2.5-rc1.

The migration itself worked fine, but we manage the model from a separate environment from where the controller is managed from, and use different users for each model. This user was not migrated across as part of this migration. I confirmed this by running "juju users" on the target controller after the migration.

I worked around this by manually recreating the user on the target controller and then updating the management environment to point to the new model and use the newly created user.

[Richard Harding (rharding)]

Unfortunately as different controllers could have differnet user backends/etc it's not in the scope to deal with the user/permission side during model migrations. There's just no promises that we can keep there. It's expected behavior that if you migrate as different users that you'd have to reset up any access for users that are valid on the new home controller for a model after migration.

[Tom Haddon (mthaddon)]

I'm not sure I agree it's expected behaviour. It certainly wasn't for me. I was migrating using the admin account in each case, but expected the user that had permissions to the model I was migrating to be migrated as part of the model migration. I understand that might not be possible in all cases, but could it not be attempted and warn in case of failure? Or at least be an option to migrate the user with the model, or even to migrate the user as a separate action (where migrating the model would suggest there's a user that had permissions to the model we were migrating from doesn't exist on the target controller)?

[Roger Peppe (rogpeppe)]

> Unfortunately as different controllers could have differnet user backends/etc it's not in the scope to deal with the user/permission side during model migrations.

I agree that it's not reasonable to migrate local users from controller to controller, but external users are a different matter, I think. Assuming both controllers are using the same identity manager, I think it should be perfectly feasible (and desirable) to transfer external users when a model is migrated. It could be an optional flag on the migrate call, I suppose, if some people prefer the current behaviour.

[Tim Penhey (thumper)]

I'm fairly sure that the model users are transferred with the model, so two controllers that use the same identity manager and the model access is controlled with the external users, all should be fine.

If it is just local users, the new controller needs to be set up with the same users as the old controller. This isn't something we do automatically as the risk of giving the wrong person access inadvertantly was considered too high when the target controller already had some users defined.

[James Troup (elmo)]

Tim Penhey <email address hidden> writes:

> If it is just local users, the new controller needs to be set up with
> the same users as the old controller. This isn't something we do
> automatically as the risk of giving the wrong person access
> inadvertantly was considered too high when the target controller already
> had some users defined.

If it can't be done automatically that's fine, but the current
behaviour is dangerously misleading.

Acceptable behaviour:

 1) both user(s) and model are successfully migrated
 2) model is migrated, user(s) are not and the operator is warned that
    this the case
 3) user(s) can not be migrated and so the model is not migrated and
    the operator is told this with an option (--force-mumble) to
    override

Unacceptable behaviour:

 1) what we do now

--
James

[Tim Penhey (thumper)]

On 11/01/19 3:07 PM, James Troup wrote:
> If it can't be done automatically that's fine, but the current
> behaviour is dangerously misleading.
>
> Acceptable behaviour:
>
> 1) both user(s) and model are successfully migrated
> 2) model is migrated, user(s) are not and the operator is warned that
> this the case
> 3) user(s) can not be migrated and so the model is not migrated and
> the operator is told this with an option (--force-mumble) to
> override
>
> Unacceptable behaviour:
>
> 1) what we do now

My preference would be for the migration to output a list of any local
users that have access to the model that aren't defined in the target
controller. Which is part of option 2.

Perhaps we should also have a warning if there are external users that
have access and the external auth url (or whatever it is) is different.

[Tim Penhey (thumper)]

Additional 2.5 milestone will be set as the work is picked up.

[Richard Harding (rharding)]

This is actually released as part of Juju 2.6.

[Anastasia (anastasia-macmood)]

2.6.7 release never went out. This fix was instead released in 2.6.8 - re-targeting this report.