Open Stack

Good day, Stackers, 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:

   -

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

   Resize instances (compute instance flavor resize).
   -

   Volume resize (cinder volume resize).
   -

   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].

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

Trove

   -

   provide abstract manager interface;
   -

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

   implement native management support;
   -

   implement orchestrator management support;
   -

   implement migration management support;

 Heat


   -

   implement instance resize; Done
   <https://github.com/openstack/heat/blob/master/heat/engine/resources/instance.py#L564-L648>
   -

   implement volume resize; Done
   <https://github.com/openstack/heat/commit/34e215c3c930b3b79bc3795dca3b5a73678f2a36>


Testing environment

In terms of this topic i’d like to propose two new experimental gates for
Trove:

   -

   gate-trove-heat-integration (integration testing)
   -

   gate-trove-heat-integration-faked (testing based upon fake
   implementation of heat).

 Fro the first iteration would gate-trove-heat-integration would be
proposed and used.

Review process

For the next BP review meeting (Trove) i will revisit this BP since all
required tasks were done.

For the bug-reports, i’d like to ask Trove-core team to take a look at
them. And review/approve/merge them as soon as possible to start working on
Heat integration.

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

[TROVE BP SPACE]

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

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

[TROVE BUG-REPORT SPACE]

https://bugs.launchpad.net/trove/+bug/1276228

https://bugs.launchpad.net/trove/+bug/1325512

https://bugs.launchpad.net/trove/+bug/1328464


Best regards,
Denis Makogon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/e5ededd6/attachment.html>