Good day, 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: 1. Trove instance provisioning (a combination of nova compute instance and cinder volume). 2. Resize instances (compute instance flavor resize). 3. Volume resize (cinder volume resize). 4. Security groups management (nova-network, neutron). - create rules in group; - create group; - 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]<https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L51-L52> . *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: - provide abstract manager interface; - extract common code shared between natives/heat/migration; - implement native management support; - implement orchestrator management support; - implement migration management support; - implement missing features in Heat; - re-visit orchestrator support; There are already filed several blueprints which would give to Trove an ability to fully support orchestrator based provisioning: [TROVE SPACE] https://blueprints.launchpad.net/trove/+spec/stack-id https://blueprints.launchpad.net/trove/+spec/resource-manager-interface https://blueprints.launchpad.net/trove/+spec/resize-volume https://blueprints.launchpad.net/trove/+spec/resize-instance [HEAT SPACE] https://blueprints.launchpad.net/heat/+spec/update-cinder-volume https://blueprints.launchpad.net/heat/+spec/handle-update-for-security-groups
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev