Difference between revisions of "Blueprint-nova-planned-resource-reservation-api"
JulienDanjou (talk | contribs) (→Design) |
(→Summary) |
||
| Line 3: | Line 3: | ||
== Summary == | == Summary == | ||
| − | |||
| − | + | This blueprint introduces the concept of a Capacity Leasing Service in OpenStack along the side of Nova. | |
| − | + | ||
| − | + | == Typical Usage Scenario == | |
| − | + | ||
| − | + | In its most basic form, the service should provide the ability to create an aggregate of physical nodes for a given time period and to the exclusive use of project. We will call that particular kind of aggregate a lease. Once the lease is granted by the service, nobody, but the users of a project, should be allowed to create instances in that lease. | |
| + | |||
| + | In the request, the user specifies the properties of the lease: | ||
| + | |||
| + | # the required hosts capabilities, | ||
| + | # the minimum number of nodes, | ||
| + | # a no-latter-than starting date | ||
| + | # a duration in number of hours or days | ||
| + | |||
| + | In return, the service displays a list of lease handles (sorted in chronological order) containing a schedule proposals (starting date and time), and other optional (provider's specific?) parameters. | ||
| + | |||
| + | The user can then create, and so activate the lease, using one of the lease handles he obtained from the previous step. | ||
| + | |||
| + | Once the lease has ended, nothing disruptive happens to the active instances excepted that the reserved nodes return to the shared pool and so become available to other projects. | ||
| + | |||
| + | A lease is potentially a billable item and so should be logged through Ceilometer accordingly. Similarly, instances created out of an active lease should be logged as well to allow for differentiated pricing policies. | ||
| + | |||
| + | == More Advanced Usage Scenarios == | ||
| + | |||
| + | More advanced usage scenarios will be enabled through the use of plug-able modules to backend systems that will affect the content of the lease handles returned by the service. Beyond reserving capacity, the expected benefits of the Capacity Leasing Service is to foster energy efficiency (greener?) behaviors through promoting nodes with the lowest MFLOPS/Watt ratio, or save electricity by automatically turning machines on and off based on the leasing schedule. In addition, the service should help operators with the management of their physical assets in a more effective way thanks to the enablement of capacity planing and automated fulfillment processes based again on the leasing schedule. | ||
| + | |||
| + | Last but not least. The Capacity Leasing Service is also expected to address a class of performance needs and types of workload that are typical of the high performance computing world, whereby applications require to be executed on dedicated nodes of similar hardware specifications and speed (CPU arch and model, clock frequency, GPU, ...) | ||
== Design == | == Design == | ||
Revision as of 17:39, 27 February 2013
- Created: Julien Danjou
- Contributors: Julien Danjou, Patrick Petit, François Rossigneux
Summary
This blueprint introduces the concept of a Capacity Leasing Service in OpenStack along the side of Nova.
Typical Usage Scenario
In its most basic form, the service should provide the ability to create an aggregate of physical nodes for a given time period and to the exclusive use of project. We will call that particular kind of aggregate a lease. Once the lease is granted by the service, nobody, but the users of a project, should be allowed to create instances in that lease.
In the request, the user specifies the properties of the lease:
- the required hosts capabilities,
- the minimum number of nodes,
- a no-latter-than starting date
- a duration in number of hours or days
In return, the service displays a list of lease handles (sorted in chronological order) containing a schedule proposals (starting date and time), and other optional (provider's specific?) parameters.
The user can then create, and so activate the lease, using one of the lease handles he obtained from the previous step.
Once the lease has ended, nothing disruptive happens to the active instances excepted that the reserved nodes return to the shared pool and so become available to other projects.
A lease is potentially a billable item and so should be logged through Ceilometer accordingly. Similarly, instances created out of an active lease should be logged as well to allow for differentiated pricing policies.
More Advanced Usage Scenarios
More advanced usage scenarios will be enabled through the use of plug-able modules to backend systems that will affect the content of the lease handles returned by the service. Beyond reserving capacity, the expected benefits of the Capacity Leasing Service is to foster energy efficiency (greener?) behaviors through promoting nodes with the lowest MFLOPS/Watt ratio, or save electricity by automatically turning machines on and off based on the leasing schedule. In addition, the service should help operators with the management of their physical assets in a more effective way thanks to the enablement of capacity planing and automated fulfillment processes based again on the leasing schedule.
Last but not least. The Capacity Leasing Service is also expected to address a class of performance needs and types of workload that are typical of the high performance computing world, whereby applications require to be executed on dedicated nodes of similar hardware specifications and speed (CPU arch and model, clock frequency, GPU, ...)
Design
A reservation, or lease, is tight to a project. It has a start and an end timestamp, during which the lease is valid. It also has a number of nodes and their flavors associated with, so it can be quantified. A lease has a set of scheduler hints set that are immutable. An API call allows a user to retrieve the list and combination of applicable hints. When a user tries to creates a lease, the list of scheduler hints is checked for validity: an operator can refuse a lease with invalid or too strict hints.
When an instance is created, it's registered as being part of the lease when the user passes the information at creation time. It's taken from the lease when it's destroyed. If an instance is created as being part of a lease, the scheduler has to launch the instance with the requirements fulfilled.
