Jump to: navigation, search

Difference between revisions of "Trove"

(reddwarf-guestagent)
Line 1: Line 1:
  
 
= Description =
 
= Description =
Reddwarf is Database as a Service for Openstack.  It's designed to run entirely on [[OpenStack]], with the goal of allowing users to quickly and easily utilize the features of a relational database without the burden of handling complex administrative tasks.  Cloud users and database administrators can provision and manage multiple database instances as needed. Initially, the service will focus on providing resource isolation at high performance while automating complex administrative tasks including deployment, configuration, patching, backups, restores, and monitoring.
+
Trove is Database as a Service for Openstack.  It's designed to run entirely on [[OpenStack]], with the goal of allowing users to quickly and easily utilize the features of a relational database without the burden of handling complex administrative tasks.  Cloud users and database administrators can provision and manage multiple database instances as needed. Initially, the service will focus on providing resource isolation at high performance while automating complex administrative tasks including deployment, configuration, patching, backups, restores, and monitoring.
  
 
= Design =
 
= Design =
Reddwarf is designed to support a single-tenant database within a Nova instance.  There will be no restrictions on how Nova is configured, since Reddwarf interacts with other [[OpenStack]] components purely through the API.
+
Trove is designed to support a single-tenant database within a Nova instance.  There will be no restrictions on how Nova is configured, since Trove interacts with other [[OpenStack]] components purely through the API.
  
== reddwarf-api ==
+
== trove-api ==
The '''reddwarf-api''' service provides a RESTful API that supports JSON and XML to provision and manage Reddwarf instances.  
+
The '''trove-api''' service provides a RESTful API that supports JSON and XML to provision and manage Trove instances.  
 
* A REST-ful component
 
* A REST-ful component
* Entry point - Reddwarf/bin/reddwarf-api
+
* Entry point - Trove/bin/trove-api
* Uses a WSGI launcher configured by Reddwarf/etc/reddwarf/api-paste.ini
+
* Uses a WSGI launcher configured by Trove/etc/trove/api-paste.ini
 
** Defines the pipeline of filters; tokenauth, ratelimit, etc.
 
** Defines the pipeline of filters; tokenauth, ratelimit, etc.
** Defines the app_factory for the reddwarfapp as reddwarf.common.api:app_factory
+
** Defines the app_factory for the troveapp as trove.common.api:app_factory
 
* The API class (a wsgi Router) wires the REST paths to the appropriate Controllers
 
* The API class (a wsgi Router) wires the REST paths to the appropriate Controllers
 
** Implementation of the Controllers are under the relevant module (versions/instance/flavor/limits), in the service.py module
 
** Implementation of the Controllers are under the relevant module (versions/instance/flavor/limits), in the service.py module
Line 18: Line 18:
 
* At this point, an api module of another component (TaskManager, GuestAgent, etc.) is used to send the request onwards through RabbitMQ
 
* At this point, an api module of another component (TaskManager, GuestAgent, etc.) is used to send the request onwards through RabbitMQ
  
== reddwarf-taskmanager ==
+
== trove-taskmanager ==
The '''reddwarf-taskmanager''' service does the heavy lifting as far as provisioning instances, managing the lifecycle of instances, and performing operations on the Database instance.
+
The '''trove-taskmanager''' service does the heavy lifting as far as provisioning instances, managing the lifecycle of instances, and performing operations on the Database instance.
 
* A service that listens on a RabbitMQ topic
 
* A service that listens on a RabbitMQ topic
* Entry point - Reddwarf/bin/reddwarf-taskmanager
+
* Entry point - Trove/bin/trove-taskmanager
* Runs as a RpcService configured by Reddwarf/etc/reddwarf/reddwarf-taskmanager.conf.sample which defines reddwarf.taskmanager.manager.Manager as the manager - basically this is the entry point for requests arriving through the queue
+
* Runs as a RpcService configured by Trove/etc/trove/trove-taskmanager.conf.sample which defines trove.taskmanager.manager.Manager as the manager - basically this is the entry point for requests arriving through the queue
 
* As described above, requests for this component are pushed to MQ from another component using the TaskManager's api module using _cast() or _call() (sync/a-sync) and putting the method's name as a parameter
 
