Parity with python client for version variables?

[lentzi90]

I have a use case for setting the compute API version in clouds.yaml and/or thought the env variable COMPUTE_API_VERSION, but only identity and volume API versions are currently available. It is however, available in python.

After some more research on this, there seems to be more missing in gophercloud than just the compute API version. Would it be acceptable to bring it into parity with the python client? These are the variables that can be used with the python client but are ignored by gophercloud from what I can tell:

export OS_BAREMETAL_API_VERSION
export OS_COMPUTE_API_VERSION
export OS_IMAGE_API_VERSION
export OS_NETWORK_API_VERSION
export OS_ORCHESTRATION_API_VERSION
export OS_IRONIC_API_VERSION
export OS_PLACEMENT_API_VERSION

Would it be possible to add the compute API version here as well? I would be happy to work on a PR!

Edit: Edited to expand from just comput API version to bring the clientconfig up to parity with the python client.

I'm not well versed in the OpenStack SDK, but I have managed to dig up some hopefully relevant code.
Link to OpenStackSDK files:

• https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/config/loader.py
• https://opendev.org/openstack/openstacksdk/src/commit/ef7b73f0cec36df6b2071b2689c17aba277c9701/openstack/tests/unit/test_microversions.py
• https://opendev.org/openstack/openstacksdk/src/commit/ef7b73f0cec36df6b2071b2689c17aba277c9701/openstack/config/cloud_region.py#L451
• https://opendev.org/openstack/openstacksdk/src/commit/ef7b73f0cec36df6b2071b2689c17aba277c9701/openstack/tests/unit/config/test_cloud_config.py
• https://opendev.org/openstack/openstacksdk/src/commit/ef7b73f0cec36df6b2071b2689c17aba277c9701/doc/source/user/microversions.rst?display=source#L23-L25

[pierreprinetti]

I believe that Utils currently supports setting versions through clouds.yaml, and not microversions. The difference for us is that versions determine a different behaviour client-side, while microversions are just passed up to OpenStack (example: older microversions of Nova accept server groups "policies", newer just "policy". Gophercloud delegates the issue to the consumer and expects them to set the microversion accordingly).

As a consequence we may just parse the microversion variable, if any, and insert it into the gophercloud.ServiceClient. This could happen right into clientconfig.NewServiceClient.

Is that what you had in mind?

[lentzi90]

I'm a bit confused about the distinction still, but the goal is to be able to set the OS_*_API_VERSION variables (either in clouds.yaml or environment) and have them respected. From what I can tell they would need to be listed in here.

[lentzi90]

Ok after some more digging I have a better understanding of this now.
The goal for me would be to be able to set the API versions in clouds.yaml that I pass to Cluster API provider OpenStack. Since CAPO relies on gophercloud for the communication with the OpenStack API I assumed it would make sense to detect what versions to use on the gophercloud side. Basically what would be needed is to check for all the OS_*_API_VERSION variables in environment, clouds.yaml and flags, and then set the relevant microversion (if any). Similar to how the versions are already handled.

However, I see now that in the docs for microversions it is expected that the client sets these versions. So essentially it would be the job of CAPO to detect and set them. I do see the logic in letting the client provide some "defaults" or overrides (e.g. CAPO has a minimum required nova microversion). However, I think it would make sense to also automatically detect and use any microversions set through environment variables, clouds.yaml or flags, and doing that in gophercloud makes more sense than each client doing it separately.

So essentially what I would like to do is change

utils/openstack/clientconfig/requests.go

Lines 880 to 881 in e8fba78

	case "compute":
	return openstack.NewComputeV2(pClient, eo)

into something like

	case "compute":
                client, err := openstack.NewComputeV2(pClient, eo)
                client.Microversion = detectComputeMicroversion(cloud)
		return client, err

(But obviously with a nicer implementation.)

Does it make sense?

[pierreprinetti]

I think that what you propose makes complete sense, especially here in utils where we don't have backwards-compatibility constraints.

[pierreprinetti]

Consistently with what we do when adding API calls, please include pointers to the Python SDK code to justify any microversion parsing in clouds.yaml.

[lentzi90]

Thanks @pierreprinetti ! I have updated the description with some links that I think show that the python SDK is parsing the clouds.yaml. I will start working on a draft PR and see if I can make sense of this 🙂