Jump to: navigation, search

Difference between revisions of "DisableCellSupport"

(Created page with "== Use case == * It will be very useful if the admin user could disable a child cell when the child cell needs to be maintained. == Implementation == * Add “disabled” fi...")
 
(Use case)
Line 1: Line 1:
 
== Use case ==
 
== Use case ==
  
* It will be very useful if the admin user could disable a child cell when the child cell needs to be maintained.
+
* It will be very useful if the admin user could disable a child cell when the child cell needs to be maintained. Typically there would be 4 states: active, draining, read-only and inactive
 +
: * Active would be the usual state.
 +
: * Draining would respond to queries, migrations and deletes but refuse new schedule requests.
 +
: * Read-only would only permit queries.
 +
: * Inactive would not respond.
 +
* Depending on the intervention, all of these could be useful. user story for draining is where the hardware in a cell is to be re-used and you want to move the workload off but not schedule new VMs. read-only would where, for example, you are doing a database migration and don't want new entries during that migration. inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behaviour.
  
 
== Implementation ==
 
== Implementation ==

Revision as of 08:56, 20 November 2013

Use case

  • It will be very useful if the admin user could disable a child cell when the child cell needs to be maintained. Typically there would be 4 states: active, draining, read-only and inactive
* Active would be the usual state.
* Draining would respond to queries, migrations and deletes but refuse new schedule requests.
* Read-only would only permit queries.
* Inactive would not respond.
  • Depending on the intervention, all of these could be useful. user story for draining is where the hardware in a cell is to be re-used and you want to move the workload off but not schedule new VMs. read-only would where, for example, you are doing a database migration and don't want new entries during that migration. inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behaviour.

Implementation

  • Add “disabled” field to cells table, check this field when scheduling instance to child cells, and block the cell state reports when the child cell is *disabled*.

API Spec

  • Disable cell
PUT v3/{tenant_id}/os-cells/disable
Response Codes 200
Request parameters
{
“cell”: {
“id”: “123”,
“status”: “disabled”
}
}
  • Enable cell
PUT v3/{tenant_id}/os-cells/enable
Response Codes 200
{
“cell”: {
“id”: “123”,
“status”: “enabled”
}
}