* As described above, requests for this component are pushed to MQ from another component using the TaskManager's api module using _cast() or _call() (sync/a-sync) and putting the method's name as a parameter
* Reddwarf/openstack/common/rpc/dispatcher.py- RpcDispatcher.dispatch() invokes the proper method in the Manager by some equivalent to reflection
+
* Trove/openstack/common/rpc/dispatcher.py- RpcDispatcher.dispatch() invokes the proper method in the Manager by some equivalent to reflection
 
* The Manager then redirect the handling to an object from the models.py module. It loads an object from the relevant class with the context  and instance_id
 
* The Manager then redirect the handling to an object from the models.py module. It loads an object from the relevant class with the context  and instance_id
 
* Actual handling is usually done in the models.py module
 
* Actual handling is usually done in the models.py module
  
== reddwarf-guestagent ==
+
== trove-guestagent ==
 
The '''guestagent''' is a service that runs within the guest instance, responsible for managing and performing operations on the Database itself.  The Guest Agent listens for RPC messages through the message bus and performs the requested operation.
 
The '''guestagent''' is a service that runs within the guest instance, responsible for managing and performing operations on the Database itself.  The Guest Agent listens for RPC messages through the message bus and performs the requested operation.
 
* Similar to TaskManager in the sense of running as a service that listens on a RabbitMQ topic
 
* Similar to TaskManager in the sense of running as a service that listens on a RabbitMQ topic
 
