Editing User fails when the user already has a Primary Project

[Julie Pichon]

As an admin, if I want to edit the details for a user who already has a Primary Project associated, the form submission fails with "Error: There was an error submitting the form. Please try again. "

DEBUG:requests.packages.urllib3.connectionpool:"PUT /v2.0/users/9c058a211a0b4ceb938d0cd764f22f6b/OS-KSADM/tenant HTTP/1.1" 409 240
DEBUG:keystoneclient.client:Request returned failure status: 409
ERROR:django.request:Internal Server Error: /admin/users/9c058a211a0b4ceb938d0cd764f22f6b/update/
Traceback (most recent call last):
  File "/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/keystone.py", line 221, in user_update_tenant
     tenant_id)
   File "/opt/stack/python-keystoneclient/keystoneclient/v2_0/users.py", line 96, in update_tenant
     params, "user")
   File "/opt/stack/python-keystoneclient/keystoneclient/base.py", line 104, in _update
     management=management)
   File "/opt/stack/python-keystoneclient/keystoneclient/client.py", line 417, in put
     return self._cs_request(url, 'PUT', **kwargs)
  File "/opt/stack/python-keystoneclient/keystoneclient/client.py", line 404, in _cs_request
     **kwargs)
   File "/opt/stack/python-keystoneclient/keystoneclient/client.py", line 366, in request
     raise exceptions.from_response(resp, resp.text)
ClientException: Unable to communicate with identity service: {"error": {"message": "Conflict occurred attempting to store role grant. User 9c058a211a0b4ceb938d0cd764f22f6b already has role 9fe2ff9ee4384b1894a90878d3e92bab in tenant 4783617525c349b28413bc32cf2d5cc4", "code": 409, "title": "Conflict"}}. (HTTP 409)

Steps to reproduce:
1. As an admin, go to Admin -> Users and Edit the demo user
2. Change the demo's email. It's not possible to submit the form without a primary project so select "demo"
3. Try to edit the demo user again to revert your change. "demo" will be preselected as a Primary project. Submit the form.
4. A message "Error: There was an error submitting the form. Please try again. " is displayed. The email change actually took place.

This appears to be a regression, as I can't reproduce the problem in a Folsom devstack. The code around this hasn't changed in Horizon though, as far as I can tell.

[Julie Pichon (jpichon)]

Ah... My bad, I forgot to update my devstack settings with a better HORIZON_CONFIG variable.

The error is somewhat nicer in that case. There's both a success message and "Error: Unable to update (<django.utils.functional.__proxy__ object at 0x7f6a818d7790>,) for the user". I'll open a new bug for the translation issue, sorry for the noise!

[Julie Pichon (jpichon)]

Reopening this -- although the error is caught and displayed, we probably shouldn't force the user to select a Primary Project if setting it (multiple times) is going to cause an error.

[Julie Pichon (jpichon)]

This is only a problem when using Keystone v2.0.

[Dolph Mathews (dolph)]

Looks like keystone's API is behaving as expected.

[Kieran Spear (kspear)]

@dolph: I think something more is going on here. With v2.0 I get a 409 every time if the user is already a member of the project, even if they have never had a default project before.

User.update_user_project() seems very naive:

https://github.com/openstack/keystone/blob/71c6a4b88279ddf9047595fb4c1ffbce4062621d/keystone/identity/controllers.py#L247

Shouldn't this be checking whether the user is already on the project?

[Dolph Mathews (dolph)]

Hmm, looks like you're probably right-- definitely worth investigating

[Jan Provaznik (jan-provaznik)]

There is a different behavior for v2.0 and v3 on Horizon side:
with v2.0: horizon calls keystone's update_user_project method which both adds the user to a project and updates the user settings
with v3: horizon updates the user only -> after changing user's prject, we have to add the user on prject's user management page explicitly

Temporary workaround for the Keystone's issue pointed out by @kspear could be 2 separate calls: update_user (which updates user's tenantId attr), then add this user to primary project (if he is not added yet).

On Horizon side we should add a call which adds user to project after update for v3:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/keystone.py#L325

[Dolph Mathews (dolph)]

That's an intentional difference. The goal is to allow users to revise their own default project as a preference, while on v2 it was treated as an administrative operation and resulted in a change in authorization.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/31559

[Dolph Mathews (dolph)]

@Kieran: I was able to reproduce a 409 with v2.0 (see tests in https://review.openstack.org/31559 ) when attempting to update the user to the pre-existing default project. However, the fact that the test was running in it's previous state was covering the "even if they have never had a default project before." Is there some other contributing factor to reproducing the issue as you described?

[Dolph Mathews (dolph)]

@Kieran: Refactored my tests after patchset 1, so the above is in reference to the original test_user_create_update_delete in https://review.openstack.org/#/c/31559/1/tests/test_keystoneclient.py

[Kieran Spear (kspear)]

@Dolph: Thanks, your fix looks good. I removed the tenantId from the DB manually when testing, but I was thinking of a case like:

Create user with no tenantId specified
Add user to tenant x
Set user's default tenant to tenant x

The root cause is the same though, so your existing test covers it.

[Jan Provaznik (jan-provaznik)]

On Horizon side do we want to add the user to the selected primary project as a member (if she is not member yet) as described in comment #7?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/31707

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/31559
Committed: http://github.com/openstack/keystone/commit/2ff3ddd356d599677bfc2a1ad08009b2226357eb
Submitter: Jenkins
Branch: master

commit 2ff3ddd356d599677bfc2a1ad08009b2226357eb
Author: Dolph Mathews <email address hidden>
Date: Mon Jun 3 15:30:10 2013 -0500

    Ignore conflict on v2 auto role assignment (bug 1161963)

    Change-Id: I10581a39325b4fcdb997ad704c3ee0de494b32e0

[Kieran Spear (kspear)]

@Jan: I think the v2 way of doing things is somewhat dangerous, since you can accidentally select the wrong project as default, and it's not obvious that they get added to the project when you do so. Would be interested to hear other's thoughts, but personally I'd rather we only list the current projects for the edited user in the dropdown.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/32454

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/32454
Committed: http://github.com/openstack/horizon/commit/c123e2abb48b8e72b279258d272d661a5146ebb8
Submitter: Jenkins
Branch: master

commit c123e2abb48b8e72b279258d272d661a5146ebb8
Author: Jan Provaznik <email address hidden>
Date: Mon Jun 10 17:46:08 2013 +0200

    List only projects accessible by user

    When setting user's primary project, display only projects accessible
    by user being updated.

    Fixes bug 1161963

    Change-Id: Ib83f3a1ee83b8d0441267254582824a3fe07b4e3

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/31707
Committed: http://github.com/openstack/keystone/commit/e44685113a7e6cd7a77d0647c85eab2689938435
Submitter: Jenkins
Branch: stable/grizzly

commit e44685113a7e6cd7a77d0647c85eab2689938435
Author: Dolph Mathews <email address hidden>
Date: Mon Jun 3 15:30:10 2013 -0500

    Ignore conflict on v2 auto role assignment (bug 1161963)

    Change-Id: I10581a39325b4fcdb997ad704c3ee0de494b32e0