Skip to content

Allows non standard OVS setups #549

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
Merged
merged 1 commit into from
Apr 1, 2025
Merged

Allows non standard OVS setups #549

merged 1 commit into from
Apr 1, 2025

Conversation

@crypticC0der
Copy link
Contributor

Changes the checks to be based around the availability of the command line OVS tools instead of the availability of the service installed under apt. This allows netplan to consume OVS when it is provided as part of another package such as in snap environments.

This involves minor changes to lots of the OVS code and also modifies the unit tests as to handle OVS from both standard and nonstandard setups.

Checklist

  • Runs make check successfully.
  • Retains code coverage (make check-coverage).

@crypticC0der crypticC0der force-pushed the main branch 3 times, most recently from 7384837 to 4203d23 Compare March 25, 2025 12:33
@slyon slyon added community This PR has been proposed by somebody outside of the Netplan team and roadmap commitments. Canonical by Canonical employees outside the Netplan team labels Mar 26, 2025
@slyon slyon self-requested a review March 26, 2025 14:09
@slyon slyon mentioned this pull request Mar 26, 2025
Closed
2 tasks
slyon
slyon requested changes Mar 26, 2025
View reviewed changes
Copy link
Collaborator

@slyon slyon left a comment

Choose a reason for hiding this comment

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

Thank you for improving upon #425 !

We're failing some coverage- and integration-tests here. For system specific checks, such as location of binaries, feel free to exclude them from the coverage:

  • Python
    • #pragma: nocover
  • C
    • // LCOV_EXCL_START
    • // LCOV_EXCL_STOP

The approach of this PR is generally fine. It doesn't change major logic or architecture of Netplan, but only makes it more flexible to prefert /snap/bin/ovs-vsctl in favour of /usr/bin/ovs-vsctl if available.

I left a bunch of inline comments for your to look at.

@crypticC0der crypticC0der force-pushed the main branch 2 times, most recently from c239938 to e5d682b Compare March 27, 2025 14:50
slyon
slyon reviewed Mar 27, 2025
View reviewed changes
Copy link
Collaborator

@slyon slyon left a comment

Choose a reason for hiding this comment

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

Thanks this mostly LGTM! I left a few minor inline remarks. Can you please double-check those, before we merge it?

netplan_cli/cli/ovs.py
pass


def _ovs_vsctl_path(): # pragma: nocover
Copy link
Collaborator

Choose a reason for hiding this comment

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

note (non-blocking): This is specific to the installed system, so excluding it from the coverage is OK. Same for the other cases below.

@crypticC0der crypticC0der force-pushed the main branch 2 times, most recently from eecc0c4 to edefde0 Compare March 28, 2025 16:45
@crypticC0der
Allows non standard OVS setups
e292c13 
Changes the checks to be based around the availability of the command
line OVS tools instead of the availability of the service installed
under apt. This allows netplan to consume OVS when it is provided as part
of another package such as in snap environments.

This involves minor changes to lots of the OVS code and also modifies
the unit tests as to handle OVS from both standard and nonstandard setups.

Signed-off-by: MJ Ponsonby <[email protected]>
@crypticC0der crypticC0der requested a review from slyon March 31, 2025 15:40
slyon
slyon approved these changes Apr 1, 2025
View reviewed changes
Copy link
Collaborator

@slyon slyon left a comment

Choose a reason for hiding this comment

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

Thank you very much for your contribution to Netplan! And for resolving all of my remarks.

CI tests are all green and this LGTM.
Ready to be merged.

@slyon slyon merged commit 4abe2e7 into canonical:main Apr 1, 2025
16 checks passed
@fnordahl fnordahl mentioned this pull request Jul 11, 2025
Merged
thejjw pushed a commit to thejjw/sunbeam-charms that referenced this pull request Aug 29, 2025
@petrutlucian94
Mask system OVS services instead of erroring out
7228578 
OVS crashes if there are multiple conflicting installations.
As such, the charm currently errors out when detecting system
OVS services.

The problem is that with DPDK, we expect OVS bridges and bonds
to be preconfigured through MAAS/Netplan, which currently
use system (deb) OVS packages.

Instead of erroring out, we'll stop and mask system OVS services,
then reapply Netplan to move the OVS bridges to the snap based
OVS installation. Netplan is expected to contain the following
patch: canonical/netplan#549

