This removes some references to "online schema migrations", as well
as some references to in-progress things that have been (long since)
completed. It also clarifies some of the upgrade steps, and unifies
the notion of "offline" and "live" upgrades, calling out only a couple
places where the process differs.
This came from me explaining the document to someone and calling out
things that were no longer accurate.
Change-Id: Iec1d73c3fd0038d9bca7e7fa746caad06c329ed3
This just adds some more detailed docs for upgrading
to Ocata and notable things for the Placement service
and related components as part of that upgrade.
The Ocata release notes will have some of this
information too, but I think it's good to also have
a single place for some of this, like an install/upgrade
guide for Placement.
Change-Id: Id33b9c852bb36ae80a6f29ae33d963a78cbff193
Depends-On: Ie12acb76ec5affba536c3c45fbb6de35d64aea1b
The docs for this command were woefully out of date. This
change clarifies the wording since we're really upgrading
the schema in the database, not "synchronizing" it even
though that's the name of the command - the migration scripts
run the 'upgrade' method only. Also, it was saying this was
how you created the main database, which is totally wrong
since this command doesn't create the database. The deployer
creates the database, this command migrates the schema on that
database.
Then I also added the arguments along with a description of each
and noted that this will by default upgrade the cell0 schema.
Change-Id: I3d40cb32c325bc3f665e727b921082efba043192
This is just a simple change that provides a references section
for setting up cells v2 and points to the nova-manage cell_v2
man pages.
Change-Id: I94d3de97f4ff2120e250ac40ac82c31372d90a2b
There are two changes here:
1. Removes the mention of the message queue since the cell0
mapping has a transport_url but it's effectively none meaning
we don't use RPC for accessing cell0 objects.
2. Adds boilerplate wording on the config option used to determine
the database connection if the --database_connection argument
is not specified. This was particularly confusing at one point
because it originally started out as the CONF.api_database.connection
but we changed that mid-cycle in Ocata since the schema for cell0
is the cell (nova) DB, not the nova_api DB.
Change-Id: Ie869f8565460600da767d99e9e397abc5e8bf0e0
Document the `nova-manage cell_v2 delete_cell` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I280b87ad38feeaa68728f51c78b1c6a0dc895ca7
Document the `nova-manage cell_v2 list_cells` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I0cd0c3d8c6cd0229a62b3eaf18679d4931c6e4eb
Document the `nova-manage cell_v2 discover_hosts` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I7ce9a93384741e42f409324cf0ee3cb1fc4c6a67
Document the `nova-manage cell_v2 create_cell` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: Ic9ddef319aaf8a377d733633cc279a0fc1558cb2
Document the `nova-manage cell_v2 verify_instance` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: Id243299bdf0f115e86200cee38634791ea359b2a
Document the `nova-manage cell_v2 map_cell_and_hosts` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I4ed1e77f100e9d90d6a1ebd5e20bdd1f1ff5ce6e
This patch adds a new method "trigger_crash_dump" to Ironic virt
driver. Ironic supports this feature since Ironic API version 1.29.
It also requires python-ironicclient >= 1.11.0.
Change-Id: I33812abbff919e5e477334c3bc46309491d14b6a
Implements: blueprint inject-nmi-ironic
Co-Authored-By: Tang Chen <chen.tang@easystack.cn>
Co-Authored-By: xiexs <xiexs@cn.fujitsu.com>
Depends-On: Iac112b82bab9cdf8a383879f9424cb368df741d6
Document the `nova-manage cell_v2 map_instances` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: Ie7b8a3b54ca851485393e279d2355f57a097b4d2
Document the `nova-manage cell_v2 map_cell0` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I088c959ee5e20e754c2bcfc4a3698db83abc570c
Document the `nova-manage cell_v2 simple_cell_setup` command.
This is part of a series to document the nova-manage cells
commands.
Change-Id: I236d47595b29dbfa18c2c26902301e764d086556
There was a typo in here about the map_cell0 command creating
a db connection with a _nova suffix when it's actually a _cell0
suffix like in the example, nova_cell0.
This also adds a reminder to sync the API database schema before
running the commands and also gives a warning about being
specific when using map_cell0 and having the databases on different
hosts.
Depends-On: I541b072638b5d50985145391e76f610417fdcaa6
Change-Id: Ibf3355217bbd0139a020de352bb62ff7d973d27b
This is the first commit in a series to document the nova-manage cells
commands.
This scope of this first commit is limited to cleaning up the section
titles, and removing the hardcoded list of categories as it is prone to
becoming out of date (and is currently not up-to-date).
Change-Id: I59af436fca739de3d4d5033f7b5eb43a8dff287f
There is no 'nova-manage image' subcommand so this removes
it's reference from the man pages.
Change-Id: Ia918006d58c8d7536c37187c37b8004c6f7d3aac
Closes-Bug: #1656686
While we've not made any immediate plans to do the extraction we
should avoid adding complexity that would make it harder later, so
this new section discusses the plan to eventually extract, and the
structures that either help or hinder this.
Change-Id: Ia3e95e4b85aa768b8f94d4a99963c7ec719b8a13
The section gives an overview of the steps required to add a new
handler to the placement API and the usual expectations of those
steps.
Change-Id: I41e8e413c30c44f3b6f6b1a8b559f0d39d793f68
Add a section to placement_dev.rst explaining how testing of the
placement API works, mostly gabbi. The idea here is not to duplicate
the gabbi docs, but to provide some context on how the use of gabbi
fits in to the existing tests and how to add more, with links off to
the docs for a bit more info.
Change-Id: If99521881a017543acdbbf7e8f1b7f170f5d633d
A section for placement_dev.rst describing how to manage
microversions, including available utility methods.
Change-Id: I8ace96ed7fd721c547cedf5285833a8baa52a70a
Live migration for Libvirt vz driver works the same
way as for qemu. However some migration capabilities
are supported differently:
* Virtuozzo containers doesn't use backing file, so
we shouldn't ensure it exists in pre live migration.
* migrate_disks parameter doesn't make sense for
Virtuozzo, as backend determines whether specific
block device should be migrated or not.
* Passing new domain xml to migration method is not
supported.
Implements: blueprint live-migration-vz-driver
Change-Id: I89ecdef13ad47800abc8a5158f8834e46750b9ea
Signed-off-by: Pavel Gluschak <pglushchak@virtuozzo.com>
Minor edits to clarify some points and grammar in the placement
doc. Since I was giving it a close read anyway, I thought it
best to commit changes for the small number of issues that were
apparent.
Change-Id: I8eb94a94a72e3a30fd17479d5168cd6a10f62ed3
Update the placement docs to reflect the fact that the compute service
will keep attempting to connect to the placement service rather than
just aborting like it used to.
Depends-On: Ie6387afeb239a20d39c00f519e8288f3b3a5e9cb
Change-Id: I6246f6c7318f53c2a917dc320b328fec536506b5
Jenkins