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:
parent
904c4a1d9a
commit
c62ed630a9
|
@ -320,6 +320,7 @@ following:
|
||||||
#. Instance affinity reporting from the compute nodes to scheduler
|
#. Instance affinity reporting from the compute nodes to scheduler
|
||||||
#. The late anti-affinity check
|
#. The late anti-affinity check
|
||||||
#. Querying host aggregates from the cell
|
#. 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
|
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
|
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
|
based on source and destination hosts being in the same aggregate. Since
|
||||||
aggregates data has migrated to the API database, the cell conductor will
|
aggregates data has migrated to the API database, the cell conductor will
|
||||||
not be able to access the aggregate information and will fail.
|
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.
|
||||||
|
|
Loading…
Reference in New Issue