Add first Longhorn tests #389

hamistao · 2025-11-21T19:00:10Z

rancher/qa-tasks#2006

This adds the first automated Longhorn interoperability tests, namely:

Longhorn Installation with Custom Configuration
Fresh Longhorn Installation via Rancher App Catalog
Create Longhorn volume through Rancher Workloads
Test RBAC integration with Longhorn
Test scaling a StatefulSet with a Longhorn PVC template

actions/charts/longhorn.go

hamistao · 2025-11-26T22:46:48Z

validation/longhorn/longhorn_test.go

+	// If Longhorn was installed by a previous test on this same session, uninstall it to install it again with custom configuration.
+	// If Longhorn was installed previously to this test run, leave it be and skip this test. This way we allow for running the
+	// next tests on top of a manually installed Longhorn and avoid accidentally uninstalling something important.
+	if chart.IsAlreadyInstalled {
+		if l.installedLonghorn {
+			l.T().Log("Uninstalling Longhorn that was intalled on the previous test.")
+			err = charts.UninstallLonghornChart(l.client, longhornNamespace, l.cluster.ID, l.payloadOpts.Host)
+			require.NoError(l.T(), err)
+		} else {
+			l.T().Skip("Skipping installation test because Longhorn is already installed")
+		}
+	}
+


This decision was tricky and had some discussion surrounding it. From the outcome of the discussions I believe this is the way to go. This way we achieve

1- Running all tests at once with the suite;
2- Running some tests with a custom installation of longhorn;
3- Keep the cleanup logic neatly isolated;

cc @rancher/qa-pit-crew

1 last nit here; put chart_install test in its own file -- move the rest out (same structure as validation/fleet/provisioning)

this way, the non-install tests can have the chart check + install / uninstall as a part of setup instead of in each test.

So are you saying we should put the chart install test in a separate file and in a separate suite and install Longhorn in the setup for the suite containing all the tests except the chart install one. If that is correct,

I assume the test that installs longhorn again with a static custom configuration would share a suite with the simple chart install test and the one that runs last would uninstall if longhorn was installed in the same test run before proceeding.

If that is correct, I see the benefits of doing this, but also having them of two suites would make it impossible to run them all of them in a single Jenkins run, so now I am trying to think of a way that we can have the best of both worlds.

validation/longhorn/longhorn_test.go

rancher-max

Looks really good! Couple of minor things, but otherwise this has my approval 👍

actions/charts/longhorn.go

validation/longhorn/longhorn_test.go

floatingman

Looks good overall. You should consider adding a README for the longhorn_test, so others will know how to run the tests and if any specific cattle-config settings are needed.

actions/charts/longhorn.go

actions/workloads/pods/pods.go

validation/longhorn/longhorn_test.go

rancher-max

LGTM -- left one comment that I feel is a nit so will leave up to you if you want to update or not

validation/longhorn/longhorn_test.go

hamistao · 2025-12-11T13:34:13Z

You should consider adding a README for the longhorn_test, so others will know how to run the tests and if any specific cattle-config settings are needed.

@floatingman at this point there is no additional settings required for these tests, so I don't think this is needed yet. That said, there are a lot more tests to go so I will keep that in mind moving forward.

validation/longhorn/longhorn_test.go

actions/charts/longhorn.go

validation/longhorn/longhorn_test.go

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

This is not required for the Longhorn tests. Signed-off-by: hamistao <pedro.ribeiro@suse.com>

The dash is already added by `AppendRandomString` Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

And move CreatePVCWorkload there Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

This adds the following tests: - Install Longhorn Using Rancher Charts - Install Longhorn with Custom Configuration - Create Longhorn Volume with Rancher Workloads - Test RBAC Integration with Longhorn - Test Scaling a StatefulSet with a Longhorn PVC Signed-off-by: hamistao <pedro.ribeiro@suse.com>

slickwarren

some more nits, but pretty simple ones. Can meet to go over if you would like

slickwarren · 2026-01-05T18:08:52Z

validation/longhorn/longhorn_test.go

+	storage.CheckVolumeAllocation(l.T(), l.client, l.cluster.ID, namespace.Name, l.longhornTestConfig.LonghornTestStorageClass, volumeSourceName, storage.MountPath)
+
+	var stetefulSetPodReplicas int32 = 5
+	statefulSet.Spec.Replicas = &stetefulSetPodReplicas
+	statefulSet, err = statefulset.UpdateStatefulSet(l.client, l.cluster.ID, namespace.Name, statefulSet, true)
+	require.NoError(l.T(), err)
+
+	storage.CheckVolumeAllocation(l.T(), l.client, l.cluster.ID, namespace.Name, l.longhornTestConfig.LonghornTestStorageClass, volumeSourceName, storage.MountPath)


