Fix nits in the handling down cell spec

This patch addresses the nits in bp/handling-down-cell

Change-Id: I65dc63b8767888618ef52c519d5b158af61823ab
Related to blueprint handling-down-cell
This commit is contained in:
Surya Seetharaman 2018-07-10 09:51:27 +02:00 committed by Matt Riedemann
parent 17b2e4a395
commit fff27cf9b9
1 changed files with 11 additions and 7 deletions

View File

@ -85,7 +85,7 @@ from the down cell:
#. ``nova list`` should return a minimalistic construct from the available
information in the API DB which would include:
#. instance_uuid and project_id from the instance_mapping table.
#. created_at, instance_uuid and project_id from the instance_mapping table.
#. status of the instance would be "UNKNOWN" which would be the major
indication that the record for this instance is partial.
#. rest of the field keys will be missing.
@ -100,6 +100,8 @@ from the down cell:
include:
#. instance_uuid, created_at and project_id from the instance_mapping table.
#. status of the instance would be "UNKNOWN" which would be the major
indication that the record for this instance is partial.
#. user_id, flavor, image and availability_zone from the request_spec table.
#. power_state is set to NOSTATE.
#. rest of the field keys will be missing.
@ -119,10 +121,11 @@ from the down cell:
instance_mapping table and prevent the boot request if it has. However it
might not be desirable to block VM creation for users having VMs in multiple
cells if a single cell goes down. Hence a new policy rule
``os_compute_api:servers:create:cell_down`` which defaults to ``is_admin``
can be added by which the ability to create instances when a project has
instances in a down cell can be controlled between users/admin. Using this
deployments can configure their setup in whichever way they desire.
``os_compute_api:servers:create:cell_down`` which defaults to
``rule:admin_api`` can be added by which the ability to create instances
when a project has instances in a down cell can be controlled between
users/admin. Using this deployments can configure their setup in whichever
way they desire.
For the 1st, 2nd and 4th operations to work when a cell is down, we need to
have the information regarding if an instance is in SOFT_DELETED/DELETED state
@ -313,6 +316,7 @@ JSON response body example::
"metadata": {}
},
{
"created": "2018-06-29T15:07:29Z",
"status": "UNKNOWN",
"tenant_id": "940f47b984034c7f8f9624ab28f5643c",
"id": "bcc6c6dd-3d0a-4633-9586-60878fd68edb",
@ -337,8 +341,8 @@ When a cell DB cannot be connected, ``nova list``, ``nova show`` and
``nova service-list`` will work with the records from the down cell not having
all the information. When these commands are used with filters/sorting/paging,
the output will totally skip the down cell and return only information from the
up cells. ``nova boot`` will not work if that tenant_id has any living
instances in the down cell.
up cells. As per default policy ``nova boot`` will not work if that tenant_id
has any living instances in the down cell.
Performance Impact
------------------