ValueSpecs in port CreateOpts is a no-op

[mdbooth]

I was reading #2537, which adds value_specs to ports. The doc link in the PR points to the Heat documentation, where it is a parameter. It is documented as:

Extra parameters to include in the request.

The gophercloud implementation includes a value_specs parameter in the port creation request. However, I couldn't find any evidence that neutron supports this parameter. Digging in to the implementation in Heat, I think the purpose of this field is to add arbitrary top-level fields to the request. i.e. There is no value_specs field.
I found some validation of value_specs which supports that:
https://github.com/openstack/heat/blob/2df46d4c59140255ece640896019bfca03437388/heat/engine/resources/openstack/neutron/neutron.py#L49-L62

Also, the only use of it I could find uses it in this way:
https://github.com/openstack/heat/blob/2df46d4c59140255ece640896019bfca03437388/heat/engine/resources/openstack/nova/server_network_mixin.py#L131-L133

I think we should re-examine the use case for this API. It is possible that it's required to support out-of-tree neutron drivers. If so, we should fix it to behave the same way as it does in Heat. However, it's clear that nobody is currently using it. This also opens an argument for removing it¹, especially as it's an unusual API backdoor.

I have a suspicion that it was just an escape-hatch in Heat so they didn't have to add every port parameter to Heat. I note that in Heat ports have binding:vnic_type, but not binding:(host_id|profile|vif_details|vif_type). Gophercloud does have these, though:
https://pkg.go.dev/github.com/gophercloud/gophercloud@v1.8.0/openstack/networking/v2/extensions/portsbinding. Is it possible this isn't required in gophercloud?

Footnotes

1. Or marking it deprecated with a note that it's a no-op, as API stability guarantees require. ↩

[lentzi90]

Thanks for clearing this up and creating the issue!
I will clarify internally if/how we use this and comeback with some suggested action in roughly a week