Jump to: navigation, search

Difference between revisions of "Trove/ResourceManagerInterface"

(Justification/Benefits)
(Benefits of Resource manager interface)
Line 26: Line 26:
  
 
: The restriction that is being described by the resource manager will make developers to follow provided specification while implementing resource managers (heat or natives).
 
: The restriction that is being described by the resource manager will make developers to follow provided specification while implementing resource managers (heat or natives).
: Reduced number of the dependecies (heatclient against nova/cinder/neutron/designate).
+
: Reducing orchestration logic, delegating all possible tasks to Heat Orchestration Service. As the result - reduced number of the dependecies (heatclient against nova/cinder/neutron/designate).
 +
: Single point of failure.
 +
: Recovery procedures are delegated to Heat (Template update: allow rollback).
  
 
== Scope ==  
 
== Scope ==  

Revision as of 20:35, 26 April 2014

Description

This feature makes three change to the behavior of Trove.

Nova/Cinder/Neutron/Designate aka Natives

Simple interface for the implementation of the resource managements, such as:

  1. Instances(instance groups).
  2. Volumes (cinder or ephemeral).
  3. Network attributes (SGs, floating IPs, NICS).
  4. DNS records.

Heat and Nova/Cinder/Designate implementation of the Resource manager

Heat and Nova/Cinder/Designate implementation of the Resource manager will cover all methods that are presented in Trove now, such as:

  1. Provisioning.
  2. Resizing instances (flavor).
  3. Resizing volumes.
  4. DNS records management.
  5. Security group/rules management

Justification/Benefits

Justification

Heat allows to work with almost all types of the resources that Trove requires, but Trove does it all orchestration over each service expecting to receive the actual resource from nova/cinder/neutron/designate. Since Heat is a cloud orchestration service, Trove should not do orchestration work over multiple serviced. It should work with a single service and have only one dependency instead of multiple(one per each service).

Benefits of Resource manager interface

The restriction that is being described by the resource manager will make developers to follow provided specification while implementing resource managers (heat or natives).
Reducing orchestration logic, delegating all possible tasks to Heat Orchestration Service. As the result - reduced number of the dependecies (heatclient against nova/cinder/neutron/designate).
Single point of failure.
Recovery procedures are delegated to Heat (Template update: allow rollback).

Scope

Heat should be able to accomplish all tasks required by Trove.


Impacts

From a user’s perspective this feature doesn't change any of the expectations and behavior. From deployer perspective:

If updating already running deployed Trove then you would need to use migration manager.
If setuping fresh new Trove - use orchestrator manager.

Configuration

This configuration parameters are related to trove-api and trove-taskmanager

Parameter name Config value Resource managers mapping
resource_manager orchestrator or native and migration
  { 
       "orchestrator": "trove.taskmanager.orchestrator.Orchestrator", 
       "native": "trove.taskmanager.native.Native" 
       "migration": "trove.taskamanger.migration.Migration" 
  }

Database

There are no expected changes to the database

Column name Attribute type Which model is being extended
provisioning_engine String Base instance mode (DBInstance model)

Public API

No changes

Internal API

No changes

Guest Agent

No changes

Resource manager under the hood

Resource manager interface is nothing else than class with required abstract methods.

Way to implement it

Among all services (api, tm, conductor, guestagent) the most suitable please to refactor code is the taskmanager.

How taskmanager works

Taskmanager works upon manager class that presented inside the configuration file.

taskmanager_manager is set as trove.taskmanager.manager.Manager

https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L33 https://github.com/openstack-dev/devstack/blob/master/lib/trove#L166

Current taskmanager manager is the mixing of the orechestrator and native client use. It should be splitted into the two different bruches, two resource management drivers, one for nova/cinder/neutron/designate and another one for _only_ heat. Since now all resources are managed according USE_TROVE flag it would be easy to do this. From the first implementation heat branch will be the experimental branch that requires CI job.