Difference between revisions of "Trove/DynamicExtensionLoading"
m |
|||
Line 4: | Line 4: | ||
What's proposed here to move to a more dynamic means to discover and load extensions using the stevedore package: http://stevedore.readthedocs.org/en/latest/index.html | What's proposed here to move to a more dynamic means to discover and load extensions using the stevedore package: http://stevedore.readthedocs.org/en/latest/index.html | ||
− | [1] https://github.com/openstack/trove/blob/master/trove/openstack/common/extensions.py#L35 | + | * [1] https://github.com/openstack/trove/blob/master/trove/openstack/common/extensions.py#L35 |
− | [2] https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L40 | + | * [2] https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L40 |
− | [3] https://github.com/openstack/trove/blob/master/trove/openstack/common/extensions.py#L407 | + | * [3] https://github.com/openstack/trove/blob/master/trove/openstack/common/extensions.py#L407 |
== Justification/Benefits == | == Justification/Benefits == | ||
− | + | A more dynamic / robust means to discover trove extensions will allow more accessible | |
− | |||
== Impacts == | == Impacts == |
Revision as of 17:22, 25 July 2014
Contents
Description
The current trove impl for loading API extensions is based on a single path which is specified in the trove conf file and then searched at trove-api start-up time to find and load extensions. While this approach is sufficient for loading trove proper extensions it becomes more painful for consumers who wish to package and / or consume trove extensions not shipped with trove proper. With the current approach, a consumer must copy his / her extension class (a concrete impl of trove.common.extensions.ExtensionDescriptor [1]) into the path specified by the api_extensions_path conf property[2] in trove.conf in order for it to be picked up the the trove-api extension loading [3]. The act of copying py files into another modules install path is a bad practice and this is not a very robust / flexible approach.
What's proposed here to move to a more dynamic means to discover and load extensions using the stevedore package: http://stevedore.readthedocs.org/en/latest/index.html
- [1] https://github.com/openstack/trove/blob/master/trove/openstack/common/extensions.py#L35
- [2] https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L40
- [3] https://github.com/openstack/trove/blob/master/trove/openstack/common/extensions.py#L407
Justification/Benefits
A more dynamic / robust means to discover trove extensions will allow more accessible
Impacts
Configuration
- Does this impact any configuration files? If so, which ones?
Database
- Does this impact any existing tables? If so, which ones?
- Are the changes forward and backward compatible?
- Be sure to include the expected migration process
Public API
- Does this change any API that an end-user has access to?
- Are there any exceptions in terms of consistency with other APIs?
CLI interface
- How the command will look like?
- Does it extends the already existed command interfaces ?
ReST Part
- Which HTTP methods added ?
- Which routes were added/modified/extended?
- How does the Request body look like?
- How does the Response object look like?
Internal API
- Does this change any internal messages between API and Task Manager or Task Manager to Guest
RPC API description
- Method name.
- Method parameters.
- Message type (cast/call).
Guest Agent
- Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?