Open Stack

Hi Denis

On 11/06/14 20:17, Denis Makogon wrote:
>
> 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).
>
>      o
>
>         create rules in group;
>
>      o
>
>         create group;
>
>      o
>
>         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
>
>
Have you investigated whether you can use stack-adopt to create a stack
from already existing NATIVES provisioned resources? This could allow
migration to ORCHESTRATOR in one hit, with potential to roll back to
NATIVES if there are any migration issues. This could be a lot simpler
than a mixed MIGRATION manager.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140612/98584046/attachment.html>