This changes enables the Keystone v3 api. It can be toggled on and off via the
preferred-api-version option.
When services join the identity-service relation they will be presented with a
new parameter api_version which is the maximum api version the keystone charm
supports and matches what was set via preferred-api-version.
If preferred-api-version is set to 3 then the charm will render a new
policy.json which adds support for domains etc when keystone is checking
authorisation. The new policy.json requires an admin domain to be created and
specifies that a user is classed as an admin of the whole cloud if they have
the admin role against that admin domain.
The admin domain, called admin_domain, is created by the charm. The name of
this domain is currently not user configurable. The role that enables a user to
be classed as an admin is specified by the old charm option admin-role. The
charm grants admin-role to the admin-user against the admin_domain.
Switching a deployed cloud from preferred-api-version 2 to
preferred-api-version 3 is supported. Switching from preferred-api-version 3 to
preferred-api-version 2 should work from the charm point of view but may cause
problems if there are duplicate users between domains or may have unintended
consequences like escalating the privilege of some users so is not recommended.
Change-Id: I8eec2a90e0acbf56ee72cb5036a0a21f4a77a2c3
Implemented new is_paused() and assess_status() functions, and changed
the pause and resume actions to use them. Changed existing and added new
tests to verify functionality.
CloudKitty (Rating-as-a-Service for OpenStack) requires the creation of a
service in keystone to properly work. This patch registers cloukitty as a valid
service to enable the relation between those two charms.
MidoNet needs its low-level API to have access to the admin token.
Thus, it needs to be considered a valid service. This patch adds it
to the list of valid services so that the identity-service relation
can be completed successfully and with the admin_token.