Difference between revisions of "Trove/ResourceManagerInterface"
(→Impacts) |
(→How taskmanager works) |
||
(47 intermediate revisions by the same user not shown) | |||
Line 10: | Line 10: | ||
# DNS records. | # DNS records. | ||
− | === Heat and Nova/Cinder/Designate implementation of the Resource manager === | + | === Heat and Nova/Cinder/Designate/Neutron 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: | Heat and Nova/Cinder/Designate implementation of the Resource manager will cover all methods that are presented in Trove now, such as: | ||
# Provisioning. | # Provisioning. | ||
Line 21: | Line 21: | ||
=== Justification === | === Justification === | ||
− | Heat allows to work with almost all types of the resources that Trove requires, but Trove does | + | :Heat allows to work with almost all types of the resources that Trove requires, but Trove does all orchestration over each service expecting to receive/obtain the actual resource from nova/cinder/neutron/designate. Since Heat is a Cloud Orchestration Service, Trove should not do orchestration work over multiple services. It should work with a single service and have only one dependency instead of multiple(one per each service). |
− | === Benefits of Resource manager interface === | + | === 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 nova/cinder/designate). | + | |
+ | # 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 == | == Scope == | ||
Heat should be able to accomplish all tasks required by Trove. | Heat should be able to accomplish all tasks required by Trove. | ||
− | |||
== Impacts == | == Impacts == | ||
Line 36: | Line 39: | ||
: If setuping fresh new Trove - use orchestrator manager. | : If setuping fresh new Trove - use orchestrator manager. | ||
=== Configuration === | === Configuration === | ||
− | This configuration parameters are related to | + | ==== New ==== |
+ | :This configuration parameters are related to trove-taskmanager | ||
+ | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Parameter name !! Config value !! Resource managers mapping | ! Parameter name !! Config value !! Resource managers mapping | ||
|- | |- | ||
− | | resource_manager || ''orchestrator'' | + | | resource_manager || ''orchestrator'' / ''native'' / ''migration'' || |
− | + | "orchestrator": "trove.taskmanager.resources.orchestrator.Orchestrator" | |
− | + | "native": "trove.taskmanager.resources.native.Native" | |
− | + | "migration": "trove.taskamanger.resources.migration.Migration" | |
− | |||
− | |||
|} | |} | ||
+ | |||
+ | :''Native manager'' - integrated with native services, makes taskmanager act like a orchestration service. | ||
+ | :''Orchestration manager ''- integrated with cloud orchestration service, less orchestration logic required, all tasks are delegated to cloud orchestration service. | ||
+ | :''Migration manager'' - combinition of the native and orchestration maanger, works as router - execution task choise depends on how Trove instance was provisioned (native or orchestrator). Route rule based upon new base instance model attribute - provisioning_engine. | ||
+ | |||
+ | ==== Particular Qualities ==== | ||
+ | |||
+ | :With migration driver each new Trove instance is provisioned by cloud orchestration service. | ||
+ | |||
+ | :Tasks like: resize flavor/volume and delete were implemented as actual routers with specific rule. Routing based upon how resource was provisioned. | ||
+ | |||
+ | :Tasks that envolve direct guest interations like: create backup, restart, update_overrides, unassign_configuration - are common to each resource manager. | ||
+ | |||
+ | :Reboot task. For orchestrator - stack signal. For natives - simple reboot call for server. | ||
+ | |||
+ | ==== Deprecated ==== | ||
+ | : ''taskmanager_manager'' - ''resource_manager'' used instead. | ||
+ | : ''use_heat'' - not required any more. | ||
=== Database === | === Database === | ||
Line 57: | Line 78: | ||
|- | |- | ||
| provisioning_engine || String || Base instance mode (DBInstance model) | | provisioning_engine || String || Base instance mode (DBInstance model) | ||
+ | |- | ||
+ | | stack_id || String || Base instance mode (DBInstance model) | ||
|} | |} | ||
Line 73: | Line 96: | ||
== Resource manager under the hood == | == Resource manager under the hood == | ||
− | Resource manager interface is nothing else than class with required | + | Resource manager interface is nothing else than class with required methods, each of them raises OperationIsNotSupported exception. |
+ | Each resource manager implements required tasks from Resource manager interface, such as: provisioning, resizing(instance/volume), security groups management. | ||
+ | |||
+ | === Why? === | ||
+ | Because cloud orchestrator is ready to cover all required cases. | ||
=== Way to implement it === | === Way to implement it === | ||
− | Among all services (api, tm, conductor, guestagent) the most suitable please to refactor code is | + | Among all services (api, tm, conductor, guestagent) the most suitable please to refactor code is a Trove taskmanager service. |
+ | |||
==== How taskmanager works ==== | ==== How taskmanager works ==== | ||
− | Taskmanager works upon manager class that presented inside the configuration file. | + | Taskmanager works upon manager class that presented inside the configuration file. Default value : |
− | : '' | + | : ''resource_manager'' is set as '''''trove.taskmanager.resources.natives.Natives''''' |
+ | Links: | ||
+ | |||
https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L33 | https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L33 | ||
+ | |||
https://github.com/openstack-dev/devstack/blob/master/lib/trove#L166 | https://github.com/openstack-dev/devstack/blob/master/lib/trove#L166 | ||
− | + | Current taskmanager manager is the mixing of the orechestration and native resource management. It should be splitted into the three resource management drivers, one for nova/cinder/neutron/designate and another one for heat service, and migration for the combinition of the proposed managers to accomplish successful management with previosly provisioned instances. From the first implementation heat branch will be the experimental branch that requires setup CI job. | |
+ | |||
+ | === Trove use cases=== | ||
+ | ==== Covered by Heat ==== | ||
+ | # Rollbacks on failed stack updating. | ||
+ | # Resize instance with confirmation task. | ||
+ | # Provisioning task. | ||
+ | # Delete task. | ||
+ | # Nova-network security group/rules management with Outputs. | ||
+ | # Neutron security group/rules management with Outputs. | ||
+ | # Resize volume. |
Latest revision as of 08:59, 16 June 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:
- Instances(instance groups).
- Volumes (cinder or ephemeral).
- Network attributes (SGs, floating IPs, NICS).
- DNS records.
Heat and Nova/Cinder/Designate/Neutron 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:
- Provisioning.
- Resizing instances (flavor).
- Resizing volumes.
- DNS records management.
- Security group/rules management
Justification/Benefits
Justification
- Heat allows to work with almost all types of the resources that Trove requires, but Trove does all orchestration over each service expecting to receive/obtain the actual resource from nova/cinder/neutron/designate. Since Heat is a Cloud Orchestration Service, Trove should not do orchestration work over multiple services. 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
New
- This configuration parameters are related to trove-taskmanager
Parameter name | Config value | Resource managers mapping |
---|---|---|
resource_manager | orchestrator / native / migration |
"orchestrator": "trove.taskmanager.resources.orchestrator.Orchestrator" "native": "trove.taskmanager.resources.native.Native" "migration": "trove.taskamanger.resources.migration.Migration" |
- Native manager - integrated with native services, makes taskmanager act like a orchestration service.
- Orchestration manager - integrated with cloud orchestration service, less orchestration logic required, all tasks are delegated to cloud orchestration service.
- Migration manager - combinition of the native and orchestration maanger, works as router - execution task choise depends on how Trove instance was provisioned (native or orchestrator). Route rule based upon new base instance model attribute - provisioning_engine.
Particular Qualities
- With migration driver each new Trove instance is provisioned by cloud orchestration service.
- Tasks like: resize flavor/volume and delete were implemented as actual routers with specific rule. Routing based upon how resource was provisioned.
- Tasks that envolve direct guest interations like: create backup, restart, update_overrides, unassign_configuration - are common to each resource manager.
- Reboot task. For orchestrator - stack signal. For natives - simple reboot call for server.
Deprecated
- taskmanager_manager - resource_manager used instead.
- use_heat - not required any more.
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) |
stack_id | 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 methods, each of them raises OperationIsNotSupported exception. Each resource manager implements required tasks from Resource manager interface, such as: provisioning, resizing(instance/volume), security groups management.
Why?
Because cloud orchestrator is ready to cover all required cases.
Way to implement it
Among all services (api, tm, conductor, guestagent) the most suitable please to refactor code is a Trove taskmanager service.
How taskmanager works
Taskmanager works upon manager class that presented inside the configuration file. Default value :
- resource_manager is set as trove.taskmanager.resources.natives.Natives
Links:
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 orechestration and native resource management. It should be splitted into the three resource management drivers, one for nova/cinder/neutron/designate and another one for heat service, and migration for the combinition of the proposed managers to accomplish successful management with previosly provisioned instances. From the first implementation heat branch will be the experimental branch that requires setup CI job.
Trove use cases
Covered by Heat
- Rollbacks on failed stack updating.
- Resize instance with confirmation task.
- Provisioning task.
- Delete task.
- Nova-network security group/rules management with Outputs.
- Neutron security group/rules management with Outputs.
- Resize volume.