Skip to content

Conversation

@bnallapeta
Copy link
Contributor

What this PR does / why we need it:
Proposal doc for #2861

/hold

Signed-off-by: Bharath Nallapeta <nr.bharath97@gmail.com>
@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 26, 2025
@netlify
Copy link

netlify bot commented Nov 26, 2025

Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!

Name Link
🔨 Latest commit 83fc91f
🔍 Latest deploy log https://app.netlify.com/projects/kubernetes-sigs-cluster-api-openstack/deploys/6926c48deb91d7000758c60d
😎 Deploy Preview https://deploy-preview-2862--kubernetes-sigs-cluster-api-openstack.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign lentzi90 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Nov 26, 2025
@bnallapeta
Copy link
Contributor Author

/cc @lentzi90

@bnallapeta
Copy link
Contributor Author

@lentzi90 do you have some time to take a look at this?

Copy link
Contributor

@smoshiur1237 smoshiur1237 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments regarding formatting of md files. I was getting the following minor issues in the docs . It will improve the md file formatting .

- Maintain backward compatibility with existing port configurations
- Follow OpenStack Networking (Neutron) trunk API patterns

### Non-Goals
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need one empty line after the title


## Motivation

### Goals
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need one empty line after the title


### User Stories

#### Story 1: NFV Workloads
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need one empty line after the title

#### Story 1: NFV Workloads
As a user deploying Network Function Virtualization (NFV) workloads, I need to attach my VM to multiple VLANs through a single trunk interface to separate control plane and data plane traffic without consuming multiple physical interfaces or PCI slots.

#### Story 2: Multi-Tenant Networking
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need one empty line after the title

```go
type PortOpts struct {
// ... existing fields ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove the empty line

Comment on lines +81 to +86
1. **`EnsureTrunkSubPorts` Method**:
- Iterates through the desired ports.
- If `trunk: true` is set, it checks for `Subports`.
- For each subport:
- Creates a regular Neutron port using `CommonPortOpts`.
- Adds the port as a subport to the parent trunk using the `AddSubports` API, specifying the `SegmentationID` and `SegmentationType`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you have used space 4. please use space 2

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far we have not used so strict formatting in CAPO. I think we need to discuss this first and agree on a style. Maybe also go through older docs and reformat them so we can actually enforce the style. Otherwise it will just be inconsistent.

Comment on lines +107 to +112
- **Manual Configuration**: Users could manually create trunks and subports using the OpenStack CLI and reference them by ID.
- *Pros*: No code changes in CAPO.
- *Cons*: Breaks the "Infrastructure as Code" model; manual steps are error-prone and hard to automate in CAPI workflows.
- **Separate CRD**: Introduce a new CRD for Trunks/Subports.
- *Pros*: Decouples networking from Machine.
- *Cons*: Increases API surface area and complexity for common use cases. Embedding in `OpenStackMachine` is more ergonomic for the 90% case.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please confirm with space 2. In my editor it is showing space 4

Copy link
Contributor

@lentzi90 lentzi90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay!
I don't have any immediate concerns. It looks like a useful feature.
However, I think we should coordinate this with ORC so we don't end up making things unnecessarily painful later.
There is already a Port resource in ORC, but I don't think it has Trunk support yet.

@mandre could you check this? Do you see any issues with this if we later want to adopt ORC Ports? Would it be better to go for a separate CRD (perhaps implemented in ORC)?

/cc @mandre

Comment on lines +81 to +86
1. **`EnsureTrunkSubPorts` Method**:
- Iterates through the desired ports.
- If `trunk: true` is set, it checks for `Subports`.
- For each subport:
- Creates a regular Neutron port using `CommonPortOpts`.
- Adds the port as a subport to the parent trunk using the `AddSubports` API, specifying the `SegmentationID` and `SegmentationType`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far we have not used so strict formatting in CAPO. I think we need to discuss this first and agree on a style. Maybe also go through older docs and reformat them so we can actually enforce the style. Otherwise it will just be inconsistent.


2. **Lifecycle Management**:
- Subports are created after the parent port and trunk are created.
- Deletion of the `OpenStackMachine` will naturally clean up the ports, but explicit cleanup logic for trunks and subports ensures no orphaned resources.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unclear to me. Do we need to clean up or will it happen automatically? If it happens automatically, why would manual cleaning ensure no orphaned resources? Wouldn't that be ensured anyway?

@k8s-ci-robot k8s-ci-robot requested a review from mandre December 18, 2025 07:39
@winiciusallan
Copy link

Sorry for the delay! I don't have any immediate concerns. It looks like a useful feature. However, I think we should coordinate this with ORC so we don't end up making things unnecessarily painful later. There is already a Port resource in ORC, but I don't think it has Trunk support yet.

Hi @lentzi90! ORC already has a work still in progress to add a new Trunk controller on this PR. Since it is still in progress, I believe it can be aligned with CAPO interests.

(sorry for meddling)

@bnallapeta
Copy link
Contributor Author

@winiciusallan Thanks for the info. I checked out the current ongoing work on Trunk controller. While it implements the feature I have proposed here, the approach is totally different, but I guess that's a bigger question about the design itself (multiple, individual custom resources (Port, Trunk, Machine)).

@lentzi90 @mandre I see two paths moving forward here.

  • We wait for the work to be completed in ORC and plan for migrating it to CAPO. Although, that isn't just about this feature but rather about the entire networking feature. That's gonna be a big one.
  • I could do this feature right now in CAPO, but I don't want it to be a wasted effort in a couple months or so since we plan to migrate to ORC anyways. In that case, the whole approach changes and this proposal would not make much sense.

Thoughts? I am inclined towards letting this go at this point and plan for the bigger migration work. Please let me know.

@lentzi90
Copy link
Contributor

The first option sounds good to me, as long as you can wait for it.
I'll try to get some time early next year to help with the planning for how to migrate to use more of ORC 🤞

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

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

5 participants