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