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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
