Skip to content

Port: add binding profile field #622

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
winiciusallan wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Port: add binding profile field #622

winiciusallan wants to merge 2 commits into from
+380 −3

Conversation

@winiciusallan
Copy link
Contributor

@winiciusallan winiciusallan commented Dec 30, 2025 •
edited
Loading

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
port: add binding profile to the port controller
c8d87a4 
Signed-off-by: Winicius Silva <winiciusab12@gmail.com>
@winiciusallan
CI: add additional neutron policy
545b013 
To test properly the binding:profile field, we need to override the
default policies to allow stack user to create and update it.

The warning section here[1] on docs discuss better.

[1] https://docs.openstack.org/api-ref/network/v2/index.html#port-binding-extended-attributes

Signed-off-by: Winicius Silva <winiciusab12@gmail.com>
@winiciusallan winiciusallan mentioned this pull request Dec 30, 2025
Open
6 tasks
@github-actions github-actions bot added the semver:minor Backwards-compatible change label Dec 30, 2025
@winiciusallan
Copy link
Contributor Author

winiciusallan commented Dec 31, 2025

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.

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

Reviewers

No reviews

Assignees

No one assigned

Labels

semver:minor Backwards-compatible change

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@winiciusallan