Heat/Reservation

Summary
We would like to introduce the Heat stacks Reservation support for the OpenStack Reservation service - Climate. Climate aims to provide resource reservation to the OpenStack based clouds and for the virtual reservations, and one of the parts of integration Climate with other OpenStack services is to implement stack reservation feature. This moment is very special, because Heat stacks are complex resources that means Heat should support reserving VMs, volumes, etc.

This blueprint proposes implementation of managing reserved resources from Heat to give user opportunity of reserving not just separated VMs, volumes, floating IPs, but whole working ecosystem.

Climate team is now working on implementing solid, atomic virtual resources reservation (like reserving Nova VM). This would be done by creating new status in the service DB for the resource to be reserved and by adding new hints to the booting VM API call. This way VM object will be really created in Nova DB, it will be provisioned, but not really started. Nova will call Climate to create lease with the parameters passed by user (like time for lease to start, notification policies, etc.) and ID of the just created (but not actually booted) instance.

Reserving of stacks means studying Heat to operate with reserved resources in other OpenStack services.

Rationale
Opportunity of reserving virtual resources enables cloud resource planning (based on current and future demand from end users), automates processes of resource allocation and reclaiming and improves visibility of cloud resources consumption. Although this feature is useful, it's not enough to reserve separated instances, block storages and network resources. To make this opportunity useful from end users we need to provide possibility of reserving connected resource pools - stacks.

Design
The following moment should be implemented in Heat (they are quit high level): 1) reservation of atomic resources for the needs of stack (using hints/extensions that will implemented in Nova, Cinder, … by the time of implementing this BP) 2) configuration of actions that should be done with atomic resources by the moment lease actually starts and ends (probably these actions should be set in Heat templates) 3) communication with Climate itself like creating lease with needed parameters

Open Issues
It's now unclear what should be done in the case user wants to update reserved stack, cause it's not only adding/removing of some atomic resources from stack, but also rescheduling of them. This question occurs not only in the case lease is not started (and stack is not waked up), but also if stack is already running. In last case we have no opportunity to guarantee there will be enough resources to run more VMs, for example, because all scheduling work will be done much time before.