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
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
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
This just links to the osc-placement plugin docs
for managing required and forbidden traits in the
flavor extra specs docs.
Change-Id: I8549dc404a62a05d327a2c7a4813e7cc505d6b06
Update the conductor to handle rebuilding of an instance. If a rebuild
is requested with an image with traits, we check the current allocations
of the instance against the image required traits and allow the action
only if the current allocations can satisfy the image requirements.
Change-Id: Ie49d605c66062d2548241d7e04f5a2a6b98c011e
Implements: blueprint glance-image-traits
To solve the race condition problem, we do anti-affinity policy
sanity check in the instance build code of compute manager, but
this check is only valid in original policy.
Specifically, this change adds validation of the new
max_server_per_host policy rule which can be used to allow >1
anti-affinity group member on the same host.
blueprint: complex-anti-affinity-policies
Change-Id: I755b6fdddc9d754326cd9c81b6880581641f73e8
In this patch, the anti-affinity filter will get the
max_server_per_host limit from policy rules, and compare it
against the number of servers within the same group on a given
host. If the filter finds the number is not satisfied with the
limit, it will filter out this host.
The default ``max_server_per_host`` for the anti-affinity filter
is 1 for backward compatibility.
Change-Id: I4b67ec9dd4ce846a704d0f75ad64c41e693de0fb
blueprint: complex-anti-affinity-policies
In this patch, the ServerGroupPayload is updated to include
the new ``policy`` field; the ``policies`` field is deprecated
for removal but still put into the notification payload for
backward compatibility.
Related to blueprint complex-anti-affinity-policies
Change-Id: Ie739ee8dec4685cd70e735ff83f7f30bc7e95a57
The change items in this patch as below:
1. Add policy and rules to InstanceGroup, deprecate
the policies field.
2. Also, make _from_db_object and _create_in_db method to
support new "policy" field.
The internal usage of InstanceGroup.policies is converted to
use the new model in the REST API and RequestSpec compat code.
Related to blueprint complex-anti-affinity-policies
Change-Id: Ib33719a4b9599d86848c618a6e142c71ece79ca5
Zuul