This is a partial revert of Ie46311fa9195b8f359bfc3f61514fc7f70d78084.
Depends-On: https://review.openstack.org/643045
Related-Bug: #1819794
Change-Id: I1bf37edb4dc3bdb6f23d077eae32e81ef48bdcdc
This document was written back in the liberty release [1]
and says that conductor is not used for orchestrating the
resize/migrate flow, but given the description of how
conductor is used to orchestrate scheduling and reschedules
during a server create, it is unclear why the doc says that
resize is not used the same way since it is used for rescheduling
when prep_resize fails in a selected dest compute. This removes
the caveat to reflect reality.
[1] Ieb9134302d21a11fe9b9ee876bb7b0dd32b437e1
Change-Id: I932a7ac6870a3f9d26556c23c9074115963b3c27
If we do not pass kwargs to exception, the parameter will be deemed
as message and msg_fmt is ignored, so the message will be displayed
directly. This is to pass kwargs to some exceptions, to get better
format of error message.
Change-Id: I66677a90430d9e6699619539cb8f575f57b19433
In _get_instance_capabilities() we get a list of host capabilities and then
build a list of arches supported by the virt type of an instance to arrive
at the list of possibilities for the instance. We check each of those
against our enum, but fail to gracefully skip unsupported values should we
encounter one.
This patch makes that graceful, and also introduces an unsupported arch to
the test stub to make sure we always skip it. Note that we do not warn
because this happens once per instance in a periodic task, and since the
situation is caused by a (somewhat permanent) mismatch of libvirt and
nova version support, isn't something that needs to be remedied by an
operator.
Closes-Bug: #1820125
Change-Id: I5d95bd50279a6bf903a5793ad5f3ae9d06f085f4
I noticed change Iea6288fe6d341ee92f87a35e0b0a59fe564ab96c
was not running the nova-live-migration job even though
it was making changes to nova/tests/live_migration/hooks/run_tests.sh.
The reason is the nova-live-migration job irrelevant-files were
excluding changes to nova/tests/*.
This copies the nova-grenade-live-migration irrelevant-files list
to the nova-live-migration job and defines it as a variable so it
can be re-used in the nova-grenade-live-migration job definition.
Change-Id: I753fda1a83b340f4699c049158e6744b099f55d8
While moving the legacy job nova-next on bionic, tls-proxy
did not work and leads to nova-next job fail.
To proceed further on Bionic migration which is blocked by nova-next failure,
this commit temporary disable the tls-proxy service until bug#1819794 is fixed.
Also this updates the parent of nova-tox-functional-py35 from openstack-tox
to openstack-tox-functional-py35 in order to handle the upcoming change
of the infra CI default node type from ubuntu-xenial to ubuntu-bionic.
The python3.5 binary is not provided on ubuntu-bionic and the shared
"py35" job definitions in the openstack-zuul-jobs repository have been
patched to force them to run on ubuntu-xenial [1]. We should inherit
from one of these jobs for jobs that rely on python3.5.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003746.html
Related-Bug: #1819794
Change-Id: Ie46311fa9195b8f359bfc3f61514fc7f70d78084
Add description of cases that 'block_device_mapping_v2.volume_size`
is required in the "Create Server" (POST /servers) API.
Change-Id: I36f28ca756b908b5fc591cc87f5786a3e217285e
Closes-Bug: #1818310
The file virt.py has been remove from the patch
https://review.openstack.org/#/c/392566/.
So use_cow_images config is now in file compute.py
Change from virt to compute for it.
Change-Id: Id332f6dc3e0aaaab4ff94b810e4a5bf6b7e01874
This scenario came up while discussing what might be causing
leaked resource allocations in Placement [1].
I fully expected the new test to fail because I couldn't see
from the compute manager where the migration-based allocations
would be cleaned up when deleting the server. It turns out that
when deleting a VERIFY_RESIZE server, the API confirms the resize
which drops the migration-based allocations on the source node
before deleting the server on the target node.
Since this is not obvious, a comment in the compute API
_confirm_resize_on_deleting() method is added.
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136295.html
Change-Id: I4c12502c86c7ac27369d119e0f97768cf41695b5
Via change [1], ironicclient began to use endpoint_filter in the
version negotiation code path, whereas it was previously unused if a
fully-qualified endpoint had already been determined. Suddenly it was
important that the `interface` part of this endpoint_filter be correct.
Prior to ironicclient change [2], there was no way to pass an
appropriate `interface` value through ironicclient's initialization, so
the ironicclient used from nova would always end up with the default
value, `public`, in the endpoint_filter. This would break in clouds
lacking a public ironic API endpoint (see the referenced bug).
With this change, we pass the value of the (standard, per ksa)
`valid_interfaces` ironic config option into the ironicclient
initialization, where (if and only if the ironicclient fix [2] is also
present) it eventually gets passed through to the ksa Adapter
initialization (which is set up to accept values from exactly that conf
option) to wind up in the endpoint_filter.
The effect is that nova's ironicclient will actually be using the
interface from nova.conf throughout. (Because `valid_interfaces` is also
used in recommended configuration setups - i.e. those that use the
service catalog to determine API endpoints - to construct the
endpoint_override used to initialize the ironicclient, the value used
during version negotiation should be in sync with that used for regular
API calls.)
[1] I42b66daea1f4397273a3f4eb1638abafb3bb28ce
[2] I610836e5038774621690aca88b2aee25670f0262
Change-Id: I5f78d21c39ed2fd58d2a0f3649116e39883d5a2c
closes-bug: 1818295
This utime call sometimes fails, with EACCES (Permission Denied), when
the base file is on an NFS client filesystem. I don't understand why,
but wonder if it's a similar problem as the one that motivated using
touch instead of utime in ec9d5e375e. In any case, IIUC, timing
isn't the primary thing that the image cache manager uses to determine
when the base file is in use. The primary mechanism for that is
whether there is a matching disk file for a current instance. The
timestamp on the base file is only used when deciding whether to
delete a base file that is _not_ in use; so it is not a big deal if
that deletion happens slightly earlier, for an unused base file,
because of one of these preceding utime calls having failed.
Closes-Bug: #1809123
Co-Authored-By: Matthew Booth <mbooth@redhat.com>
Change-Id: Idc131ff426f1707150867030fa5a69b77a7fc832
During port detach the unbind towards neutron happens before the
port allocation is removed from placement. The functional test only
waited for the port unbind before asserted the remaining allocations and
therefore it was racy.
Fortunately the instance.interface_detach.end is emitted after the both
the unbind and the allocation shrink. So the test is changed to wait for
this notification instead.
Change-Id: I53d76d6353ae634e387672e14943f518955b221e
Closes-Bug: #1819374
melanie witt