Jump to: navigation, search

Blazar/Use Cases

< Blazar
Revision as of 21:06, 5 June 2014 by Pafuent (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Blazar Use Cases

This page describes what use cases where we thinking about while Blazar implementation. As said, Blazar was created to provide time-based resource management.

Implemented Blazar Use Cases

VM Reservation

First idea for VM reservation was the following. Let's imagine big company with dev cloud. There is wish to automate process of VM management in time - like having all VMs running from now during 30 days. VM reservation allows to remove unused VMs without keeping them running - user will have VM only for a time, wanted by this user.

VM reservation might be used with some billing service to sell compute capacity.

User wants to have working VM for 5 days from tomorrow. He also wants to it to be snapshoted and then deleted after the end of lease. This use case contains the following steps:

  • User goes to Nova and asks server to be created, passing special lease-related hints
  • Specially written Nova API extension shelves VM and sends info about it to Blazar
  • Blazar creates lease and reservation with just created VM ID as resource ID
  • Blazar creates start and end events for this lease
  • When lease starts, Blazar unshelves VM
  • When lease ends, Blazar creates snapshot and deletes VM


  • Currently OS does not support complex quota management (like setting time period for quota), that leads to inability to separate “create lease” and “resource allocation” steps.
  • The previous point leads to inability of resource reusage (like user1 wants VM right now for one day, user2 wants VM tomorrow for one day too. Technically they should use same CPU/RAM/etc. resources for their usage, but to manage this situation we should use time-defined quotas for each of them)


  • Implement quotas with start/end dates. Probably here we should remember about discussed on last summit idea of centralised quota management - so each service will know only current quota, while Keystone (as a place where this centralised management will be implemented) will send notifications to services about changed quota.

Compute Host Reservation

This use case came from HPC jobs idea running on OS clouds.

User wants to have whole hosts compute capacity to run his/her instances on them. To provide whole hosts to user, there should not be any other VMs running on them. Currently that is managed by keeping special pool of hosts (defined by admin) that might be reserved. Technically these hosts are the part of one aggregate.

  • User goes to Blazar and asks for some number of hosts with specified characteristics
  • Hosts are moved to special aggregate (lease-specific)
  • When lease is started, user may pass reservation hint to Nova and that will filter Nova hosts leaving only belonging to this reservation
  • When lease ends, hosts are moved back to common reservable pool


  • Aggregates are now used to implement hosts reservation, but that requires special wrappers in Blazar, that, that should be implemented in Nova


  • Go back to Phil Day proposal of pclouds in the current their view, and use them after it’ll be implemented. That BP was abandoned, and Phil is concentration on dedicated instances instead of it, but still.

Future use cases

User notifications (in progress)

We’re implementing now user notifications about close lease start/end and other possible events. That will allow user to prolong leases, if he/she needs these resources more time.

Volume Reservation

Volume reservation means reservation of block storage space, that might be given to VM. As this space is not endless, its time management is also needed. Volume reservation is needed to run reserved VMs with block storages attached to them.

Possible solution #1:

  • Have some kind of special ‘reserved’ state for volume in Cinder (that will mean no real volume created), and have opportunity to finish creation request time lease actually allocates resources for reservation.


  • Many moments to change in Cinder code, although that should be investigated.

Possible solution #2:

  • Consider volumes dedicated to Blazar - like store info about them, manage scheduling process, etc.


  • That should not be managed in Blazar. That’s Cinder thing to manage volumes states, scheduling, etc.

Heat Stacks Reservation

Heat stacks might be reserved to provide user not separated VMs and volumes, but already working and connected components like VMs with attached volumes and associated floating IPs.

Possible solution: TBD

Storage Host Reservation

Close to compute hosts reservation, and problems are almost the same.