Jump to: navigation, search

Difference between revisions of "Trove/DynamicExtensionLoading"

(Created page with "== 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...")
 
Line 1: Line 1:
 
== Description ==
 
== 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) into the path specified by the api_extensions_path conf property in trove.conf in order for it to be picked up the the trove-api extension loading. The act of copying py files into another modules install path is a bad practice and this is not a very robust / flexible approach.
+
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
 
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 ==
 
== Justification/Benefits ==

Revision as of 17:08, 25 July 2014

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

  • What is the driving force behind this change?
  • Does it allow for great flexibility? Stability? Security?

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?