Difference between revisions of "DisableCellSupport"
(→DB Model Changes) |
(→Design) |
||
| Line 11: | Line 11: | ||
* 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. | * 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. | * It will extend the existing v3 cells API. | ||
| + | * Support for nova cli to update state of cell: | ||
| + | <pre><nowiki> | ||
| + | # nova help cell-update | ||
| + | usage: nova cell-update <cell-name> <state> | ||
| + | |||
| + | Update state of a given cell. | ||
| + | |||
| + | Positional arguments: | ||
| + | <cell-name> Name of the cell. | ||
| + | <state> Supported states: (ACTIVE | DRAINING | READONLY | INACTIVE) | ||
| + | </nowiki></pre> | ||
== DB Model Changes == | == DB Model Changes == | ||
Revision as of 12:59, 20 November 2013
Contents
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.
- Support for nova cli to update state of cell:
# nova help cell-update usage: nova cell-update <cell-name> <state> Update state of a given cell. Positional arguments: <cell-name> Name of the cell. <state> Supported states: (ACTIVE | DRAINING | READONLY | INACTIVE)
DB Model Changes
- New table would be like:
| Field | Type | Null | Key | Default | Extra |
|---|---|---|---|---|---|
| created_at | datetime | YES | NULL | ||
| updated_at | datetime | YES | NULL | ||
| deleted_at | datetime | YES | NULL | ||
| id | int(11) | NO | PRI | NULL | |
| api_url | varchar(255) | YES | NULL | ||
| weight_offset | float | YES | NULL | ||
| weight_scale | float | YES | NULL | ||
| name | varchar(255) | YES | MUL | NULL | |
| is_parent | tinyint(1) | YES | NULL | ||
| deleted | int(11) | YES | NULL | ||
| transport_url | varchar(255) | NO | NULL | ||
| state | varchar(255) | YES | NULL |
API Spec
- Change cell state
- PUT v3/{tenant_id}/os-cells/state
- Response Codes 200
- Request parameters
- {
- “cell”: {
- “id”: “123”,
- “state”: “Active/Draining/ReadOnly/Inactive”
- }
- }
