libvirtd was being restarted on the controller during negative
evacuation tests that rely on the service being to cause an
evacuation failure.
This change adds various virt services to the list of services stopped
and now disabled on the host to ensure these don't cause systemd to
restart libvirtd:
* virtlogd.service
* virtlogd-admin.socket
* virtlogd.socket
* virtlockd.service
* virtlockd-admin.socket
* virtlockd.socket
Closes-Bug: #1903979
Change-Id: Ic83252bbda76c205bcbf0eef184ce0b201e224fc
This job tests the recently introduced direct download of rbd hosted
Glance images into a file based imagecache.
Depends-On: https://review.opendev.org/748212
Change-Id: I0933447e6caa0013f0b26dbf6532ff1976197e80
I8b1c05317734e14ea73dc868941351bb31210bf0 introduced a crude call to
_cleanup_volumes within _do_build_and_run_instance when handling a
RescheduledException exception raised from _build_and_run_instance
without any retry information provided from the scheduler.
This situation can arise when using the 'availability_zone' parameter to
skip the scheduler by providing both a target availability_zone and host
in the format of `$availability_zone:$host`. If the instance is unable
to build on the compute the failure will eventually lead to
_cleanup_volumes calling DriverVolumeBlockDevice.detach that will either
detach (cinderv2) or delete the associated volume attachments (cinderv3)
moving the volume to an `available` state, assuming it isn't
multi-attached etc.
The issue with this is that this behaviour is in stark contrast to that
of volumes associated with instances that have failed to schedule. In
that case the volumes remain marked as reserved and associated with the
ERROR'd out instance until the instance itself is deleted.
This change aims to align both cases by removing the call to
_cleanup_volumes and in doing so keeping any volumes in a `reserved`
state until the underlying instance is deleted.
Note that leaving these volumes associated with ERROR'd out instances is
now safe after I4dc6c8bd3bb6c135f8a698af41f5d0e026c39117 landed and now
ensures that ports and volumes associated with such an instance are
correctly cleaned up.
Closes-Bug: #1899649
Change-Id: I5dda9e8bca5fbaae77ece12b67176945ca4d9a4c
At least uwsgi supports passing command line arguments to python wsgi
apps by specifying them as --pyargv for to uwsgi binary. Then the wsgi
app can access them normally via sys.argv.
This patch makes sure that nova-api and nova-metadata-api passes
sys.argv to oslo.config and therefore specifying config files for
these services now possible.
For example the following line in the systemclt service file makes sure
that the nova-api service reads both the nova.conf and the
nova-extra.conf
ExecStart = /usr/local/bin/uwsgi --procname-prefix nova-api \
--ini /etc/nova/nova-api-uwsgi.ini \
--pyargv "--config-file=/etc/nova/nova.conf
--config-file=/etc/nova/nova-extra.conf"
Change-Id: If4783adda92da33d512d7c2834f0bb2e2a9b9654
Related-Bug: #1871482
This was used to propagate the metadata changes to the hypervisor. For
all non-XenAPI drivers, we still allow updating instance metadata via
the API (i.e. '/servers/{server_id}/metadata') but this simply changes
what is exposed via the metadata API.
Change-Id: Ibd0ffd9906e7d7f22a9233539091d450e8023f07
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Change Idd49b0c70caedfcd42420ffa2ac926a6087d406e added support for
discovery of PMEM devices by the libvirt driver. Some error handling
code in this was expected to raise a 'GetPMEMNamespacesFailed'
exception, however, a typo meant the exception was actually called
'GetPMEMNamespaceFailed' (singular). This exception was later removed in
change I6fd027fb51823b8a8a24ed7b864a2191c4e8e8c0 because it had no
references.
Re-introduce the exception, this time with the correct name, and add
some unit tests to prevent us regressing.
Change-Id: I3b597a46314a1b29a952fc0f7a9c4537341e37b8
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Closes-Bug: #1904446
Follow up for change I9512f605dd2b3b0e88c951ed086250d57056303d.
Change-Id: Ia627bab8ed911baf329e0bda385beb2ffcbbe7d6
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The nova-compute fails to start if the hypervisor has PCI addresses
32bit domain.
Change-Id: I48dcb7faa17fe9f8346445a1746cff5845baf358
Related-Bug: #1897528
Add a description to update the contributor guide
in the PTL guide.
Change-Id: I1e292a98ed72cf181a944c2bb20ff3a4d0bdd600
Signed-off-by: Takashi Natsume <takanattie@gmail.com>
Before Ie15ec8299ae52ae8f5334d591ed3944e9585cf71 if the compute was
started before the conductor then the compute retried the connection
until the conductor was up. The Ie15ec8299ae52ae8f5334d591ed3944e9585cf71
break this behavior as the service version check runs before this RPC
retry mechanism and therefore the compute simply fails to start without
a retry if no conductor is started.
This patch moves the service version check after the RPC connection
retry mechanism.
Change-Id: Iad0ba1a02868eebc2f43b1ac843fcc5096cd5c47
Closes-Bug: #1904181
For amending a single value, `--amend` switch is required to be
used. Otherwise Placement will return 400 about required
properties being missing.
Change-Id: Ia94be98dea22f97bc89201ee2a0a1a4e6b54c875
When reverting a resize, we need to wait for the migration status to
change to 'reverted', but we also need to wait for the relevant
versioned notification to be emitted. The reason for this is noted in a
couple of places, including the '_revert_resize' helper in the
'nova.tests.functional.integrated_helpers.InstanceHelperMixin' module:
[T]he migration status is changed to "reverted" in the dest host
revert_resize method but the allocations are cleaned up in the source
host finish_revert_resize method so we need to wait for the
finish_revert_resize method to complete.
Two tests in the 'test_cross_cell_migrate' test module were not doing
this wait, resulting in intermittent failures in CI due to the races.
Resolve this now.
Change-Id: I3ec6cae19b362ac9cc311a979f680cf64db4f458
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Closes-Bug: #1904051
Lee Yarwood