
immutable
lockdown
A bug in the test design have hidden the issue with options of the domain. It is possible to set immutable to true during creation or update of the domain, but it is impossible to change it back through API. Reason is the check that refuses update operation when there are more then 1 updated props with immutable switched on. For projects it is no problem to send 1 update but for domain we pull additional base props (is_domain=true, domain_id=none, parent_id=none) in the get_project_from_domain method. And since the test for unsetting immutable started with immutable already unset (in difference to similar test for the project) it was never identified. - discard default props of the domain to keep the length check happy - ensure test for unsetting immutable starts with immutable domain Change-Id: I03ba754875050fdb93219e915fc099680679b6c4
OpenStack Keystone
OpenStack Keystone provides authentication, authorization and service discovery mechanisms via HTTP primarily for use by projects in the OpenStack family. It is most commonly deployed as an HTTP interface to existing identity systems, such as LDAP.
Developer documentation, the source of which is in
doc/source/
, is published at:
The API reference and documentation are available at:
The canonical client library is available at:
Documentation for cloud administrators is available at:
The source of documentation for cloud administrators is available at:
Information about our team meeting is available at:
Release notes is available at:
Bugs and feature requests are tracked on Launchpad at:
Future design work is tracked at:
Contributors are encouraged to join IRC
(#openstack-keystone
on OFTC):
Source for the project:
For information on contributing to Keystone, see
CONTRIBUTING.rst
.