Difference between revisions of "DisableCellSupport"
(→Use case) |
(→API Spec) |
||
(7 intermediate revisions by 2 users not shown) | |||
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. Typically there would be | + | * 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 5 states: active, draining, testing, read-only and inactive |
: * Active would be the usual state. | : * Active would be the usual state. | ||
: * Draining would respond to queries, migrations and deletes but refuse new schedule requests. | : * Draining would respond to queries, migrations and deletes but refuse new schedule requests. | ||
+ | : * Testing would respond as Active but only when targeted with schedule hints, etc. Otherwise, it would behave like Inactive relative to any other activity | ||
: * Read-only would only permit queries. | : * Read-only would only permit queries. | ||
: * Inactive would not respond. | : * 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. | + | * 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. Testing would be very useful for larger implementations that regularly add cells to exiting regions and would want to QC them independently from production. Inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behavior. |
− | == | + | == 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. | ||
+ | * 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 | TESTING | READONLY | INACTIVE) | ||
+ | </nowiki></pre> | ||
+ | |||
+ | == DB Model Changes == | ||
+ | * New table would be like: | ||
+ | {| class="wikitable" | ||
+ | |- | ||
+ | ! 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 || auto_increment | | ||
+ | |- | ||
+ | | 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 == | == API Spec == | ||
− | * | + | * Change cell state |
− | :PUT v3/{tenant_id}/os-cells/ | + | :PUT v3/{tenant_id}/os-cells/update |
:Response Codes 200 | :Response Codes 200 | ||
:Request parameters | :Request parameters | ||
Line 20: | Line 65: | ||
:: “cell”: { | :: “cell”: { | ||
:: “id”: “123”, | :: “id”: “123”, | ||
− | :: | + | :: “state”: “Active/Draining/Testing/ReadOnly/Inactive” |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
:: } | :: } | ||
:} | :} |
Latest revision as of 19:28, 2 April 2014
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 5 states: active, draining, testing, read-only and inactive
- * Active would be the usual state.
- * Draining would respond to queries, migrations and deletes but refuse new schedule requests.
- * Testing would respond as Active but only when targeted with schedule hints, etc. Otherwise, it would behave like Inactive relative to any other activity
- * 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. Testing would be very useful for larger implementations that regularly add cells to exiting regions and would want to QC them independently from production. Inactive would be where you really don't want the cell to answer. There are probably other components in OpenStack that also exhibit this behavior.
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 | TESTING | 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/update
- Response Codes 200
- Request parameters
- {
- “cell”: {
- “id”: “123”,
- “state”: “Active/Draining/Testing/ReadOnly/Inactive”
- }
- }