there's some weirdness in the logs around this function but I can't figure out exactly where:

09:09:24 2025/12/24 17:09:23 (0xc000efe000) (0xc000b600a0) Stream added, broadcasting: 3 09:09:24 2025/12/24 17:09:23 (0xc000efe000) Reply frame received for 3 09:09:24 2025/12/24 17:09:23 (0xc000efe000) (0xc000a663c0) Create stream 09:09:24 2025/12/24 17:09:23 (0xc000efe000) (0xc000a663c0) Stream added, broadcasting: 5 09:09:24 2025/12/24 17:09:23 (0xc000efe000) Reply frame received for 5

slickwarren · 2026-01-05T18:10:01Z

actions/storage/verify.go

+
+	t.Logf("Write to mounted volume under the path [%v] on pod [%v]", mountpoint, podName)
+	writeToMountedVolume := []string{"touch", mountpoint + "/" + testFileName}
+	output, err := kubeconfig.KubectlExec(restConfig, podName, namespace, writeToMountedVolume)


does this log streams for some reason?

slickwarren · 2026-01-05T18:11:17Z

validation/longhorn/longhorn_test.go

+	// If Longhorn was installed by a previous test on this same session, uninstall it to install it again with custom configuration.
+	// If Longhorn was installed previously to this test run, leave it be and skip this test. This way we allow for running the
+	// next tests on top of a manually installed Longhorn and avoid accidentally uninstalling something important.
+	if chart.IsAlreadyInstalled {
+		if l.installedLonghorn {
+			l.T().Log("Uninstalling Longhorn that was intalled on the previous test.")
+			err = charts.UninstallLonghornChart(l.client, longhornNamespace, l.cluster.ID, l.payloadOpts.Host)
+			require.NoError(l.T(), err)
+		} else {
+			l.T().Skip("Skipping installation test because Longhorn is already installed")
+		}
+	}
+


1 last nit here; put chart_install test in its own file -- move the rest out (same structure as validation/fleet/provisioning)

this way, the non-install tests can have the chart check + install / uninstall as a part of setup instead of in each test.

slickwarren · 2026-01-05T18:12:28Z

validation/longhorn/README.md

