Skip to content

ValueSpecs in port CreateOpts is a no-op #2870

Closed

Description

@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 it1, 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/[email protected]/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. ↩

Activity

  1. lentzi90 commented on Jan 18, 2024

    @lentzi90
    Contributor

    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

  2. winiciusallan commented on Feb 9, 2026

    @winiciusallan
    Contributor

    Hi @lentzi90, it's been a long time since the last discussion, but do you remember if there is a use case for this field by chance? I'm about to implement it on the Port resource in the ORC side, but I want to make sure that this field is not outdated. (This may be an opportunity to raise the discussion to deprecate the field on Gophercloud side)

    Could you please provide feedback on this?

  3. lentzi90 commented on Feb 10, 2026

    @lentzi90
    Contributor

    Hi! There are use-cases for this field. I do not know the exact details, but if I recall correctly there was a demand that things must work the same way as with Heat. ValueSpecs worked with Heat and so we needed to support them also in CAPO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions