Port: add binding profile field

[winiciusallan]

This PR adds the binding:profile field to the Port controller.

• Part of the implementation was inspired by the already implemented controller on CAPO.
• The profile field on the port API is originally a free-form dict, but I decided to not expose in that way to only support the Neutron values.
• I also added a change on e2e action, because we need to override the default neutron policy so we can create and update ports with profile, since it is allowed by "services users" by default.

Partial: #616

[winiciusallan]

There is a difference between this implementation and the implemented on CAPO - I have used the capabilities field instead of a boolean value that indicates whether OVS hardware offload must be enabled or not. I believe that the latest avoid user error, but the first uses exactly what Openstack returns to us.

Wdty? cc. @mandre

Also, I'm spending some time configuring an environment to test the changes to the CI that I made before running again.

[mandre]

I wonder if we really want to add binding profile. Neutron recently changed their policy to restrict this API to service accounts via https://review.opendev.org/c/openstack/neutron/+/909075 as we're not supposed to use this API directly.

CAPO needs to be updated: kubernetes-sigs/cluster-api-provider-openstack#2172

[winiciusallan]

Oh,thanks, I didn't know of this change on upstream. But yeah, the docs says it mustn't be used for end users

This field is only meant for machine-machine communication for compute services like Nova, Ironic or Zun to pass information to a Neutron back-end. It should not be used by multiple services concurrently or by cloud end users.

When implementing I was wondering too what was the use case for supporting this. @lentzi90, do you have any idea if this is strictly necessary?

[lentzi90]

When implementing I was wondering too what was the use case for supporting this. @lentzi90, do you have any idea if this is strictly necessary?

I must confess I don't have a clue. It could even be something that was implemented for CI convenience. I remember cleaning up a few places where we used to rely on OpenStack admin credentials in the e2e tests.

[winiciusallan]

I must confess I don't have a clue. It could even be something that was implemented for CI convenience. I remember cleaning up a few places where we used to rely on OpenStack admin credentials in the e2e tests.

Ok, got it. Thanks. So, I'll move forward to close this pull request and create another one that adds the port_trusted_vif extension as added here[1] in upstream.

I believe we won't want an incompatible API and expose a non-supported field for the end users.

[1] https://review.opendev.org/c/openstack/neutron/+/926068

[winiciusallan]

It seems that we will need to add this extension to gophercloud first, I have created this issue for tracking.