+```yaml
+longhorn:
+  testProject: "longhorn-custom-test"
+  testStorageClass: "longhorn" # Can be either "longhorn" or "longhorn-static"


does it matter which?

tbh I am not sure. Since most operations perform over the course of the tests can be done with either, I figured I should add this option in case someone wants to test using longhorn-static specifically, but I am not sure as which scenarios would demand that.

slickwarren · 2026-01-05T18:14:41Z

interoperability/longhorn/longhorn.go

+	longhornTestConfigConfigurationFileKey = "longhorn"
+	LonghornTestDefaultProject             = "longhorn-test"
+	LonghornTestDefaultStorageClass        = "longhorn"
+)


why not set this at the TestConfig level instead i.e. json:"testProject,default=longhorn-test (not sure if that's exactly the format, see other files for exact ref.

Hey I like this approach. I am not sure whether it works if the configuration is missing entirely instead of just missing a few fields, but either way there is room for improvement here.

slickwarren · 2026-01-05T18:21:16Z

interoperability/longhorn/longhorn.go

+		if r := recover(); r != nil {
+			longhornTestConfig = TestConfig{
+				LonghornTestProject:      LonghornTestDefaultProject,
+				LonghornTestStorageClass: LonghornTestDefaultStorageClass,
+			}


why would this ever fail? just curious as this isn't typically in other funcs that load in a struct.

If the longhorn test configuration on the cattle config file is not set, LoadConfig panics and then we recover by using the default values.

slickwarren · 2026-01-05T18:22:23Z

interoperability/longhorn/longhorn.go

+			if !slices.Contains(storage.LonghornStorageClasses, longhornTestConfig.LonghornTestStorageClass) {
+				panic(fmt.Errorf("Invalid storage class %s", longhornTestConfig.LonghornTestStorageClass))
+			}


won't this fail is its empty? Or maybe it never will be empty if you use the json suggestion above. . ?

If it is empty then we would have entered the previous if block.

slickwarren · 2026-01-05T18:22:48Z

interoperability/longhorn/longhorn.go

+		longhornTestConfig.LonghornTestProject = LonghornTestDefaultProject
+	}
+
+	if longhornTestConfig.LonghornTestStorageClass == "" {


I think this will never be reached if it is indeed empty due to the panic above.

This is for the case where the longhorn test configuration is there but one of the fields is empty.

hamistao commented Nov 24, 2025

View reviewed changes

actions/charts/longhorn.go Outdated Show resolved Hide resolved

hamistao force-pushed the longhorn_installation_tests branch from c8c01b3 to 0cda9b4 Compare November 26, 2025 22:42

hamistao commented Nov 26, 2025

View reviewed changes

validation/longhorn/longhorn_test.go Outdated Show resolved Hide resolved

hamistao marked this pull request as ready for review November 26, 2025 22:48

hamistao requested a review from a team November 26, 2025 22:49

hamistao force-pushed the longhorn_installation_tests branch 2 times, most recently from 264b9a2 to b1dbeaa Compare November 28, 2025 13:55

lscalabrini01 reviewed Nov 28, 2025

View reviewed changes

validation/longhorn/longhorn_test.go Outdated Show resolved Hide resolved

lscalabrini01 reviewed Nov 28, 2025

View reviewed changes

validation/longhorn/longhorn_test.go Show resolved Hide resolved

lscalabrini01 reviewed Nov 28, 2025

View reviewed changes

validation/longhorn/longhorn_test.go Show resolved Hide resolved

rancher-max reviewed Dec 2, 2025

View reviewed changes

actions/charts/longhorn.go Outdated Show resolved Hide resolved

actions/charts/longhorn.go Outdated Show resolved Hide resolved

validation/longhorn/longhorn_test.go Outdated Show resolved Hide resolved

validation/longhorn/longhorn_test.go Show resolved Hide resolved

floatingman self-requested a review December 2, 2025 22:12

floatingman requested changes Dec 3, 2025

View reviewed changes

hamistao force-pushed the longhorn_installation_tests branch from b1dbeaa to e7d7e69 Compare December 4, 2025 18:32

hamistao changed the title ~~Add Longhorn installation tests~~ Add first Longhorn tests Dec 4, 2025

hamistao commented Dec 9, 2025

View reviewed changes

validation/longhorn/longhorn_test.go Outdated Show resolved Hide resolved

rancher-max added the team/pit-crew slack notifier for pit crew label Dec 9, 2025

rancher-max assigned hamistao Dec 9, 2025

floatingman requested a review from slickwarren December 10, 2025 03:50

lscalabrini01 reviewed Dec 10, 2025

View reviewed changes

validation/longhorn/longhorn_test.go Outdated Show resolved Hide resolved

hamistao force-pushed the longhorn_installation_tests branch from e7d7e69 to 0ebe37f Compare December 10, 2025 21:11

rancher-max previously approved these changes Dec 11, 2025

View reviewed changes

validation/longhorn/longhorn_test.go Outdated Show resolved Hide resolved

slickwarren reviewed Dec 11, 2025

View reviewed changes

hamistao dismissed rancher-max’s stale review via aca2bac December 24, 2025 14:08

hamistao force-pushed the longhorn_installation_tests branch 4 times, most recently from bc06906 to 978e0eb Compare December 24, 2025 17:00

hamistao force-pushed the longhorn_installation_tests branch from 978e0eb to 0a11914 Compare December 24, 2025 17:30

hamistao added 13 commits December 24, 2025 14:43

Simplify getting cluster name

1dfb103

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Remove unused deploymentTemplate variable

c059a61

This is not required for the Longhorn tests. Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Remove unnecessary tailing dash

8d0398a

The dash is already added by `AppendRandomString` Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Remove unused constants

0255fc3

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Update pit_schemas.yaml

8a0c455

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Add storageClassName parameter

53bc05d

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Create GetStorageClass

443cc6d

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Add Longhorn actions

8da30fb

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Add README for Longhorn tests

b9f9049

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Create storage related actions

650af74

And move CreatePVCWorkload there Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Allow PVC template creation in CreateStatefulSet

f1d49fb

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

Add logic to parse longhorn cattle config

21a00a1

Signed-off-by: hamistao <pedro.ribeiro@suse.com>

hamistao force-pushed the longhorn_installation_tests branch from 0a11914 to aa8f72c Compare December 24, 2025 17:44

slickwarren reviewed Jan 5, 2026

View reviewed changes

Add first Longhorn tests #389

Are you sure you want to change the base?

Add first Longhorn tests #389

Conversation

hamistao commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rancher-max left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

floatingman left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rancher-max left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hamistao commented Dec 11, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

slickwarren left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamistao commented Nov 21, 2025 •

edited

Loading