Change-Id: I054aca28ecb753e624a9e0a04f1cb76fb1e5806a
Signed-off-by: OpenStack Release Bot <infra-root@openstack.org>
Generated-By: openstack/project-config:roles/copy-release-tools-scripts/files/release-tools/functions

Update the URL to the upper-constraints file to point to the redirect
rule on releases.openstack.org so that anyone working on this branch
will switch to the correct upper-constraints list automatically when
the requirements repository branches.

Until the requirements repository has as stable/2025.2 branch, tests will
continue to use the upper-constraints list on master.

Change-Id: Ia0ae5340687eac3d2dc6d050a40c4c02e80279ed
Signed-off-by: OpenStack Release Bot <infra-root@openstack.org>
Generated-By: openstack/project-config:roles/copy-release-tools-scripts/files/release-tools/functions

Added support for the 'vendor' and 'category' fields for the port
object.

Change-Id: Id2ec4308b1ab4c9fba538c811af52b32206730f8
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
(cherry picked from commit 924107b)

This check determines the maximum API version that the client can use.
There is no way for the user to override this maximum value. The current
API that the client is pinned to is 1.96 but this was the Ironic API for
2025.1. The API for 2025.2 was 1.101. This means that the client
released for 2025.2 cannot use any of the API features released with
2025.2 unless this value is changed. The 2025.2 client code includes
support for changes up to 1.101 but is unable to do so. The change to
the test is for confirming the API clamping behavior of the client. The
mock server reported that it supported 1.1 through 1.99. The test
requests the maximum version the client supports and then confirms that
the server accepted the client's maximum. By changing the client to
1.101 the test fails when the mock server returns back 1.99. The
original value of 1.99 was selected many years ago and deemed to be
'very large' but has now proven not large enough.

Change-Id: I2d242d64f03e8252d6f6d8c713430c654e6059ad
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

If two parallel greenthreads use the same, uninitialized client, there's
a race-condition when both enter `negotiate_version()`: there is a
request made to Ironic, which hands over execution to the other
greenthread. The first greenthread returning from the request changes
the state of the client and the second one reads the updated state and
thus thinks it's in an error-handling call instead of the initial
negotiation - and errors out.

We fix this by adding a lock around the initial call to
`negotiate_version()`.

Change-Id: I9ec03d2bc34017c7670fd6903e5353a8c91e9f17
Closes-Bug: #2119323
Signed-off-by: Johannes Kulik <johannes.kulik@sap.com>
(cherry picked from commit ad1291c)