This patch replaces mox stubs with stub_out in
nova/tests/unit/api/openstack/compute/test_extended_volumes.py.
Change-Id: Ia58a5b2bb5b0647c42e34c5f6ac8babc508215c6
Implements: blueprint mox-removal
During a resize, the RequestSpec.flavor is updated
to the new flavor. If the resize failed on one host
and was rescheduled, the RequestSpec.retry is updated
for that failed host and mistakenly persisted, which
can affect later move operations, like if an admin
targets one of those previously failed hosts for a
live migration or evacuate operation.
This change fixes the problem by not ever persisting
the RequestSpec.retry field to the database, since
retries are per-request/operation and not something
that needs to be persisted.
Alternative to this, we could reset the retry field
in the RequestSpec.reset_forced_destinations method
but that would be slightly overloading the meaning
of that method, and the approach taken in this patch
is arguably cleaner since retries shouldn't ever be
persisted. It should be noted, however, that one
advantage to resetting the 'retry' field in the
RequestSpec.reset_forced_destinations method would
be to avoid this issue for any existing DB entries
that have this problem.
The related functional regression test is updated
to show the bug is now fixed.
Change-Id: Iadbf8ec935565a6d4ccf6f36ef630ab6bf1bea5d
Closes-Bug: #1718512
Commit 74ab427d47 in Newton added
code to persist changes to the RequestSpec during a resize since
the flavor changes.
That change inadvertantly also persisted any failed hosts during
the resize that are stored in the RequestSpec.retry field during
a reschedule.
The problem is that later those persisted failed hosts are rejected
by the RetryFilter, which can be confusing if an admin is trying
to live migrate or evacate the instance to one of those specific
hosts.
This adds a functional regression test to show the failure, which
will be fixed in a separate change that then modifies the assertions.
Change-Id: Ib8a23db838b0bbf2cfb8123cf6aaa39d00ff0640
Related-Bug: #1718512
test_report_client provides functional tests of the report client using
a fully operating placement service (via wsgi-intercept) but it is not,
in itself, testing placement. Therefore this change moves the test
into nova/tests/functional where it can sit besides other genral purpose
nova-related functional tests.
As noted in the moved file, in a future where placement is extracted,
nova could choose to import a fixture that placement (installed as a
test dependency) provides so that this test and ones like it can
continue to run as desired.
compute/test_resource_tracker.py is updated to reflect the new location
of the module as it makes use of it.
partially implements blueprint placement-extract
Change-Id: I433700e833f97c0fec946dafc2cdda9d49e1100b
This is similar to I18f162c4f8d1964cb4d0c184ff2149c76e1e86b4,
except all REST API interactions that hit the Cinder API use
the request user token, so configuring auth for [cinder] was
only recently added (in Queens) and is not required. However,
it is needed for certain scenarios where there is no user token,
like with periodic tasks to shutdown an instance and detach its
volumes. As such, we need to provide a more useful error message
to help an operator debug the problem if this don't have the
configuration needed for some operations.
Change-Id: I7adaa003a86503b711e87be671e9ef9c0e52b152
Related-Bug: #1761487
It is not uncommon to triage bugs on a weekly basis where the
[neutron] auth credentials are not configured in nova.conf, which
generally leads to a 500 response in the compute API because of
the auth error.
With respect to neutron, the compute install guides really only
say to set use_neutron=True, but don't mention that configuring
the [neutron] section for auth is required. The networking service
install guide does, so it's a bit confusing why people make this
mistake in the first place, but as a reminder, this change adds
links from the compute install guide to the relevant sections
in the networking service install guides.
Change-Id: Id17457bd2770fcbebd6231919ba4002e75410089
Closes-Bug: #1761487
We only need to get the image metadata and build the legacy
filter_properties dict if we don't have a request spec, which
at this point in nova should never be the case, but cleaning
all of that fallback code is a longer bigger effort for another
day.
This change simply moves the image meta and filter properties
code into the conditional that actually uses them, and cleans
up several tests while at it.
Change-Id: I68589e00dd6c2efdbe19eb4cea0be546a1bd5151
Everyone seems to agree that the only sane ordering of these operations
is "api first, cell after." However, grenade and our own documentation
shows the api database as coming after the main one. I believe this
was added to grenade in a sort of append operation, and thus after the
main database. This was done back when usage of the API database was
still optional (for upgrades) and thus the ordering didn't matter much.
Since the process has been correct (api first) in devstack for a long
time, and since grenade runs after devstack, we haven't had any issues.
A recent change to add something to a core data structure column format
highlighted the out-of-order-ness of this.
I also believe the docs got the same append behavior when adding the
command to the list, and/or it may have been copied from grenade, which
is our in-code manifestation of the upgrade steps.
Change-Id: I19f263ed314a8b01bbb07337467392cc1c146b66
Related-Bug: #1761775
As required by Eric Fried during review of
I9610070deeb9d31a2457e196b733645042997050.
Change-Id: I10382329524bcd217299df15c586615193205bdc
blueprint: remove-nova-network
The image meta data object now parses the un-numbered traits fields
defined as part of image properties. These traits are intended to be
passed to the scheduler -> placement api to pick the resources matching
the traits.
Added unit tests for the same.
Change-Id: I86872e482d9a646204e4c3a3e5126fea474b574b
Implements: blueprint glance-image-traits
Replace an exec() of rm with a more pythonic thing, with a simple
retry loop now that we can't just use the one oslo gives us for
free. The retry delay is the same as that currently used by
oslo.
Change-Id: Icdd039bb4374269d9da38e7f8d2e15e05ca8aadb
blueprint: execs-ive-had-a-few
In change I2b94945a0963d6a61af931505b69afe2d4733759 the exceptions that
placement uses were moved into the placement hierarchy and most of the
code that uses those exceptions was updated to reflect the change.
I86416e35da1798cdf039b42c9ed7629f0f9c75fc merged slightly before,
and had not made the change to the new style.
As the old aggregate handler had no exceptions imported, there was no
merge conflict when the exceptions change merged. At the same time
the exception in question is not covered by tests, because it only
happens if there is a concurrent update, which we don't cover in the
gabbi tests. We do cover a generation conflict on a supplied
generation, but that's not the same thing.
So basically this went by without us noticing and I happened to notice
while doing something else, so here's a fix for it.
To test it, a new directory for unit tests for handlers is added and
a new file, test_aggregate. Following the guidelines in
https://docs.openstack.org/nova/latest/contributor/placement.html#testing
the problematic code has been extracted to its own private method so that
it can be tested as a unit with limited mocking. The overarching flow
of setting aggregates continues to be tested by the gabbi functional
tests.
Note the added NOTE in the new _set_aggregates method: It appears that
the DBDuplicateEntry exception maybe doesn't need to be there.
Change-Id: I4b7b29270b2d9900b59c7dd74082688164430252
Closes-Bug: #1761295
When the [neutron] section of nova.conf isn't configured for
auth with the networking service, end users of the compute
REST API get a 500 error and the logs contain this mostly
unhelpful error message:
Unauthorized: Unknown auth type: None
This change adds a more useful error log message indicating
the root problem and provides a link to the networking service
install guide for how to resolve it.
Change-Id: I18f162c4f8d1964cb4d0c184ff2149c76e1e86b4
Partial-Bug: #1761487
The recent "Meltdown" CVE fixes have resulted in a critical performance
penalty[*] that will impact every Nova guest with certain CPU models.
I.e. assume you have applied all the "Meltdown" CVE fixes, and performed
a cold reboot (explicit stop & start) of all Nova guests, for the
updates to take effect. Now, if any guests that are booted with certain
named virtual CPU models (e.g. "IvyBridge", "Westmere", etc), then those
guests, will incur noticeable performance degradation[*], while being
protected from the CVE itself.
To alleviate this guest performance impact, it is now important to
specify an obscure Intel CPU feature flag, 'PCID' (Process-Context ID)
-- for the virtual CPU models that don't already include it (more on
this below). To that end, this change will allow Nova to explicitly
specify CPU feature flags via a new configuration attribute,
`cpu_model_extra_flags`, e.g. in `nova.conf`:
...
[libvirt]
cpu_mode = custom
cpu_model = IvyBridge
cpu_model_extra_flags = pcid
...
NB: In the first iteration, the choices for `cpu_model_extra_flags` is
restricted to only 'pcid' (the option is case-insensitive) -- to address
the earlier mentioned guest performance degradation. A future patch
will remove this restriction, allowing to add / remove multiple CPU
feature flags, thus making way for other useful features.
Some have asked: "Why not simply hardcode the 'PCID' CPU feature flag
into Nova?" That's not graceful, and more importantly, impractical:
(1) Not every Intel CPU model has 'PCID':
- The only Intel CPU models that include the 'PCID' capability
are: "Haswell", "Broadwell", and "Skylake" variants.
- The libvirt / QEMU Intel CPU models: "Nehalem", "Westmere",
"SandyBridge", and "IvyBridge" will *not* expose the 'PCID'
capability, even if the host CPUs by the same name include it.
I.e. 'PCID' needs to be explicitly when using the said virtual
CPU models.
(2) Magically adding new CPU feature flags under the user's feet
impacts live migration.
[*] https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU
Closes-Bug: #1750829
Change-Id: I6bb956808aa3df58747c865c92e5b276e61aff44
BluePrint: libvirt-cpu-model-extra-flags
The aggregate.update_metadata.start and aggregate.update_metadata.end
notifications has been transformed to the versioned notification framework.
Co-Authored-By: Takashi Natsume <natsume.takashi@lab.ntt.co.jp>
Change-Id: Iab73b1351a50869620334f692aaefb566ba4ddf8
Implements: bp versioned-notification-transformation-rocky
In Pike we started requiring that ironic instances have their
embedded flavor migrated to track the ironic node custom
resource class. This can be done either via the normal running
of the nova-compute service and ironic driver or via the
'nova-manage db ironic_flavor_migration' command.
This change adds a nova-status check to see if there are any
unmigrated ironic instances across all non-cell0 cells, and
is based mostly on the same logic within the nova-manage command
except it's multi-cell aware and doesn't use the objects.
Change-Id: Ifd22325e849db2353b1b1eedfe998e3d6a79591c
Due to change c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 in
oslo.serialization, serialized exceptions in errors no longer
have kwargs. This change fixes the problem by adding __repr__
to NovaException which will return a string representation
of exception.__dict__. This string contains the exception message
along with all the kwargs. Without __repr__, the serialization
process for exceptions just returns the exception type and the
default message, without the kwargs.
Change-Id: I653282a030d03362dfca0fd1026cebe920d54e37
Closes-Bug: #1756360
Through these new options, users can enable or disable a cell
through the CLI.
Related to blueprint cell-disable
Change-Id: I761f2e2b1f1cc2c605f7da504a8c8647d6d6a45e
Takashi NATSUME