Bases: keystone.cmd.cli.BasePermissionsSetup
Provides common options for certificate setup.
Bases: keystone.cmd.cli.BaseApp
Common user/group setup for file permissions.
Bases: keystone.cmd.cli.BaseApp
Perform the basic bootstrap process
Perform the bootstrap actions.
Create bootstrap user, project, and role so that CMS, humans, or scripts can continue to perform initial setup (domains, projects, services, endpoints, etc) of Keystone when standing up a new deployment.
Bases: keystone.cmd.cli.BaseApp
Sync the database.
Bases: keystone.cmd.cli.BaseApp
Print the current migration version of the database.
Bases: keystone.cmd.cli.BaseApp
Upload the domain specific configuration files to the database.
Bases: object
Read configs from file(s) and load into database.
The command line parameters have already been parsed and the CONF command option will have been set. It is either set to the name of an explicit domain, or it’s None to indicate that we want all domain config files.
Upload a single config file to the database.
Parameters: |
|
---|---|
Raises: |
|
The caller of this method should catch the errors raised and handle appropriately in order that the best UX experience can be provided for both the case of when a user has asked for a specific config file to be uploaded, as well as all config files in a directory.
Upload configs from file and load into database.
This method will be called repeatedly for all the config files in the config directory. To provide a better UX, we differentiate the error handling in this case (versus when the user has asked for a single config file to be uploaded).
Validate the options, returning True if they are indeed valid.
It would be nice to use the argparse automated checking for this validation, but the only way I can see doing that is to make the default (i.e. if no optional parameters are specified) to upload all configuration files - and that sounds too dangerous as a default. So we use it in a slightly unconventional way, where all parameters are optional, but you must specify at least one.
Bases: keystone.cmd.cli.BasePermissionsSetup
Rotate Fernet encryption keys.
This assumes you have already run keystone-manage fernet_setup.
A new primary key is placed into rotation, which is used for new tokens. The old primary key is demoted to secondary, which can then still be used for validating tokens. Excess secondary keys (beyond [fernet_tokens] max_active_keys) are revoked. Revoked keys are permanently deleted. A new staged key will be created and used to validate tokens. The next time key rotation takes place, the staged key will be put into rotation as the primary key.
Rotating keys too frequently, or with [fernet_tokens] max_active_keys set too low, will cause tokens to become invalid prior to their expiration.
Bases: keystone.cmd.cli.BasePermissionsSetup
Setup a key repository for Fernet tokens.
This also creates a primary key used for both creating and validating Fernet tokens. To improve security, you should rotate your keys (using keystone-manage fernet_rotate, for example).
Bases: keystone.cmd.cli.BaseApp
Execute mapping engine locally.
Bases: keystone.cmd.cli.BaseApp
Purge the mapping table.
Bases: keystone.cmd.cli.BaseCertificateSetup
Set up Key pairs and certificates for token signing and verification.
This is NOT intended for production use, see Keystone Configuration documentation for details. As of the Mitaka release, this command has been DEPRECATED and may be removed in the ‘O’ release.
Bases: keystone.cmd.cli.BaseCertificateSetup
Create key pairs and certificates for HTTPS connections.
This is NOT intended for production use, see Keystone Configuration documentation for details.
Bases: keystone.cmd.cli.BaseApp
Generate Identity Provider metadata.
Bases: keystone.cmd.cli.BaseApp
Flush expired tokens from the backend.