DisableCellSupport

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
usage: nova cell-update 
 * 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:
 * 1) nova help cell-update

Update state of a given cell.

Positional arguments:  Name of the cell. Supported states: (ACTIVE | DRAINING | TESTING | READONLY | INACTIVE)

DB Model Changes

 * New table would be like:

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”
 * }
 * }
 * }