Jump to: navigation, search

Difference between revisions of "Blazar/Use Cases"

m (Sergey Lukjanov moved page Climate/Use Cases to Blazar/Use Cases: Climate project has been renamed to the Blazar project due to the possible trademark issues.)
Line 1: Line 1:
== Climate Use Cases ==
+
== Blazar Use Cases ==
  
This page describes what use cases where we thinking about while Climate implementation. As said, Climate was created to provide time-based resource management.
+
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 Climate Use Cases ===
+
=== Implemented Blazar Use Cases ===
  
 
==== VM Reservation ====
 
==== VM Reservation ====
Line 14: Line 14:
  
 
* User goes to Nova and asks server to be created, passing special lease-related hints
 
* 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 Climate
+
* Specially written Nova API extension shelves VM and sends info about it to Blazar
* Climate creates lease and reservation with just created VM ID as resource ID
+
* Blazar creates lease and reservation with just created VM ID as resource ID
* Climate creates start and end events for this lease
+
* Blazar creates start and end events for this lease
* When lease starts, Climate unshelves VM
+
* When lease starts, Blazar unshelves VM
* When lease ends, Climate creates snapshot and deletes VM
+
* When lease ends, Blazar creates snapshot and deletes VM
  
  
Line 37: Line 37:
 
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 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 Climate and asks for some number of hosts with specified characteristics
+
* User goes to Blazar and asks for some number of hosts with specified characteristics
 
* Hosts are moved to special aggregate (lease-specific)
 
* 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 is started, user may pass reservation hint to Nova and that will filter Nova hosts leaving only belonging to this reservation
Line 45: Line 45:
 
'''Problems''':
 
'''Problems''':
  
* Aggregates are now used to implement hosts reservation, but that requires special wrappers in Climate, that, that should be implemented in Nova
+
* Aggregates are now used to implement hosts reservation, but that requires special wrappers in Blazar, that, that should be implemented in Nova
  
  
Line 74: Line 74:
 
'''Possible solution #2''':
 
'''Possible solution #2''':
  
* Consider volumes dedicated to Climate - like store info about them, manage scheduling process, etc.
+
* Consider volumes dedicated to Blazar - like store info about them, manage scheduling process, etc.
  
  
 
'''Problems''':
 
'''Problems''':
  
* That should not be managed in Climate. That’s Cinder thing to manage volumes states, scheduling, etc.
+
* That should not be managed in Blazar. That’s Cinder thing to manage volumes states, scheduling, etc.
  
 
==== Heat Stacks Reservation ====
 
==== Heat Stacks Reservation ====

Revision as of 21:06, 5 June 2014

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


Problems:

  • 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)


Solution:

  • 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


Problems:

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


Solution:

  • 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.


Problems:

  • 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.


Problems:

  • 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.