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
Nova already has support for hotplugging neutorn ports in the libvirt
driver. This extends the support to the XenAPI driver, implement
attaching/detaching VIFs
I have made a patch to run releated testcase in xenserver CI
https://review.openstack.org/#/c/416797/
Change-Id: I22f3fe52d07100592015007653c7f8c47c25d22c
Implements: blueprint xenapi-vif-hotplug
This document describes the steps to test zero downtime
upgrade process.
Change-Id: Ieafd65da959f6153524f1f3ab0522025b94cbef4
Co-Authored-by: Anusha Unnam <anusha.unnam@intel.com>
This patch adds attach/detach interface information
to the support matrix.
CLI support information from this commit:
https://review.openstack.org/#/c/272471/
Co-Authored-By: Kevin_Zheng <zhengzhenyu@huawei.com>
Change-Id: I6182585ae5a622b7ff0b22dff41ab7ff4d4c0afa
Closes-Bug: #1572370
These were all deprecated in newton in change:
b82b987b76
The network and floating IP commands can't be removed yet
because devstack still relies on them, which is being worked
in I5c4291509841325e6123520131f30b64c847a17f.
Change-Id: I0c02d409c5726b5e0532fc91fb9b8c5d3196499f
Notifications related configuration options have been moved from the
default group to the ``notifications`` group.
Also, ``default_notification_level`` has been renamed to avoid naming
redundancy.
Blueprint centralize-config-options-ocata
Change-Id: I09dc358fabc84f7bf37d40d48b0652a10d9b8903
placement_dev.rst provides a nova-developer oriented perspective on
the placement API including some explanation of its structure, some
gotchas to be aware of, and some instruction on how to add to it.
Subsequent patches will fill in the missing sections.
Change-Id: Ia571800774aa14beab121c85a693d75fc30ed517
Based on the mail discussion [1] I think we should use the same payload
for delete, create, update notifications of the same entity.
This will help keep the notifications more consistent and easier
to filter.
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109501.html
Change-Id: If4237b111ffb0e8511b6a73c57807b9bd4addf80
This adds the basic framework for the nova-status
upgrade check commands. Follow up patches will flesh
this out to perform cells v2 and placement API related
upgrade status checks.
A man page is added for the new CLI and as part of that
the man page index is sorted.
Part of blueprint cells-scheduling-interaction
Part of blueprint resource-providers-scheduler-db-filters
Change-Id: I687dd7317703a1bb76c197ebba849ca368c0872e
as placement API has same file existing in the folder
we can move rest_api_version_history.rst to compute folder
so it will make the logic more clear
Change-Id: I2fa2f2121dcd0e8fd1af4527c6f31334e0b5a1c4
While doing a close read of the process doc, some issues were found
which this changeset tried to address:
* a variety of minor typos and grammatical issues
* resources that could have better links
* time/cycle dependent links and discussion that could be improved
by either changing the name of the cycle, making the statements
historical, or otherwise tweaking for some clarity
The changes are certainly not complete, but hopefully a useful
improvement.
Change-Id: I463bdf97154a5d7b241e8c11955ddbcac5804f8a
Jenkins