Detail these features, including links to the documentation. No tests
are provided as no upstream Tempest tests currently exist.
Change-Id: I1bb3674f35f83e2a33243103a267b4aff70f852e
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
There is an up-call from the xenapi driver when performing a live
migration and --block-migrate is not specified such that the driver
checks to see if the source and destination hosts are in the same
aggregate. This fails in a super-conductor setup because the
aggregates are now in the API database and the cell conductor
won't be able to access that database by design.
Change-Id: I6c880c72d87eb0116cb57371e5d600dced2915f7
Related-Bug: #1709594
This provides a more detailed, but still high level, explanation
of how the FilterScheduler is using allocation candidates to pick
hosts during scheduling, and how the allocations are handled during
a move operation, including a resize to the same host.
Ideally this content will live somewhere else in the devref, or
would be updated in the spec for blueprint placement-claims, but
for now this should suffice for Pike release notes that can point
at this upgrade doc.
Change-Id: I274c684f829bc310ebb17faabf498d36f4ceea0c
This adds information about where the consoleauth service and console
proxies should run with multiple cells in Cells v2.
Change-Id: Ib817581dfe0c32d3888c242166e3daa7b954320a
This adds another subsection to the caveat section about operations that
require upcalls in Pike not being supported.
Change-Id: If95be4f631f929cd8c6528671433ae0fc747a6be
List items need to be exactly 2 spaces off of the parent, and the top
level left justified, otherwise <blockquote> gets thrown into the
html.
Part of bp: doc-migration
Change-Id: I16634edbc562aff69744e5d7c7275689326ab8d0
What looked clear in the rst actually was far from clear when rendered
in HTML. The document was restructured a bit so all the options end up
in a single bullet list, and the combination description is a separate
section.
Part of bp: doc-migration
Change-Id: I2feee4018a332483658d24d299dbb04ec87f2df0
This adds a fresh cellsv2 overview document that talks about
deployment decisions for single and multiple cell environments
in an attempt to help address confusion about what the service
layouts look like in a multi-cell setup.
Change-Id: I1da7c375dbb98c125aebabec548280de8d8ed381
With multi-cell support in Pike, we should deprecate cells v1
so we can at least start the deprecation signaling in the
docs and release notes. We may not end up removing cells v1
code in Queens, but this at least gives us the option.
Note that we also want to do this because nova-network cannot
be removed until we remove cells v1.
Change-Id: I1a173f7ce0715e684850e030c358e8175fa8724c
It's super confusing for new people to nova and cells
to see config options in a [cells] group and think they
should be changing those, like enable and cell_type.
While we have warnings in the config option help text,
let's also put a reminder in the FAQ page in the docs.
Change-Id: I5e106d9e0743d918e2115d809ac3732c5a3d7a5a
nova console-log is supported in novaclient from nova
API 2.1 (2.0) and nova trigger-crash-dump was added for
API 2.17 (commit 6cbb22583b94660cfd78d8ee0068778d5279ceca)
so we can add those cli for user reference.
Change-Id: I17bf421a7eb2ec9ff7e94704889ea22bebfa980b
This enables Ironic to boot bare metal machines from Cinder
volume. Ironic virt driver needs to pass the remote volume
connection information down to Ironic when spawning a new
bare metal instance requested to boot from a Cinder volume.
This implements get_volume_connector method for the Ironic
driver. It will get connector information from the Ironic service
and pass it to Cinder's initialize_connection method for attached
volumes. And then it puts the returned value into Ironic.
This patch changes the required Ironic API version to 1.32 for using
new API for volume resources.
Co-Authored-By: Satoru Moriya <satoru.moriya.br@hitachi.com>
Co-Authored-By: Hironori Shiina <shiina.hironori@jp.fujitsu.com>
Change-Id: I319779af265684715f0142577a217ab66632bf4f
Implements: blueprint ironic-boot-from-volume
Set the attach and detach interface features as complete.
Implements: blueprint ironic-hotplug-interfaces
Depends-On: I48c4706b3eb6e0a5105e463236870921d55dbd93
Change-Id: I8ed286d57ccaab9a6cb0eda62e30859e7a17e826
Per the spec [1]:
user/ – end-user content such as concept guides, advice, tutorials,
step-by-step instructions for using the CLI to perform specific tasks,
etc.
The remaining content all ends up in here.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I480eee9cd7568efe2f76dd185004774588eb4a99
Jenkins