Keystone server does not define "enabled" attribute for Region but mentions in v3 regions.py
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Undecided
|
Vishakha Agarwal | ||
python-keystoneclient |
Fix Released
|
Undecided
|
Vishakha Agarwal |
Bug Description
The bug was discovered while writing the region functional tests [1]. The create() and update() calls [2] in regions.py mention the "enabled" attribute, but the specs [3] don't mention it and the code [4] doesn't support it. We don't check for "enabled" in the region schema either [5].
So, it's being stored as an extra attribute and it even works if one passes {'enabled': 'WHATEVER'}
[1] https:/
[2] https:/
[3] http://
[4] https:/
[5] https:/
summary: |
- Keystone server does not define "enabled" atribute for Region but + Keystone server does not define "enabled" attribute for Region but mentions in v3 regions.py |
affects: | python-keystoneclient → keystone |
tags: | added: office-hours |
Changed in keystone: | |
assignee: | nobody → Vishakha Agarwal (vishakha.agarwal) |
Changed in python-keystoneclient: | |
assignee: | nobody → Vishakha Agarwal (vishakha.agarwal) |
Changed in keystone: | |
status: | Confirmed → In Progress |
Changed in keystone: | |
status: | In Progress → Fix Released |
Changed in python-keystoneclient: | |
status: | In Progress → Fix Released |
Just adding some additional data. python- keystoneclient by default adds "enabled": True, but also accepts an enabled parameter on region create. The comment indicates that if "enabled" is False, the region will not be added to the catalog. Now for the kicker, since there is not an "enabled" attribute in the region schema, the "enabled" value gets added to the extra blob. And strangely, the extra blob is not update-able. The enabled trigger seems like it should either be removed altogether or in the schema so that it can be updated.