Resource-reservation-service

• Launchpad Entry: TBD
• Created: 31 July 2013
• Contributors: Dina Belova, Nikolay Starodubtsev, Dmitry Novakovskiy

Introduction

The idea of building dedicated Resource Reservation Service emerged from discussions about Lifecycle Management capabilities in scope of one of our private cloud projects.

With these capabilities in place User can request the resources of cloud environment to be provided (“leased”) to his/her Project/Tenant for specific amount on time, immediately or in future. Upon “lease” expiration Resource Reservation Service will reclaim resources and return them to common pool according to configured workflow. Both virtual (Instances, Volumes, Networks) and hardware (full hosts with specific characteristics of RAM, CPU and etc) resources can be allocated via “lease”.

In terms of benefits added, Resource Reservation Service will:

• improve visibility of cloud resources consumption (current and planned for future);
• enable cloud resource planning based on current and future demand from end users;
• automate the processes of resource allocation and reclaiming

The complete vision for this project is described in our Project proposal. We encourage everyone who's interested in such functionality to take a look on it and let us know your comments.

Service Architecture

climate-client

Provides the opportunity to communicate with Climate via REST API. Really, communicates with climate-api process.

climate-api

Waits for the calls from the outside world to redirect them to the manager. Will use different controllers for different Climate resource types (now there will be only one resource to work with from the outside world - lease). Controllers use RPC API to work with climate-manager. Runs as a separated process.

climate-manager

Implements all operations with leases - create, update, get and delete them. Communicates with Climate DB and creates there a structure of connected leases, reservations (virtual and physical) and events. Responsible for running events created for some time (information about events is stored in DB). Uses resorce plugins to run actions by lease start and lease end events. Runs in separated process with all resource plugins. Knows about Keystone trusts and gets real tokens to use for resource plugins.

resource-plugin

Responsible for exact actions to do with reserved resources (VMs, volumes, etc.) When working knows only about resorce ID and token to use. All resource plugins work in the same process as climate-manager.

REST API

Here you can take look at our REST API proposal.