Note that any configuration defined in the system OVS db that's
not set in Netplan will be lost.

Change-Id: Id398a2e4ef4cd138aa2db35d71e021f61f94b67d
Signed-off-by: Lucian Petrut <[email protected]>
petrutlucian94 added a commit to petrutlucian94/snap-openstack that referenced this pull request Sep 5, 2025
@petrutlucian94
Add DPDK configuration
9a0f78a 
This PR will allow enabling and configuring OVS DPDK, specifically:

* the number of cores used by the OVS DPDK control plane and data path
* the amount of memory used by OVS DPDK from huge pages
* physical DPDK ports
* DPDK-compatible driver (defaults to vfio-pci)

The specified amount of cores will be reserved in the EPA service,
make sure to configure isolated CPUs using kernel arguments.
At the same time, 1GB huge pages must be preallocated.

The pinned CPUs and memory will be distributed across NUMA nodes based
on the NUMA location of the physical DPDK interfaces.

Note that the specified DPDK interfaces will be persistently bound
to the configured DPDK-compatible driver and will no longer be visible
on the host.

Any physical interfaces that are going to be used with DPDK are
expected to be connected to OVS bridges, either directly or
through a bond. The bridge and bond definitions should be predefined
through Maas/Netplan.

The openstack-hypervisor charm will take care of disabling the system
ovs installation, move bridge definitions to the snap installation
(through netplan) and then reconfigure them to use the newly
defined DPDK ports.

Note that Netplan is not aware of DPDK ports, as such those
will be removed from the Netplan configuration and defined in OVS.

We expect the host Netplan installation to include the following
change in order to work with snap OVS installations:
canonical/netplan#549
petrutlucian94 added a commit to petrutlucian94/snap-openstack that referenced this pull request Sep 5, 2025
@petrutlucian94
Add DPDK configuration
22b9cb5 
This PR will allow enabling and configuring OVS DPDK, specifically:

* the number of cores used by the OVS DPDK control plane and data path
* the amount of memory used by OVS DPDK from huge pages
* physical DPDK ports
* DPDK-compatible driver (defaults to vfio-pci)

The specified amount of cores will be reserved in the EPA service,
make sure to configure isolated CPUs using kernel arguments.
At the same time, 1GB huge pages must be preallocated.

The pinned CPUs and memory will be distributed across NUMA nodes based
on the NUMA location of the physical DPDK interfaces.

Note that the specified DPDK interfaces will be persistently bound
to the configured DPDK-compatible driver and will no longer be visible
on the host.

Any physical interfaces that are going to be used with DPDK are
expected to be connected to OVS bridges, either directly or
through a bond. The bridge and bond definitions should be predefined
through Maas/Netplan.

The openstack-hypervisor charm will take care of disabling the system
ovs installation, move bridge definitions to the snap installation
(through netplan) and then reconfigure them to use the newly
defined DPDK ports.

Note that Netplan is not aware of DPDK ports, as such those
will be removed from the Netplan configuration and defined in OVS.

We expect the host Netplan installation to include the following
change in order to work with snap OVS installations:
canonical/netplan#549
@petrutlucian94 petrutlucian94 mentioned this pull request Sep 5, 2025
Merged
petrutlucian94 added a commit to petrutlucian94/snap-openstack that referenced this pull request Sep 8, 2025
@petrutlucian94
Add DPDK configuration
3350a9d 
This PR will allow enabling and configuring OVS DPDK, specifically:

* the number of cores used by the OVS DPDK control plane and data path
* the amount of memory used by OVS DPDK from huge pages
* physical DPDK ports
* DPDK-compatible driver (defaults to vfio-pci)

The specified amount of cores will be reserved in the EPA service,
make sure to configure isolated CPUs using kernel arguments.
At the same time, 1GB huge pages must be preallocated.

The pinned CPUs and memory will be distributed across NUMA nodes based
on the NUMA location of the physical DPDK interfaces.

Note that the specified DPDK interfaces will be persistently bound
to the configured DPDK-compatible driver and will no longer be visible
on the host.

Any physical interfaces that are going to be used with DPDK are
expected to be connected to OVS bridges, either directly or
through a bond. The bridge and bond definitions should be predefined
through Maas/Netplan.

The openstack-hypervisor charm will take care of disabling the system
ovs installation, move bridge definitions to the snap installation
(through netplan) and then reconfigure them to use the newly
defined DPDK ports.

