TenantName is set as TenantId in Instance and Glance Images Tables
Bug #870351 reported by
Antony Messerli
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Identity (keystone) |
Fix Released
|
Undecided
|
Kevin L. Mitchell | ||
Bug Description
If I provision an instance using TenantName, the project_id of the instance is set as TenantId. This should remain as TenantName.
For instance my TenantName is 'os-project' and the ID of it is 1 in Keystone. This should still utilize TenantName in Instances and Images tables or at least have a setting to use one of the other.
Revision history for this message
| Kevin L. Mitchell (klmitch) wrote | #1 |
Revision history for this message
| Openstack Gerrit (openstack-gerrit) wrote A change has been merged to openstack/keystone | #2 |
| Changed in keystone: | |
| status: | New → Fix Committed |
| tags: | added: diablo-backport |
Revision history for this message
| Openstack Gerrit (openstack-gerrit) wrote Fix merged to keystone (stable/diablo) | #3 |
| Changed in keystone: | |
| milestone: | none → essex-1 |
| Changed in keystone: | |
| assignee: | nobody → Kevin L. Mitchell (klmitch) |
| Changed in keystone: | |
| status: | Fix Committed → Fix Released |
| Changed in keystone: | |
| milestone: | essex-1 → 2012.1 |
To post a comment you must log in.
I talked with Ziad, and the basic idea here is that tenant names are potentially mutable, while tenant IDs are immutable. I then talked with Ant, who pointed out that, given that keystone has absolutely no database migration capability, it's hard to keep IDs lined up.
My approach to fixing this, in the short term, is to restore the behavior that X_TENANT reports the tenant name; however, I also added X_TENANT_ID to report the tenant name, and the relevant shim layers can figure out what the heck they want to do with it. Ultimately, long term, the IDs are what need to be stored, while the names should be used for presentation purposes, but Keystone really needs database migrations...