Open Stack

Denis Makogon writes:

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

I assume you mean that Trove should be support Heat as a way to
provision resources. I do agree with this sentiment, and Trove
today does have two ways of provisioning instances (i.e. with or without
Heat, depending on configuration).

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

Agreed that Trove should delegate provisioning, and orchestration tasks
to Heat. Tasks like taking backups, configuring an instance, promoting
it to master, etc are database specific tasks, and I'm not convinced
that Heat is the route to take for them.


> [...]
>
> 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 a separate RPC interface needed for this? It would be prudent,
imho, to keep the same TaskManager RPC API, since that's works as a
generic API across both Heat and Natives (nova, cinder, etc) and because
that's what's being deployed in production today. Changing it would mean
figuring out what to do about backwards compatibility, and I'm not sure
that changing it would actually buy us anything.


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

So this was something that was discussed in one of our meetings. There's
nothing today that prevents orchestrating the creation tasks via heat,
and later querying a native API for read-only information (for
eg. query nova to check the flavor of a provisioned instance). In this
case, Heat is being used for orchestration, but we're still working with
native API calls where it makes sense. So is there a real need or
requirement to move away from this model?

>
> 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;

This does seem a bit overly complex. Steve mentioned the idea of stack
adopt (Thanks!), and I think that would be quite a bit simpler. I think
it behooves us to investigate that as a mechanism for creating a stack
from existing resources, rather than having something like a mixed
migration manager that has been proposed.


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

IIRC we did have an open issue and were trying to work with heat devs to
expose a callback to trove in the case of the VERIFY_RESIZE during
instance resize. Is that now done?


>
> Testing environment
>
> In terms of this topic i’d like to propose two new experimental gates for
> Trove:
>
>    -
>
>    gate-trove-heat-integration (integration testing)
>    -

This should probably be a higher priority. I'd be more inclined to get
the gate testing all scenarios of the current heat workflow that we
already have in trove today (configuration based), rather than work on a
resource management interface. We really need to make sure our QA and
test coverage around the heat scenarios is better than what we have
today. This would probably be my highest priority over any of the other
work mentioned above.

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

We don't need a separate gate job for this, and the current tox unit
test gate would suffice. We could re-run the fake tests with the heat
configuration enabled as part of the same unit test job.

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

IIRC we already talked about these blueprints at the BP meeting already
(April 21, and 28).
http://eavesdrop.openstack.org/meetings/trove_bp_review/2014/trove_bp_review.2014-04-28-18.02.log.html#l-173

At that time, the team did identify this as something that we didn't
want to imminently tackle for a few reasons:

- The BP didn't sufficiently detail what the resource manager API
  actually was. Without this it was hard to make a call on what the
  actual changes were and what effect this would have on backwards
  compatibility.

- The BP didn't sufficiently detail migration scenarios -- it didn't
  cover anything about existing instances that had already been
  provisioned by natives that need to be moved to heat.

- We still needed to do some work to tie up loose ends in heat to make
  sure it worked for all our scenarios (including verify-resize mentioned
  above).

- The BP didn't call out how we would handle testing for this.

If any of this has changed, feel free to bring it up at the BP meeting
again, but please make sure that these specific points have been
addressed.

Thanks for taking the time to write this up!
Nikhil