Difference between revisions of "DisableCellSupport"
(→Use case) |
(→Design) |
||
| Line 8: | Line 8: | ||
* 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. | * 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. | ||
| − | == | + | == Design == |
| − | * Add | + | * Add “state” field to cells table, in the first stage, only ACTIVE and INACTIVE states will be implemented, then additional states could be added as the use cases are clarified. |
| + | * It will extend the existing v3 cells API. | ||
== API Spec == | == API Spec == | ||
Revision as of 09:40, 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.
Design
- Add “state” field to cells table, in the first stage, only ACTIVE and INACTIVE states will be implemented, then additional states could be added as the use cases are clarified.
- It will extend the existing v3 cells API.
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”
- }
- }
