Open Stack

On 16/06/14 13:56, Nikhil Manchanda wrote:
>
> Denis Makogon writes:
>> 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.

I don't think anyone disagrees with you on this, although in the future 
Mistral might be helpful for some of the task running aspects (as we 
discussed at the design summit).

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

+1 for the stack adopt, this is an ideal use case for it IMO.

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

No, this remains an outstanding issue. There are, however, plans to 
address it:

https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint

cheers,
Zane.