Format nit: Please remove the blank line on line 184.

Can you also add a comment to note which microversion introduced this field? As an exmaple:

@jtopjian thanks, fixed it.

Honestly, half of these fields were introduced in a microversion. Somebody should go through https://docs.openstack.org/ironic/latest/contributor/webapi-version-history.html and add these eventually.

I'd like to use this comment to (once again) express his disagreement with how gophercloud handles microversions. They have to be set automatically, not like this:

client.Microversion = "1.47"

Honestly, half of these fields were introduced in a microversion. Somebody should go through https://docs.openstack.org/ironic/latest/contributor/webapi-version-history.html and add these eventually.

I can try to work on this, but can't tell the exact date right now.

Only if you have spare cycles to spend. Otherwise I'll probably get to it (no ETA as well).

I'd like to use this comment to (once again) express his disagreement with how gophercloud handles microversions. They have to be set automatically, not like this:

I would be more than happy to discuss a change in implementation. In fact, I'd appreciate the help.

Not sure which venue we should use, but the vision of microversions by the OpenStack API SIG is that the microversions should not be exposed to consumers of all but the most basic and low-level SDKs. Back at the times I wrote https://specs.openstack.org/openstack/api-sig/guidelines/sdk-exposing-microversions.html.

Let's take this patch as an example. If client.Microversion is empty, we provide the minimum microversion we support. But if automated_clean is not nil, we understand that this request can only be executed with API version 1.47 and automatically use it (consumers can still override with by setting client.Microversion explicitly).

When retrieving anything, the situation is a bit more interesting. You need to figure out the maximum version that both the server and gophercloud understand. In openstacksdk, for example, we set the latter per resource: https://github.com/openstack/openstacksdk/blob/master/openstack/baremetal/v1/node.py#L95. This procedure allows exposing maximum fields without the users guessing the right microversion. Instead they can rely on the fact that e.g. automated_clean is not nil.

I hope it all makes sense, I'm open to a more detailed/broad conversation since microversions happened to be more specialization (even though I personally dislike them :) )

Thank you for the reply - it's very helpful.

Not sure which venue we should use

If there's substantial discussion that won't be resolved in a few comments, then a new Issue would be best.

It sounds like there isn't a problem with the technical details of getting microversions to work. To be honest, that's my biggest priority/concern.

I understand the implementation you've described and I agree with it.

Gophercloud attempts to be, basically, one step above raw HTTP requests. It doesn't try to do anything intelligent unless it's absolutely needed. There isn't a technical reason for this or even an ideological reason. It's really just an issue of available hands and eyes to work on Gophercloud. The amount of volunteer effort available right now is just enough for "one step above raw HTTP requests" and an occasional feature at https://github.com/gophercloud/utils. It'd be awesome if Gophercloud had feature parity with openstacksdk, but it's not possible unless more people work on it regularly.

Again, I do agree with the implementation you described, but it would take a good amount of work. It would take more effort to also make sure Gophercloud fully supported a microversion to the point where I'd feel comfortable tagging a certain Gophercloud release with an officially supported microversion (the concern largely comes from making sure all OpenStack projects/services within Gophercloud have this level of support and one service doesn't get preferential treatment).

This is why anything "two steps" above a raw HTTP requests is punted up the stack. I don't like doing it, but it's better than 2-3 years ago when microversioned features were blocked entirely while trying to figure out a clean solution. If someone would argue that not doing it the ideal way is worse than no support at all, I wouldn't disagree with them, but I'd ask them to field the feature requests that come in :)

Yeah, I realize I'm giving the "not enough time" excuse. But if people began submitting patches to change how Gophercloud works with microversions, I would absolutely be open to merging them.

Gophercloud had feature parity with openstacksdk, but it's not possible unless more people work on it regularly

Sigh, don't get me started on how many people work full time on openstacksdk (zero)..

I realize I'm giving the "not enough time" excuse

And I understand you very well! Where is my human cloning machine?

Gophercloud attempts to be, basically, one step above raw HTTP requests

There is one problem though: microversions are supposed to be set per request, not per client. It seems that Gophercloud does the latter though. A low-level SDK should do the former. Not sure how ugly it will make the API though. In rust-osauth I ended up with an explicit argument: https://docs.rs/osauth/0.3.4/osauth/struct.Session.html#method.request (but rust-osauth is actually one stop closer to the wire).

microversions are supposed to be set per request, not per client. It seems that Gophercloud does the latter though

I can't speak for everything that has used Gophercloud+microversions, so it's best to assume that there are cases where this is being done.

However, it's possible to do it on a per-request basis above Gophercloud right now. This is how it's been implemented in Terraform. Some examples are:

• https://github.com/terraform-provider-openstack/terraform-provider-openstack/blob/53f886ad12a1abcce778d535b101a91d06911a7c/openstack/resource_openstack_sharedfilesystem_share_access_v2.go#L88-L94
• https://github.com/terraform-provider-openstack/terraform-provider-openstack/blob/53f886ad12a1abcce778d535b101a91d06911a7c/openstack/resource_openstack_sharedfilesystem_share_access_v2.go#L153-L170
• https://github.com/terraform-provider-openstack/terraform-provider-openstack/blob/b1f4529d38c42062b39a43e006d728d7a890945e/openstack/resource_openstack_lb_quota_v2.go#L114-L124

These examples could be tightened up to where the microversion is reverted after the individual request, but Terraform's Create, Read, Update, and Delete functions can be thought of as a single request to perform one action.

I do understand that the logic being done in Terraform should be done in Gophercloud. Again, if someone proposed a way to redesign and enable this, I'm open to merging it.

All API calls in Gophercloud have the ability add additional headers, so it should be possible to tuck all of this logic away from the user. For example: