Skip to content
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.

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

Adding the support of Linux bridge interface for VM setup #158

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

Conversation

capolrik
Copy link
Collaborator

@capolrik capolrik commented Nov 14, 2024

Use the --bridge option to create a NAD that will be attached to the VMs

Type of change

  • New feature

Description

Adding the support for bridge interface using VMs.
A NNCP needs to be defined before running the test to defined the linux bridge.
Then, the bridge name should be passed to the option:

k8s-netperf --debug --vm --bridge br0

with the following NNCP (nmstate operator required)

apiVersion: nmstate.io/v1alpha1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br0-eth1
spec:
  desiredState:
    interfaces:
      - name: br0
        description: Linux bridge with eno2 as a port
        type: linux-bridge
        state: up
        ipv4:
          dhcp: true
          enabled: true
        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: eno2

Related Tickets & Documents

Checklist before requesting a review

  • I have performed a self-review of my code.
  • If it is a core feature, I have added thorough tests.

Testing

On OCP 4.17, 4.18.0.rc

k8s-netperf --debug --vm --bridge br0

and

k8s-netperf --debug --vm

@capolrik capolrik marked this pull request as ready for review November 20, 2024 10:33
@capolrik
Copy link
Collaborator Author

@jtaleric @rsevilla87 this change has been tested on 4.17 and 4.18 and is stable, it is ready for review.

netData = `version: 2
ethernets:
eth1:
addresses: [ 10.10.10.12/24 ]`
Copy link
Member

Choose a reason for hiding this comment

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

my only concern here is if a user needs to override this -- if they already have a 10.10.10/24 network defined. I am OK with a default, but should we allow the user to override the interface IP in the event they already use a 10net?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is a legitimate concern, I have added a little logic to handle this by passing an optional ipv4 network parameter but I don't have a cluster to test this for now. It will wait until next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants