* "compute service set" command requires a host, not a zone
* the --disable-reason flag's argument has to be quoted
Change-Id: Iaf58d702b1619a66f97553cf2e47eb8c85166bf6
Per the previous code comment, we can now use shred to zero
volumes efficiently on modern distros. Let's do that.
A thread on openstack-dev (http://lists.openstack.org/pipermail/openstack-dev/2017-August/121301.html)
confirms that all our supported distros now use a new enough
version of shred.
Change-Id: I1f0ba72ddeb26eb51bf5e7c3db017b108e0494e9
Notifications are essentially another API for end users, but
it can be hard to find the list of existing notifications or
their samples which are buried deep down via contributors >
technical reference deep dive > notitfications. If I'm an
end user, I'd like to just see them in the same set of links
on the main page as the API, under the "For End Users" section.
Change-Id: If3ca21b080d06a291ed27c9bcd84a566164c3b70
Now that we have a placement api-ref getting published, we
should link to it like we do for the compute api-ref. This
also links in the placement microversion history for consistency.
Change-Id: Id0c70486c5a72a4d6794d80d350a45a5f356ca37
There is no --limit option on the online_data_migrations
command, it's called --max-count.
This fixes that typo in the upgrades doc and also fixes
another grammar nit that was bugging me.
Change-Id: Ib76ced58314e025f617c1b4d964cd0c62d908a37
Related-Bug: #1670738
This adds a functional recreate test for bug 1713786 where
allocations are not created against the forced destination host
during an evacuation.
This asserts the faulty behavior so that a later patch which fixes
the bug can uncomment the assertions for correct behavior.
Change-Id: I55bf64a95f6b1b781656920380dc38bda864bd14
Related-Bug: #1713786
adding cli documentation for online_data_migrations to clarify
when the command is complete.
Closes-Bug: #1670738
Change-Id: If50bd044091250611a7d3d67438d732279510d5b
Add functional test for evacuation, when no valid host available.
Migration should end up in 'error' state.
Change-Id: I1adc20f2a5261e6906a18b9aee5cd2c8ecf0cf4d
Related-bug: #1713783
The new doc template includes jquery too late and therefore showing
and hindig notification samples and auto hiding them by default doesn't
work.
This patch loads the jquery lib earlier for the notification devref.
Closes-Bug: #1713974
Closes-Bug: #1714363
Change-Id: I07db4755c69d493e591761578d1077bb44acda41
Bypassing the scheduler during a live migration or evacuation
is not something we want people to be doing as it can easily fail
if the specified host is already full or doesn't provide something
required by the instance, plus it's a nightmare for tracking allocations
in the Placement service when we're bypassing the scheduler.
Because of this, we should have some warnings in the API reference
about doing this, which this patch adds.
Change-Id: I85e7c2677f4d5eccc1e7f349de06960b53ef148d
Currently only "virtio" type is supported on AArch64, and the
other "virrus", "qxl" and "vga" don't work on AArch64 according to
libvirt upstream:
https://www.redhat.com/archives/libvir-list/2016-September/msg00546.html
Then this patch adds the virtio for AArch64 and tweaks the related test cases.
Closes-bug: #1710766
Change-Id: Iba8a1e671f2b5759b3d9178aa1871d0cf888b26b
Signed-off-by: Kevin Zhao <kevin.zhao@arm.com>
If an allocation was made with an empty resources object, a 500 response
code would result. This change adjusts the schema to use minProperties
of 1 to say there must be at least one resource class and value pair in
the allocation. If there is not a 400 response is returned.
As this is fixing 500 response to a useful error, no microversion is
required. A previous gabbi file which demonstrated the problem has been
updated to demonstrate that the problem has been fixed.
Change-Id: I7d9c64c77586564fb3bdbe92c693bd2a1bc06f24
Closes-Bug: #1714072
If the resources object in an allocation request is an empty dict then
there will be a 500 deep in the belly of the AllocationList object
handling when it tries get a information. The patch demonstrates the bug
with a new gabbi test that verfies the 500. The next patch will fix it.
Change-Id: I5ab417e39044af63fb9acb57c48c087ecf1e6f04
Related-Bug: #1714072
When performing nova assisted volume snapshots, the nova api does
not receive an instance id, so there is not the usual instance
lookup from the cell which automatically targets the context for the
cell that the instance was pulled from, which is also where we'd get
the BDM.
Since we do not know which cell to target when fetching the BDM, we
have to iterate through *all* of them.
Closes-Bug: #1713735
Change-Id: Id2e3d3f177739a31d63790e4a1ae6ac41f438ddd
This adds a functional test to recreate bug 1712411 where
the allocations created against the destination node are not
cleaned up by conductor when a MigrationPreCheckError happens
and a rechedule to another host happens (or max retries are
exceeded which is the case here with only two computes).
Change-Id: Ieee45521c7e362b7dd053b20d3c39dea330ca080
Relatd-Bug: #1712411