Editing User fails when the user already has a Primary Project

Bug #1161963 reported by Julie Pichon on 2013-03-29
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
High
Jan Provaznik
OpenStack Identity (keystone)
Medium
Dolph Mathews
Grizzly
Medium
Dolph Mathews

Bug Description

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) wrote :

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!

Changed in horizon:
status: New → Invalid
Julie Pichon (jpichon) wrote :

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.

Changed in horizon:
status: Invalid → New
Changed in horizon:
status: New → Confirmed
Changed in horizon:
importance: Undecided → Medium
importance: Medium → High
milestone: none → havana-1
Julie Pichon (jpichon) wrote :

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

Changed in horizon:
milestone: havana-1 → havana-2
Changed in horizon:
assignee: nobody → Jan Provaznik (jan-provaznik)
Dolph Mathews (dolph) wrote :

Looks like keystone's API is behaving as expected.

Changed in keystone:
status: New → Invalid
Kieran Spear (kspear) wrote :

@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?

Changed in keystone:
status: Invalid → Confirmed
Dolph Mathews (dolph) wrote :

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

Jan Provaznik (jan-provaznik) wrote :

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) wrote :

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.

tags: added: grizzly-backport-potential

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

Changed in keystone:
assignee: nobody → Dolph Mathews (dolph)
status: Confirmed → In Progress
Dolph Mathews (dolph) wrote :

@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?

Changed in keystone:
importance: Undecided → Medium
Dolph Mathews (dolph) wrote :

@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) wrote :

@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) wrote :

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?

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

Changed in keystone:
status: In Progress → Fix Committed
Kieran Spear (kspear) wrote :

@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.

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

Changed in horizon:
status: Confirmed → In Progress

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

Changed in horizon:
status: In Progress → Fix Committed

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

tags: added: in-stable-grizzly
Thierry Carrez (ttx) on 2013-07-17
Changed in horizon:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-07-17
Changed in keystone:
milestone: none → havana-2
status: Fix Committed → Fix Released
Alan Pevec (apevec) on 2013-08-05
tags: removed: grizzly-backport-potential in-stable-grizzly
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-2 → 2013.2
Thierry Carrez (ttx) on 2013-10-17
Changed in horizon:
milestone: havana-2 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers