Trove/ConfigurableDBPlugins

Description

From a vendor / consumer perspective, there are likely cases where consumers want to leverage the existing trove sqlachemy DB models and framework abstractions for their own extensions / features within the trove framework. For example a consumer may want to develop custom in-house (proprietary) add-ons which use persistence for trove which either they do not wish to contribute upstream, or they want to build out a PoC in-house before upstreaming. In such cases a more rapid time to value and lower risk investment can be achieved by leveraging the existing trove db framework and having the ability to plug-in their own schema / migration / etc..

The current trove sqlalchemy implementation contains the plumbing and support necessary to allow consumers to "plug-in" their own database mappers which in turn can

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?