Note that Netplan is not aware of DPDK ports, as such those
will be removed from the Netplan configuration and defined in OVS.

We expect the host Netplan installation to include the following
change in order to work with snap OVS installations:
canonical/netplan#549
petrutlucian94 added a commit to petrutlucian94/snap-openstack that referenced this pull request Sep 8, 2025
@petrutlucian94
Add DPDK configuration
0167946 
This PR will allow enabling and configuring OVS DPDK, specifically:

* the number of cores used by the OVS DPDK control plane and data path
* the amount of memory used by OVS DPDK from huge pages
* physical DPDK ports
* DPDK-compatible driver (defaults to vfio-pci)

The specified amount of cores will be reserved in the EPA service,
make sure to configure isolated CPUs using kernel arguments.
At the same time, 1GB huge pages must be preallocated.

The pinned CPUs and memory will be distributed across NUMA nodes based
on the NUMA location of the physical DPDK interfaces.

Note that the specified DPDK interfaces will be persistently bound
to the configured DPDK-compatible driver and will no longer be visible
on the host.

Any physical interfaces that are going to be used with DPDK are
expected to be connected to OVS bridges, either directly or
through a bond. The bridge and bond definitions should be predefined
through Maas/Netplan.

The openstack-hypervisor charm will take care of disabling the system
ovs installation, move bridge definitions to the snap installation
(through netplan) and then reconfigure them to use the newly
defined DPDK ports.

Note that Netplan is not aware of DPDK ports, as such those
will be removed from the Netplan configuration and defined in OVS.

We expect the host Netplan installation to include the following
change in order to work with snap OVS installations:
canonical/netplan#549
petrutlucian94 added a commit to petrutlucian94/snap-openstack that referenced this pull request Sep 9, 2025
@petrutlucian94
Add DPDK configuration
3c175ca 
This PR will allow enabling and configuring OVS DPDK, specifically:

* the number of cores used by the OVS DPDK control plane and data path
* the amount of memory used by OVS DPDK from huge pages
* physical DPDK ports
* DPDK-compatible driver (defaults to vfio-pci)

The specified amount of cores will be reserved in the EPA service,
make sure to configure isolated CPUs using kernel arguments.
At the same time, 1GB huge pages must be preallocated.

The pinned CPUs and memory will be distributed across NUMA nodes based
on the NUMA location of the physical DPDK interfaces.

Note that the specified DPDK interfaces will be persistently bound
to the configured DPDK-compatible driver and will no longer be visible
on the host.

Any physical interfaces that are going to be used with DPDK are
expected to be connected to OVS bridges, either directly or
through a bond. The bridge and bond definitions should be predefined
through Maas/Netplan.

The openstack-hypervisor charm will take care of disabling the system
ovs installation, move bridge definitions to the snap installation
(through netplan) and then reconfigure them to use the newly
defined DPDK ports.

Note that Netplan is not aware of DPDK ports, as such those
will be removed from the Netplan configuration and defined in OVS.

We expect the host Netplan installation to include the following
change in order to work with snap OVS installations:
canonical/netplan#549

Signed-off-by: Lucian Petrut <[email protected]>
thejjw pushed a commit to thejjw/sunbeam-charms that referenced this pull request Sep 9, 2025
@petrutlucian94
Mask system OVS services instead of erroring out
99c3036 
OVS crashes if there are multiple conflicting installations.
As such, the charm currently errors out when detecting system
OVS services.

The problem is that with DPDK, we expect OVS bridges and bonds
to be preconfigured through MAAS/Netplan, which currently
use system (deb) OVS packages.

Instead of erroring out, we'll stop and mask system OVS services,
then reapply Netplan to move the OVS bridges to the snap based
OVS installation. Netplan is expected to contain the following
patch: canonical/netplan#549

Note that any configuration defined in the system OVS db that's
not set in Netplan will be lost.

Change-Id: Id398a2e4ef4cd138aa2db35d71e021f61f94b67d
Signed-off-by: Lucian Petrut <[email protected]>
(cherry picked from commit 7228578)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@slyon slyon slyon approved these changes

Assignees

No one assigned

Labels

Canonical by Canonical employees outside the Netplan team community This PR has been proposed by somebody outside of the Netplan team and roadmap commitments.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@crypticC0der @slyon