openstack
/
nova
Code Issues Proposed changes

doc: add superconductor up-call caveat for cross_az_attach=False 

When attaching a volume, if CONF.cinder.cross_az_attach=False,
we attempt to lookup the AZ that the instance is in and compare
that to the volume AZ. The instance AZ lookup involves getting
host aggregates which are in the API database, and in superconductor
mode the cell conductor can't access to the API database.

For volume attach, we could remove this check from the compute
service since we already check this in nova-api so the check in
nova-compute is redundant.

However, we still have a problem with checking this during boot
from volume where nova-compute creates the volume and then
attaches it. At that point it's too late and we'll fail.

We should eventually create volumes during boot from volume in
conductor, like we've talked about doing with neutron ports
during server create, but that's not something we have today
so we need to point out this limitation.

Change-Id: I9cbe41e41f8ccdc9962ab593f313b5a47314a9d1
This commit is contained in:
Matt Riedemann 2017-08-11 09:22:27 -04:00
parent 904c4a1d9a
commit c62ed630a9
1 changed files with 14 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/source/user/cellsv2_layout.rst
View File

@ -320,6 +320,7 @@ following:
#. Instance affinity reporting from the compute nodes to scheduler
#. The late anti-affinity check
#. Querying host aggregates from the cell
#. Attaching a volume and ``[cinder]/cross_az_attach=False``
The first is simple: if you boot an instance, it gets scheduled to a
compute node, fails, it would normally be re-scheduled to another
@ -344,3 +345,16 @@ driver will attempt to figure out if block migration should be performed
based on source and destination hosts being in the same aggregate. Since
aggregates data has migrated to the API database, the cell conductor will
not be able to access the aggregate information and will fail.
The fifth is a problem because when a volume is attached to an instance
in the *nova-compute* service, and ``[cinder]/cross_az_attach=False`` in
nova.conf, we attempt to look up the availability zone that the instance is
in which includes getting any host aggregates that the ``instance.host`` is in.
Since the aggregates are in the API database and the cell conductor cannot
access that information, so this will fail. In the future this check could be
moved to the *nova-api* service such that the availability zone between the
instance and the volume is checked before we reach the cell, except in the
case of boot from volume where the *nova-compute* service itself creates the
volume and must tell Cinder in which availability zone to create the volume.
Long-term, volume creation during boot from volume should be moved to the
top-level superconductor which would eliminate this AZ up-call check problem.