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>
The unsorted nature of this has always annoyed me, and since
I'm going to add a new item to the list in a following change
let's sort the list. Note that the list is sorted by title
in the linked doc, not the name of the doc file itself.
Change-Id: I24671fe5256889c3abc1ba36d70a450213f20234
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
To help adding new notification to nova we shall have a guideline
what should and what should not be in the notification payload.
Change-Id: Ic85d304974bbfa7e02999ec3d6c9bba1d1aed3c8
Add a paragraph which clarifies that a specless blueprint needs to
be approved and the normal process for doing so, with links to
additional information.
Change-Id: I1d4fc40a2e5acb8b63f90e00dc19ee5a65fbe870
This is the initial set of docs for the placement API
service introduced in the Newton release.
We still have to flesh out the API reference in detail
but this gets us started.
The deployment steps are taken from how devstack does
this today.
Change-Id: Ic2436d92a7cefaeb1ae67ed878da968444f2f18d
The ability to change the root password on a guest using the
xenserver driver is conditional on the xenapi agent being on
the guest, we should document this wrinkle like we do for the
libvirt driver.
Change-Id: If880e85daa52364e55a70bf8df54a21a003a4620
Adding a reminder that V2 APIs should no longer be used and are only
available for backward compatibility purposes.
Change-Id: Ib885c102a59b3c339b0e7986145a1c2defb346fc
Closes-bug: 1580552
Update the documents, making the following changes:
* Reference Fedora 24 instead of the outdated Fedora 21
* Don't reference the removed 'rejoin-stack' script
* Let devstack do as much work for us as possible (NUMATopologyFilter)
* Don't overcomplicate anything (installing emacs, using non-standard
devstack install dir)
* Use '$' prefix for non-root commands
* Update XML with latest examples
* Use the 'openstack' client, rather than the 'nova' client
* Random formatting fixes
...and, finally, stop hating on poor, innocent vi.
Change-Id: Idc89a5c0617ccf7044e1cfc2b5d7f5ff4004b5bf
There are two changes here:
1. The serial_console config option group help text is
updated to point out that hyper-v also supports serial
console access. This is based on virt drivers that
implement the 'get_serial_console' method.
2. The hypervisor feature matrix is updated to point out
that the vmware driver does not support getting serial
console output. This is based on virt drivers that
implement the 'get_console_output' method.
Closes-Bug: #1632135
Change-Id: Ibf7f865e2b768e5ea3d7a7ec7cbf77bd8997c50f
Pavel Gluschak