* GuestAgent runs on every DB instance, and a dedicated MQ topic is used (identified as the instance's id)
 
* GuestAgent runs on every DB instance, and a dedicated MQ topic is used (identified as the instance's id)
* Entry point - Reddwarf/bin/reddwarf-guestagent
+
* Entry point - Trove/bin/trove-guestagent
* Runs as a RpcService configured by Reddwarf/etc/reddwarf/reddwarf-guestagent.conf.sample which defines reddwarf.guestagent.manager.Manager as the manager - basically this is the entry point for requests arriving through the queue
+
* Runs as a RpcService configured by Trove/etc/trove/trove-guestagent.conf.sample which defines trove.guestagent.manager.Manager as the manager - basically this is the entry point for requests arriving through the queue
 
* As described above, requests for this component are pushed to MQ from another component using the GuestAgent's api module using _cast() or _call() (sync/a-sync) and putting the method's name as a parameter
 
* As described above, requests for this component are pushed to MQ from another component using the GuestAgent's api module using _cast() or _call() (sync/a-sync) and putting the method's name as a parameter
* Reddwarf/openstack/common/rpc/dispatcher.py- RpcDispatcher.dispatch() invokes the proper method in the Manager by some equivalent to reflection
+
* Trove/openstack/common/rpc/dispatcher.py- RpcDispatcher.dispatch() invokes the proper method in the Manager by some equivalent to reflection
 
* The Manager then redirect the handling to an object (usually) from the dbaas.py module.
 
* The Manager then redirect the handling to an object (usually) from the dbaas.py module.
 
* Actual handling is usually done in the dbaas.py module
 
* Actual handling is usually done in the dbaas.py module
Line 45: Line 45:
  
 
= Installation and Deployment =
 
= Installation and Deployment =
* How to install reddwarf as part of devstack: [[reddwarf-installation]]
+
* How to install trove as part of devstack: [[trove-installation]]
* How to set up a testing environment and run redstack tests after installation: [[reddwarf-redstack-testing]]
+
* How to set up a testing environment and run redstack tests after installation: [[trove-redstack-testing]]
* How to set up your Mac dev environment to debug: [[reddwarf-dev-env]]
+
* How to set up your Mac dev environment to debug: [[trove-dev-env]]
* Releasing python-reddwarfclient [[release-python-reddwarfclient]]
+
* Releasing python-troveclient [[release-python-troveclient]]
  
 
= Development =
 
= Development =
* Quota Management is currently in development: [[reddwarf-quotas]]
+
* Quota Management is currently in development: [[trove-quotas]]
* Security Groups is currently in design/development: [[reddwarf-security-groups]]
+
* Security Groups is currently in design/development: [[trove-security-groups]]
 
* Snapshot Design: [[snapshot-design]]
 
* Snapshot Design: [[snapshot-design]]
* Versions and Types Design: [[Reddwarf-versions-types]]
+
* Versions and Types Design: [[Trove-versions-types]]
 
* Configuration Edits: [[https://wiki.openstack.org/wiki/DatabaseAsAService/configurationediting]]
 
* Configuration Edits: [[https://wiki.openstack.org/wiki/DatabaseAsAService/configurationediting]]
* Notification Events: [[reddwarf-notifications]]
+
* Notification Events: [[trove-notifications]]
* Diagrams: [[Reddwarf-Diagrams]]
+
* Diagrams: [[Trove-Diagrams]]

Revision as of 20:50, 2 July 2013

Description

Trove is Database as a Service for Openstack. It's designed to run entirely on OpenStack, with the goal of allowing users to quickly and easily utilize the features of a relational database without the burden of handling complex administrative tasks. Cloud users and database administrators can provision and manage multiple database instances as needed. Initially, the service will focus on providing resource isolation at high performance while automating complex administrative tasks including deployment, configuration, patching, backups, restores, and monitoring.

Design

Trove is designed to support a single-tenant database within a Nova instance. There will be no restrictions on how Nova is configured, since Trove interacts with other OpenStack components purely through the API.

trove-api

The trove-api service provides a RESTful API that supports JSON and XML to provision and manage Trove instances.

  • A REST-ful component
  • Entry point - Trove/bin/trove-api
  • Uses a WSGI launcher configured by Trove/etc/trove/api-paste.ini
    • Defines the pipeline of filters; tokenauth, ratelimit, etc.
    • Defines the app_factory for the troveapp as trove.common.api:app_factory
  • The API class (a wsgi Router) wires the REST paths to the appropriate Controllers
    • Implementation of the Controllers are under the relevant module (versions/instance/flavor/limits), in the service.py module
  • Controllers usually redirect implementation to a class in the models.py module
  • At this point, an api module of another component (TaskManager, GuestAgent, etc.) is used to send the request onwards through RabbitMQ

trove-taskmanager

The trove-taskmanager service does the heavy lifting as far as provisioning instances, managing the lifecycle of instances, and performing operations on the Database instance.

  • A service that listens on a RabbitMQ topic
  • Entry point - Trove/bin/trove-taskmanager
  • Runs as a RpcService configured by Trove/etc/trove/trove-taskmanager.conf.sample which defines trove.taskmanager.manager.Manager as the manager - basically this is the entry point for requests arriving through the queue
  • As described above, requests for this component are pushed to MQ from another component using the TaskManager's api module using _cast() or _call() (sync/a-sync) and putting the method's name as a parameter
  • Trove/openstack/common/rpc/dispatcher.py- RpcDispatcher.dispatch() invokes the proper method in the Manager by some equivalent to reflection
  • The Manager then redirect the handling to an object from the models.py module. It loads an object from the relevant class with the context and instance_id
  • Actual handling is usually done in the models.py module

trove-guestagent

The guestagent is a service that runs within the guest instance, responsible for managing and performing operations on the Database itself. The Guest Agent listens for RPC messages through the message bus and performs the requested operation.

  • Similar to TaskManager in the sense of running as a service that listens on a RabbitMQ topic
  • GuestAgent runs on every DB instance, and a dedicated MQ topic is used (identified as the instance's id)
  • Entry point - Trove/bin/trove-guestagent
  • Runs as a RpcService configured by Trove/etc/trove/trove-guestagent.conf.sample which defines trove.guestagent.manager.Manager as the manager - basically this is the entry point for requests arriving through the queue
  • As described above, requests for this component are pushed to MQ from another component using the GuestAgent's api module using _cast() or _call() (sync/a-sync) and putting the method's name as a parameter
  • Trove/openstack/common/rpc/dispatcher.py- RpcDispatcher.dispatch() invokes the proper method in the Manager by some equivalent to reflection
  • The Manager then redirect the handling to an object (usually) from the dbaas.py module.
  • Actual handling is usually done in the dbaas.py module

Source Code Repositories

Installation and Deployment

Development