9b25f3f8a5
* add common introduction and architecture information * create more appropriate structure for REST API docs Change-Id: I27b95aa76814f5d6bf6737c56594c7e5ba9d667c Partially implements: blueprint climate-docs
70 lines
3.1 KiB
ReStructuredText
70 lines
3.1 KiB
ReStructuredText
Climate architecture
|
||
====================
|
||
|
||
Climate design can be described by following diagram:
|
||
|
||
.. image:: images/climate-architecture.png
|
||
:width: 700 px
|
||
:scale: 99 %
|
||
:align: left
|
||
|
||
**climate-client** - provides the opportunity to communicate with Climate via
|
||
*REST API* (climate-api service).
|
||
|
||
**climate-api** - waits for the REST calls from the outside world to redirect
|
||
them to the manager. climate-api communicates with climate-manager via RPC.
|
||
Runs as a separated process.
|
||
|
||
**climate-manager** - implements all logic and operations with leases,
|
||
reservations and events. Communicates with Climate DB and stores there data
|
||
structure of connected leases, reservations (both physical and virtual) and
|
||
events. climate-manager service is responsible for running events created for
|
||
lease and process all actions that should be done this moment. Manager uses
|
||
resource-plugins to work with concrete resources (instances, volumes, compute
|
||
hosts). climate-manager uses Keystone trusts to commit actions on behalf of
|
||
user who has created lease before.
|
||
|
||
**resource-plugin** - responsible for exact actions to do with reserved
|
||
resources (VMs, volumes, etc.) When working knows only about resource ID and
|
||
token to use. All resource plugins work in the same process as climate-manager.
|
||
|
||
Virtual instance reservation
|
||
----------------------------
|
||
|
||
Virtual instance reservation mostly looks like usual instance booting for user
|
||
- he/she only passes special hints to Nova containing information about future
|
||
lease - lease start and end dates, its name, etc. Special Nova API extensions
|
||
parse these parameter and use them to call Climate, passing to it ID of just
|
||
created instance. If there is a need to reserve all instances in cloud (like in
|
||
developer labs to automate process of resource reclaiming), default reservation
|
||
extension might be used. By default it starts lease at the moment of request
|
||
and gives it one month of lifetime.
|
||
|
||
During the time lease has not started yet, instance will be shelved.
|
||
|
||
Compute host reservation
|
||
------------------------
|
||
|
||
Now process of compute hosts reserving contains two steps:
|
||
|
||
* admin marks hosts from common pool as possible to be reserved. That is
|
||
implemented by moving these hosts to special aggregate;
|
||
* user asks for reserving of host with specified characteristics like:
|
||
|
||
* the region
|
||
* the availability zone
|
||
* the host capabilities extra specs (scoped and non-scoped format is
|
||
accepted)
|
||
* the number of CPU cores
|
||
* the amount of free RAM
|
||
* the amount of free disk space
|
||
* the number of hosts
|
||
|
||
Technically speaking, resource ID here will be not host ID, because there might
|
||
be many of them wanted. Resource here will be new aggregate containing reserved
|
||
hosts. The time lease starts, user may use reserved compute capacity to run
|
||
his/her instances on it passing special scheduler hint to Nova. When host is
|
||
reserved, it’s not used for usual instance running, it might be used only when
|
||
lease starts and only by passing reservation ID to Nova. That is implemented
|
||
using special Nova Scheduler filter, that passes reservation ID to Climate and
|
||
checks if user really can use reserved compute capacity. |