The ServerMigrationSampleJsonTestsV2_24 functional tests set up
``self.api.microversion`` to 2.24 in its' setUp(), by doing this
it will not need to add its' own sample files, as there will be
no difference anyway. But this makes Tests that inherent from this
test class impossibe to run as the microversion will always been
overriden.
This patch fix it by change the tests to use self.microversion and
adds its' own sample files.
Part of blueprint abort-live-migration-in-queued-status
Change-Id: I07222efb8d566fa1dd395ef948eae6e6c4b13678
This patch modified compute manager and bumps the
nova-compute service version to be able to abort
live migration in ``queued`` and ``preparing`` status.
The following patch will modify the API part.
Part of blueprint abort-live-migration-in-queued-status
Change-Id: I3689dd6544c387676983be47cf925c3fd7ce72f1
This changes the max_concurrent_live_migrations handling
to use a ThreadPoolExecutor so that we can control a bounded
pool of Futures in order to cancel queued live migrations
later in this series.
There is a slight functional difference in the unlimited
case since starting in python 3.5, ThreadPoolExecutor will
default to ncpu * 5 concurrently running threads. However,
max_concurrent_live_migrations defaults to 1 and assuming
compute hosts run with 32 physical CPUs on average, you'd
be looking at a maximum of 160 concurrently running live
migrations, which is probably way above what anyone would
consider sane.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Part of blueprint abort-live-migration-in-queued-status
Change-Id: Ia9ea1e164fb3b4a386405538eed58d94ad115172
Change I4b67ec9dd4ce846a704d0f75ad64c41e693de0fb changed the
behavior of the ServerGroupAntiAffinityFilter to rely on
HostState.instances being accurate within the same request
so that it can compare the number of group members on the same
host for filtering. Previously the filter was just checking
InstanceGroup.hosts which was updated in the
FilterScheduler._consume_selected_host method for each instance
processed in a multi-create request.
This change updates _consume_selected_host such that if we have
an instance group and an instance_uuid (which should always be
the case unless conductor is running code older than Pike), then
we update HostState.instances with the instance_uuid so the
ServerGroupAntiAffinityFilter can properly compare the number of
group members against the instances on a given host in a multi-create
request.
Change-Id: Iacc636fa8a59a9e8670a8d683c10bdbb0dc8237b
Closes-Bug: #1781710
The code to generate a support matrix has been pulled into a common
library. Using this instead of duplicating code in various projects that
need it.
Change-Id: If5c0bf2b0dcd7dbb7d316139ecb62a936fd15439
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
When an allocation is created with PUT /allocations/{consumer_uuid} the
consumer_uuid is not validated as UUID in the API and the DB schema only
checks that is fits into String(36). However the Consumer object stores
this value in a UUIDField oslo only raises a warning today.
This patch adds a UUID validation for that URL path.
Change-Id: Idedd85ca9266f10ce09231c34cab7ca43029a56c
Closes-Bug: #1780238
we already passed Pike cycle and should require compute to have
Pike+ version, the backport to Ocata can be removed.
Change-Id: I39d93dbf8552605e34b9f146e3613e6af62a1774
This patch add snapshot function to z/VM driver, it will call
underlying zvmsdk to generate the image
Change-Id: I0409aba55487e92efa6370eed41936bf8a4ef25d
blueprint: add-zvm-driver-rocky
It includes two main function, Spawn is used to deploy an
instance on the z/VM, and destroy is used to delete the instance
Change-Id: Ie3db769c5e62353b2fa39c1a7e1f025171ff4a4a
blueprint: add-zvm-driver-rocky
This is the first change that implements basic virt.driver methods
to allow nova-compute process start successfully.
A set of subsequent changes will implement spawn, snapshot, destroy
and instance power actions.
Change-Id: Ica6117c2c64f7518b78b7fb02487622250638e88
blueprint: add-zvm-driver-rocky
The instance.live_migration_force_complete.start and
instance.live_migration_force_complete.end notifications have been
transformed to the versioned notification framework.
Co-Authored-By: Takashi Natsume <natsume.takashi@lab.ntt.co.jp>
Change-Id: I2e9a474457a7597a9febc111b13a67ddcf45f29e
Implements: bp versioned-notification-transformation-rocky
The aggregate.update_prop.start and aggregate.update_prop.end
notifications has been transformed to the versioned notification
framework.
Co-Authored-By: Takashi Natsume <natsume.takashi@lab.ntt.co.jp>
Change-Id: I37b19573b6d0e1131c446fcec361f01fa2560f82
Implements: bp versioned-notification-transformation-rocky
If the compute service we're deleting has never been
discovered (mapped to a cell using discover_hosts) or the
host mapping was already deleted, we need to handle the
HostMappingNotFound error when deleting a compute service
so that we (1) don't 500 out of the API and (2) continue to
delete the compute service.
Change-Id: I0d7644db3537a67b94e75972b3c4fce25a623763
Closes-Bug: #1780727
This skips a couple more tempest rebuild tests for
latent intermittent rebuild race failures
due to status sync delays with cells v1.
Change-Id: Ib2dcbba7f447f54c36877a4e7c29d1b6839a0a80
Related-Bug: #1709985
Allocations created before microversion 1.8 didn't have project_id
/ user_id consumer information. In Rocky those will be migrated
to have consumer records, but using configurable sentinel values.
As part of heal_allocations, we can detect this and heal the
allocations using the instance.project_id/user_id information.
This is something we'd need if we ever use Placement allocation
information counting quotas.
Note that we should be using Placement API version 1.28 with
consumer_generation when updating the allocations, but since
people might backport this change the usage of consumer
generations is left for a follow up patch.
Related to blueprint add-consumer-generation
Change-Id: Idba40838b7b1d5389ab308f2ea40e28911aecffa
When trying to delete host that can be found in host_mappings
but not in compute_nodes, current cellv2 delete_host will throw
an exception but does not really handle it.
This patch tries to handle this exception and allow the delete
operation to continue since it shows the host has gone anyway.
Change-Id: I99bd79fb45777edc0e33d846ba478b0a94a1191e
Closes-Bug: #1781391
This patch adds logging when ironic doesn't support a required API
version for rescuing and unrescuing.
Change-Id: Ibabfc439e9d426aeabd54877a82e27f02f6ddb5a
Implements: blueprint ironic-rescue-mode
Enable users to define the policy rules on server group policy
to meet more advanced policy requirement. This microversion
brings the following changes in server group APIs:
* Add ``policy`` and ``rules`` fields in the request of POST
``/os-server-groups``.
* The ``policy`` and ``rules`` fields will be
returned in response body of POST, GET ``/os-server-groups``
API and GET ``/os-server-groups/{server_group_id}`` API.
* The ``policies`` and ``metadata`` fields have been removed
from the response body of POST, GET ``/os-server-groups`` API
and GET ``/os-server-groups/{server_group_id}`` API.
Part of blueprint: complex-anti-affinity-policies
Change-Id: I6911e97bd7f8df92511e90518dba21c127e106a5
For quite some time, the nova virt driver has invoked the ironic
python client library with a static microversion pin which causes
operators to have a failed nova-compute process upon out of order
upgrades, as well as causes ironic's grenade CI jobs to break every
cycle when the pin is changed to a version released in the current
cycle due to established community agreement as well as the grenade
testing framework limitations.
In order to gracefully navigate this, python-ironicclient has
accepted a list of possible versions to negotiate since 2.2.0.
This patch provies a mechanism to validate if we are able to
send a request that was added at a specific version, allowing for
minimal code changes and for logic to only be centered around newer
features being added.
Change-Id: I440689a246538fbc8200687e40480d837b87eb7b
Closes-Bug: #1739440
Ever since we introduced support for setting multiple consumers in a
single POST /allocations, the AllocationList.delete_all() method has
been housing a latent bad assumption and bug.
The AllocationList.delete_all() method used to assume that the
AllocationList's Allocation objects were only ever for a single
consumer, and took a shortcut in deleting the allocation by deleting all
allocations with the "first" Allocation's consumer UUID:
```python
def delete_all(self):
# Allocations can only have a single consumer, so take advantage of
# that fact and do an efficient batch delete
consumer_uuid = self.objects[0].consumer.uuid
_delete_allocations_for_consumer(self._context, consumer_uuid)
consumer_obj.delete_consumers_if_no_allocations(
self._context, [consumer_uuid])
```
The problem with the above is that if you get all the allocations for a
single resource provider, using
AllocationList.get_all_by_resource_provider() and there are more than
one consumer allocating resources against that provider, then calling
AllocationList.delete_all() will only delete *some* of the resource
provider's allocations, not all of them.
Luckily, the handler code has never used AllocationList.delete_all()
after calling AllocationList.get_all_by_resource_provider(), and so
we've not hit this latent bug in production.
However, in the next patch in this series (the reshaper DB work), we
*do* call AllocationList.delete_all() for allocation lists for each
provider involved in the reshape operation, which is why this fix is
important to get done correctly.
Note that this patch renames AllocationList.create_all() to
AllocationList.replace_all() to make it absolutely clear that all of
the allocations for all consumers in the list are first *deleted* by the
codebase and then re-created. We also remove the check in
AllocationList.create_all() that the Allocation objects in the list must
not have an 'id' field set. The reason for that is because in order to
properly implement AllocationList.delete_all() to call DELETE FROM
allocations WHERE id IN (<...>) we need the list of allocation record
internal IDs. These id field values are now properly set on the
Allocation objects when AllocationList.get_all_by_resource_provider()
and AllocationList.get_all_by_consumer_id() are called. This allows that
returned object to have delete_all() called on it and the DELETE
statement to work properly.
Change-Id: I12393b033054683bcc3e6f20da14e6243b4d5577
Closes-bug: #1781430
The docs currently name a past PTL by IRC nick -- update it to be
more generic so we don't have to update it every time the PTL
changes.
Change-Id: I31dbf0ee4f7650389e824c25c3aea7529d63eaa0
Kevin_Zheng