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
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
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
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
Add a gabbi test case demonstrating that the consumer with UUID
{8}-{4}-{4}-{4}-{12} is not the same as the consumer with UUID
{8}{4}{4}{4}{12}.
Change-Id: I1852ac6004fedc5dfa9dd3de187c937ab385d1b5
Related-Bug: #1758057
Bump the minimum version of oslo.config to 6.1.0, which adds proper
support for parsing Opt.help as rST [1]. This in turn allows us to
revert commit 75fc300901, which is a
temporary fix relying on deprecated features of Sphinx.
[1] https://review.openstack.org/#/c/553860/
Change-Id: I8f56bdce37cfc538348490052a24e463164c86a3
A pending api-sig guideline
I473918ce9c6b49c0b904e93b7140421525f4e7c0 reflects discussion amongst
various parties that adding error codes to structured error responses
should not be considered a breaking API change.
Given that, it is simply "okay" to add them. This change adds
errors.CONCURRENT_UPDATE wherever the ConcurrentUpdateDetected results
in an HTTPConflict (409) response.
In practice this means that if microversion 1.23 or beyond is being
used, there will be a code in any error response, and for some
409 responses that code will be `placement.concurrent_update`.
Note that because we haven't instrumented a way to cause a truly
concurrent update, we've never had real tests for this kind of
thing.
Change-Id: I5a164a0ee298846231113ad7b62b82a3e8f1f409
The CachingScheduler doesn't create allocations in
placement so when prep_resize fails and it tries
to revert allocations, the _revert_allocation() method
returns False and then prep_resize calls
delete_allocation_for_failed_resize() which since change
I7891b98f225f97ad47f189afb9110ef31c810717 has taken a
context argument, but that's not being passed so it
results in a TypeError.
This fixes the TypeError and adds a functional test case
which runs a resize reschedule scenario with the
CachingScheduler.
Change-Id: I0ec0c2d3f7ef8d2274b97a28a175d53921edc9db
Closes-Bug: #1781100
This change provides a small number of updates to the placement user and
contributor documentation to reflect some of the things that have
changed recently. This is by no means complete, but is an improvement
over what was there.
Partial-Bug: #1778227
Change-Id: Ia348cd3c99b1a5104e15595fdebc83e1ca582a98
Gábor Antal