can we wait for #3414?

can we wait for #3414?

OK!

coverage: 63.673%. remained the same
when pulling 45ade0d on shiftstack:prepare_v2.8.0
into 6332fe9 on gophercloud:v2.

and this... #3424

and this #3425

Sure you don't want to leave something for v2.9? 😅

Sure you don't want to leave something for v2.9?

I'd like to see main branch problems fixed for successful backports :)

@kayrus Are we still waiting for any backports?

yes, see:
#3462
#3454
#3447
#3424

UPD:

Additionally, several colleagues have experienced issues with the new endpoint discovery logic introduced in 2.7.0. This logic relies solely on the keystone service catalog order, which causes problems when multiple endpoints are available in the catalog.
The current workaround is to override the list of aliases (which are globally modifiable). There have also been multiple related reports in the Terraform OpenStack provider:

• [manila] [tests] dalmatian release doesn't respect client microversion terraform-provider-openstack/terraform-provider-openstack#1847
• Extending a volume fails since 3.1.0 terraform-provider-openstack/terraform-provider-openstack#1929
• Share objects plan failure from version 3.1.0 terraform-provider-openstack/terraform-provider-openstack#1930

To provide a quick fix, I implemented a workaround here: terraform-provider-openstack/utils#1. The endpoint discovery issue should be resolved with #3435. However, fetching microversions during each service client creation seems excessive and introduces unnecessary API calls, particularly for SDK consumers like the Terraform provider. See the detailed description: #3435 (comment).

The big endpoint discovery change merged in v2 and the CI is as happy as it can be today. It's time to cut v2.8.0.