Open Stack

Good day, Trove community

 I'd like to start thread related to orchestration based resource
management. At current state Heat support in Trove is nothing else than
experimental. Trove should be able to fully support Trove as resource
management driver.


 *Why is it so important?*

 Because Trove should not do what it does now (cloud service orchestration
is not the part of the OS Database Program). Trove should delegate all
tasks to Cloud Orchestration Service (Heat).


*How can Heat help Trove?*

 Easily, Trove API allows to perform next resource operations:

   1.

   Trove instance provisioning (a combination of nova compute instance and
   cinder volume).
   2.

   Resize instances (compute instance flavor resize).
   3.

   Volume resize (cinder volume resize).
   4.

   Security groups management (nova-network, neutron).


   -

      create rules in group;
      -

      create group;
      -

      update rules CIDR;

 Heat allows to do almost all given tasks.


  *Resource management interface*

 What is management interface – abstract class that describes the required
tasks to accomplish. From Trove-taskmanager perspective, management
interface is nothing else than RPC service manager that being used at
service start [1]<https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L51-L52>
.


 *Why is it needed?*

 The first answer is: To split-out two completely different resource
management engines. Nova/Cinder/Neutron engine etc. called “*NATIVES*” and
Heat engine called “*ORCHESTRATOR*”.

As you can all know they cannot work together, because they are acting with
resources in their own manners. But both engines are sharing more than
enough common code inside the Trove.


*Is it backward compatible?*

 Here comes the third (mixed) manager called “*MIGRATION*”. It allows to
work with previously provisioned instances through *NATIVES *engine
(resizes, migration, deletion) but new instances which would be provisioned
in future will be provisioned withing stacks through *ORCHESTRATOR*.

 So, there are three valid options:

   -

   use *NATIVES* if there's no available Heat;
   -

   use *ORCHESTRATOR *to work with Heat only;
   -

   use *MIGRATION *to work with mixed manager;


    TODO list:

   -

   provide abstract manager interface;
   -

   extract common code shared between natives/heat/migration;
   -

   implement native management support;
   -

   implement orchestrator management support;
   -

   implement migration management support;
   -

   implement missing features in Heat;
   -

   re-visit orchestrator support;


There are already filed several blueprints which would give to Trove an
ability to fully support orchestrator based provisioning:

[TROVE SPACE]

https://blueprints.launchpad.net/trove/+spec/stack-id

https://blueprints.launchpad.net/trove/+spec/resource-manager-interface

https://blueprints.launchpad.net/trove/+spec/resize-volume

https://blueprints.launchpad.net/trove/+spec/resize-instance


 [HEAT SPACE]

https://blueprints.launchpad.net/heat/+spec/update-cinder-volume

https://blueprints.launchpad.net/heat/+spec/handle-update-for-security-groups
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140428/f79c6784/attachment-0001.html>