This module provides support for dependency injection.
Providers are registered via the @provider() decorator, and dependencies on them are registered with @requires(). Providers are available to their consumers via an attribute. See the documentation for the individual functions for more detail.
See also:
Bases: exceptions.Exception
Raised when a required dependency is not resolvable.
See resolve_future_dependencies() for more details.
A class decorator used to register providers.
When @provider() is used to decorate a class, members of that class will register themselves as providers for the named dependency. As an example, In the code fragment:
@dependency.provider('foo_api')
class Foo:
def __init__(self):
...
...
foo = Foo()
The object foo will be registered as a provider for foo_api. No more than one such instance should be created; additional instances will replace the previous ones, possibly resulting in different instances being used by different consumers.
A class decorator used to inject providers into consumers.
The required providers will be made available to instances of the decorated class via an attribute with the same name as the provider. For example, in the code fragment:
@dependency.requires('foo_api', 'bar_api')
class FooBarClient:
def __init__(self):
...
...
client = FooBarClient()
The object client will have attributes named foo_api and bar_api, which are instances of the named providers.
Objects must not rely on the existence of these attributes until after resolve_future_dependencies() has been called; they may not exist beforehand.
Dependencies registered via @required() must have providers; if not, an UnresolvableDependencyException will be raised when resolve_future_dependencies() is called.
Reset the registry of providers.
This is useful for unit testing to ensure that tests don’t use providers from previous tests.
Force injection of all dependencies.
Before this function is called, circular dependencies may not have been injected. This function should be called only once, after all global providers are registered. If an object needs to be created after this call, it must not have circular dependencies.
If any required dependencies are unresolvable, this function will raise an UnresolvableDependencyException.
Outside of this module, this function should be called with no arguments; the optional argument, __provider_name is used internally, and should be treated as an implementation detail.
Bases: object
Encapsulate driver hints for listing entities.
Hints are modifiers that affect the return of entities from a list_<entities> operation. They are typically passed to a driver to give direction as to what filtering, pagination or list limiting actions are being requested.
It is optional for a driver to action some or all of the list hints, but any filters that it does satisfy must be marked as such by calling removing the filter from the list.
A Hint object contains filters, which is a list of dicts that can be accessed publicly. Also it contains a dict called limit, which will indicate the amount of data we want to limit our listing to.
If the filter is discovered to never match, then cannot_match can be set to indicate that there will not be any matches and the backend work can be short-circuited.
Each filter term consists of:
name: the name of the attribute being matched
value: the value against which it is being matched
contains, startswith or endswith
case
type: will always be ‘filter’
Add a filter to the filters list, which is publicly accessible.
Ensure list truncation is detected in Driver list entity methods.
This is designed to wrap Driver list_{entity} methods in order to calculate if the resultant list has been truncated. Provided a limit dict is found in the hints list, we increment the limit by one so as to ask the wrapped function for one more entity than the limit, and then once the list has been generated, we check to see if the original limit has been exceeded, in which case we truncate back to that limit and set the ‘truncated’ boolean to ‘true’ in the hints limit dict.
Register extension with collection of admin extensions.
Extensions register the information here that will show up in the /extensions page as a way to indicate that the extension is active.
Bases: object
Attempt to create the key directory if it doesn’t exist.
Create a key repository and bootstrap it with a key.
Parameters: |
|
---|
Load keys from disk into a list.
The first key in the list is the primary key used for encryption. All other keys are active secondary keys that can be used for decrypting tokens.
Create a new primary key and revoke excess active keys.
Parameters: |
|
---|
Key rotation utilizes the following behaviors:
This strategy allows you to safely perform rotation on one node in a cluster, before syncing the results of the rotation to all other nodes (during both key rotation and synchronization, all nodes must recognize all primary keys).
Bases: object
Relationships for Common parameters.
Bases: object
Status values supported.
Bases: object
Base class for intermediary request layer.
The Manager layer exists to support additional logic that applies to all or some of the methods exposed by a service that are not specific to the HTTP interface.
It also provides a stable entry point to dynamic backends.
An example of a probable use case is logging all the calls.
Helper function to deprecate the original driver classes.
The keystone.{subsystem}.Driver classes are deprecated in favor of the new versioned classes. This function creates a new class based on a versioned class and adds a deprecation message when it is used.
This will allow existing custom drivers to work when the Driver class is renamed to include a version.
Example usage:
Driver = create_legacy_driver(CatalogDriverV8)
Truncate the list returned by the wrapped function.
This is designed to wrap Manager list_{entity} methods to ensure that any list limits that are defined are passed to the driver layer. If a hints list is provided, the wrapper will insert the relevant limit into the hints so that the underlying driver call can try and honor it. If the driver does truncate the response, it will update the ‘truncated’ attribute in the ‘limit’ entry in the hints list, which enables the caller of this function to know if truncation has taken place. If, however, the driver layer is unable to perform truncation, the ‘limit’ entry is simply left in the hints list for the caller to handle.
A _get_list_limit() method is required to be present in the object class hierarchy, which returns the limit for this backend to which we will truncate.
If a hints list is not provided in the arguments of the wrapped call then any limits set in the config file are ignored. This allows internal use of such wrapped methods where the entire data set is needed as input for the calculations of some other API (e.g. get role assignments for a given project).
Setup OSprofiler notifier and enable profiling.
Parameters: |
|
---|