Add SLES support for AMD gpu-operator by Priyankasaggu11929 · Pull Request #365 · ROCm/gpu-operator

Priyankasaggu11929 · 2025-10-23T13:06:56Z

Motivation

This PR aim at adding support for SUSE Linux Enterprise Server (SLES) 15 SP7+ to the AMD GPU operator.

Technical Details

abbdaa8 - add support for detecting SLES nodes and automatically selecting appropriate AMD GPU driver versions
- add new slesCMNameMapper to parse SLES version strings like 'SUSE Linux Enterprise Server 15 SP7' to 'sles-15.7'
- add SLESDefaultDriverVersionsMapper to select driver versions
- register both 'sles' and 'suse' identifiers in mappers
669b888 - add SLES Dockerfile template (DockerfileTemplate.sles) using prebuilt SUSE AMD GPU Driver image (currently, I've skipped adding the GIM Dockerfile template for SLES, will tackle it once this goes through).
- also embed the template via go:embed and add SLES case logic
~~c2dce44 - docs: update example/deviceconfig_example.yaml~~ <- dropped
017fcb5- use "registry.suse.com" as the default base image registry if OS == "sles"
- although, use-specified BaseImageRegistry still takes precedence
- also extend tests in internal/kmmodule/kmmodule_test.go to test above changes in resolveDockerfile func

Test Plan

13248e7 - tests: update internal/utils_test.go for added support for SLES 15 SP*

Test Result

truncated output of make unit-test after new added tests

> make unit-test
...
...
=== RUN   TestSLESDefaultDriverVersionsMapper
=== RUN   TestSLESDefaultDriverVersionsMapper/SLES_15_SP6
=== RUN   TestSLESDefaultDriverVersionsMapper/SLES_15_SP7
=== RUN   TestSLESDefaultDriverVersionsMapper/SLES_15_SP5
=== RUN   TestSLESDefaultDriverVersionsMapper/SLES_15_SP4
=== RUN   TestSLESDefaultDriverVersionsMapper/SLES_15_base
=== RUN   TestSLESDefaultDriverVersionsMapper/SLES_15_with_dash_format
--- PASS: TestSLESDefaultDriverVersionsMapper (0.00s)
    --- PASS: TestSLESDefaultDriverVersionsMapper/SLES_15_SP6 (0.00s)
    --- PASS: TestSLESDefaultDriverVersionsMapper/SLES_15_SP7 (0.00s)
    --- PASS: TestSLESDefaultDriverVersionsMapper/SLES_15_SP5 (0.00s)
    --- PASS: TestSLESDefaultDriverVersionsMapper/SLES_15_SP4 (0.00s)
    --- PASS: TestSLESDefaultDriverVersionsMapper/SLES_15_base (0.00s)
    --- PASS: TestSLESDefaultDriverVersionsMapper/SLES_15_with_dash_format (0.00s)
PASS
coverage: 48.6% of statements
ok  	github.com/ROCm/gpu-operator/internal	0.019s	coverage: 48.6% of statements
=== RUN   TestAPIs
Running Suite: Controller Suite - /home/psaggu/work-suse/amd-gpu-operator-work/oct-23-pr/gpu-operator/internal/controllers
==========================================================================================================================
Random Seed: 1761223798

Will run 15 of 15 specs
•••••••••••••••

Ran 15 of 15 Specs in 0.008 seconds
SUCCESS! -- 15 Passed | 0 Failed | 0 Pending | 0 Skipped
--- PASS: TestAPIs (0.01s)
PASS
coverage: 7.9% of statements
ok  	github.com/ROCm/gpu-operator/internal/controllers	(cached)	coverage: 7.9% of statements
=== RUN   TestAPIs
Running Suite: KMMModule Suite - /home/psaggu/work-suse/amd-gpu-operator-work/oct-23-pr/gpu-operator/internal/kmmmodule
=======================================================================================================================
Random Seed: 1761223798

Will run 5 of 5 specs
testing multiple valid homogeneous nodes
testing multiple valid heterogeneous nodes
testing multiple valid heterogeneous nodes + one unsupported node
testing multiple unsupported nodes
testing empty node list
•<moduleName>
<amdgpu>
•<moduleName>
<amdgpu>
•••

Ran 5 of 5 Specs in 0.005 seconds
SUCCESS! -- 5 Passed | 0 Failed | 0 Pending | 0 Skipped
--- PASS: TestAPIs (0.01s)
PASS
coverage: 32.3% of statements
ok  	github.com/ROCm/gpu-operator/internal/kmmmodule	(cached)	coverage: 32.3% of statements

•••••••••••••••

Ran 15 of 15 Specs in 0.008 seconds
SUCCESS! -- 15 Passed | 0 Failed | 0 Pending | 0 Skipped

output from tests added

❯ go test ./internal/kmmmodule/... -v -ginkgo.focus="resolveDockerfile" -ginkgo.v
=== RUN   TestAPIs
Running Suite: KMMModule Suite - /home/psaggu/work-suse/amd-gpu-operator-work/oct-23-pr/gpu-operator/internal/kmmmodule
=======================================================================================================================
Random Seed: 1761548380

Will run 3 of 8 specs
SSSS
------------------------------
resolveDockerfile should use correct default registry when not specified by user
/home/psaggu/work-suse/amd-gpu-operator-work/oct-23-pr/gpu-operator/internal/kmmmodule/kmmmodule_test.go:683
• [0.000 seconds]
------------------------------
resolveDockerfile should respect user-specified BaseImageRegistry for all OS types
/home/psaggu/work-suse/amd-gpu-operator-work/oct-23-pr/gpu-operator/internal/kmmmodule/kmmmodule_test.go:702
• [0.000 seconds]
------------------------------
resolveDockerfile should return error for unsupported OS
/home/psaggu/work-suse/amd-gpu-operator-work/oct-23-pr/gpu-operator/internal/kmmmodule/kmmmodule_test.go:727
• [0.000 seconds]
------------------------------
S

Ran 3 of 8 Specs in 0.000 seconds
SUCCESS! -- 3 Passed | 0 Failed | 0 Pending | 5 Skipped
--- PASS: TestAPIs (0.00s)
PASS
ok  	github.com/ROCm/gpu-operator/internal/kmmmodule	0.022s

Submission Checklist

Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

Priyankasaggu11929 · 2025-10-23T13:16:37Z

Hello @yansun1996, I’ve opened this PR to get early feedback on the approach for adding support for SLES 15 SP6/SP7.
Please review and let me know if/where any changes are needed.

Also please note - I haven’t tested these changes yet on a SLES 15 host with an AMD GPU. That is in works!

yansun1996 · 2025-10-23T16:00:33Z

Hello @yansun1996, I’ve opened this PR to get early feedback on the approach for adding support for SLES 15 SP6/SP7. Please review and let me know if/where any changes are needed.

Also please note - I haven’t tested these changes yet on a SLES 15 host with an AMD GPU. That is in works!

Hi @Priyankasaggu11929 thanks for raising the PR, we will review this PR.

Please also let us know when you did some verification on the real AMD GPU hardware based cluster. thanks !

Priyankasaggu11929 · 2025-10-24T05:00:28Z

Hi @Priyankasaggu11929 thanks for raising the PR, we will review this PR.
Please also let us know when you did some verification on the real AMD GPU hardware based cluster. thanks !

Yes, I'll keep posting updates. Thank you!

yansun1996

one minor suggestion, the rest of the PR looks good
Let us know when you finished the verification with hardware

yansun1996

thanks @Priyankasaggu11929 good job, please open another same PR against the staging branch, we're managing PR in this way staging ---> main ---> release-vx.x.x

once you confirmed the verification on AMD GPU setup is done, we can discuss with product team about further details for a release plan with SLES support

Priyankasaggu11929 · 2025-10-28T04:45:50Z

thanks @Priyankasaggu11929 good job, please open another same PR against the staging branch, we're managing PR in this way staging ---> main ---> release-vx.x.x

Created PR for staging branch - #371

once you confirmed the verification on AMD GPU setup is done, we can discuss with product team about further details for a release plan with SLES support

Thank you so much!

Regarding "the verification on AMD GPU setup" - I'm still in discussion for getting the required lab infra access, so there are no updates as of now on this, but I will post updates as soon as I am able to run some tests.

* Automate the helm README build in sanity * address comments

Priyankasaggu11929 · 2026-05-04T07:43:24Z

Hello @yansun1996, I have updated the PR today with latest changes.

We have tested the PR changes (with the SUSE built amdgpu driver container image for latest version v7.0.3) on a machine with AMD Radeon Pro V520 (7362) GPU device and can confirm that the AMD gpu-operator is able to detect SLES nodes and publish the available GPU devices to workloads requesting GPUs (across all kernel versions of SLES 15 SP7 codestream).

Requesting your review again on the PR changes.

(Also, please let me know if staging branch is still the way to submit these changes, in that case, I'll refresh the other PR too - #371)

I used the following patch for gpu-operator to detect Radeon Pro V520 (7362) device.

> cat v520-device-support.patch 
diff --git a/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml b/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml
index 7d0269cd..531bc06b 100644
--- a/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml
+++ b/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml
@@ -64,6 +64,11 @@ spec:
             matchExpressions:
                 vendor: {op: In, value: ["1002"]}
                 device: {op: In, value: ["73ae"]} # Radeon Pro V620 MxGPU
+      - matchFeatures:
+          - feature: pci.device
+            matchExpressions:
+                vendor: {op: In, value: ["1002"]}
+                device: {op: In, value: ["7362"]} # Radeon Pro V520
   - name: amd-gpu
     labels:
       feature.node.kubernetes.io/amd-gpu: "true"
@@ -185,6 +190,11 @@ spec:
             matchExpressions:
               vendor: {op: In, value: ["1002"]}
               device: {op: In, value: ["73a1"]} # V620
+      - matchFeatures:
+          - feature: pci.device
+            matchExpressions:
+              vendor: {op: In, value: ["1002"]}
+              device: {op: In, value: ["7362"]} # V520
       - matchFeatures:
           - feature: pci.device
             matchExpressions:
diff --git a/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml b/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml
index 7d0269cd..531bc06b 100644
--- a/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml
+++ b/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml
@@ -64,6 +64,11 @@ spec:
             matchExpressions:
                 vendor: {op: In, value: ["1002"]}
                 device: {op: In, value: ["73ae"]} # Radeon Pro V620 MxGPU
+      - matchFeatures:
+          - feature: pci.device
+            matchExpressions:
+                vendor: {op: In, value: ["1002"]}
+                device: {op: In, value: ["7362"]} # Radeon Pro V520
   - name: amd-gpu
     labels:
       feature.node.kubernetes.io/amd-gpu: "true"
@@ -185,6 +190,11 @@ spec:
             matchExpressions:
               vendor: {op: In, value: ["1002"]}
               device: {op: In, value: ["73a1"]} # V620
+      - matchFeatures:
+          - feature: pci.device
+            matchExpressions:
+              vendor: {op: In, value: ["1002"]}
+              device: {op: In, value: ["7362"]} # V520
       - matchFeatures:
           - feature: pci.device
             matchExpressions:

yansun1996 · 2026-05-04T07:46:23Z

Hello @yansun1996, I have updated the PR today with latest changes.

We have tested the PR changes (with the SUSE built amdgpu driver container image for latest version v7.0.3) on a machine with AMD Radeon Pro V520 (7362) GPU device and can confirm that the AMD gpu-operator is able to detect SLES nodes and publish the available GPU devices to workloads requesting GPUs (across all kernel versions of SLES 15 SP7 codestream).

Requesting your review again on the PR changes.

(Also, please let me know if staging branch is still the way to submit these changes, in that case, I'll refresh the other PR too - #371)

I used the following patch for gpu-operator to detect Radeon Pro V520 (7362) device.


> cat v520-device-support.patch 

diff --git a/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml b/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml

index 7d0269cd..531bc06b 100644

--- a/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml

+++ b/hack/k8s-patch/template-patch/gpu-nfd-default-rule.yaml

@@ -64,6 +64,11 @@ spec:

             matchExpressions:

                 vendor: {op: In, value: ["1002"]}

                 device: {op: In, value: ["73ae"]} # Radeon Pro V620 MxGPU

+      - matchFeatures:

+          - feature: pci.device

+            matchExpressions:

+                vendor: {op: In, value: ["1002"]}

+                device: {op: In, value: ["7362"]} # Radeon Pro V520

   - name: amd-gpu

     labels:

       feature.node.kubernetes.io/amd-gpu: "true"

@@ -185,6 +190,11 @@ spec:

             matchExpressions:

               vendor: {op: In, value: ["1002"]}

               device: {op: In, value: ["73a1"]} # V620

+      - matchFeatures:

+          - feature: pci.device

+            matchExpressions:

+              vendor: {op: In, value: ["1002"]}

+              device: {op: In, value: ["7362"]} # V520

       - matchFeatures:

           - feature: pci.device

             matchExpressions:

diff --git a/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml b/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml

index 7d0269cd..531bc06b 100644

--- a/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml

+++ b/helm-charts-k8s/templates/gpu-nfd-default-rule.yaml

@@ -64,6 +64,11 @@ spec:

             matchExpressions:

                 vendor: {op: In, value: ["1002"]}

                 device: {op: In, value: ["73ae"]} # Radeon Pro V620 MxGPU

+      - matchFeatures:

+          - feature: pci.device

+            matchExpressions:

+                vendor: {op: In, value: ["1002"]}

+                device: {op: In, value: ["7362"]} # Radeon Pro V520

   - name: amd-gpu

     labels:

       feature.node.kubernetes.io/amd-gpu: "true"

@@ -185,6 +190,11 @@ spec:

             matchExpressions:

               vendor: {op: In, value: ["1002"]}

               device: {op: In, value: ["73a1"]} # V620

+      - matchFeatures:

+          - feature: pci.device

+            matchExpressions:

+              vendor: {op: In, value: ["1002"]}

+              device: {op: In, value: ["7362"]} # V520

       - matchFeatures:

           - feature: pci.device

             matchExpressions:

Hi @Priyankasaggu11929 thanks for the update and verification, let me discuss with the team about this PR, will get back to you.

Priyankasaggu11929 · 2026-05-04T07:48:32Z

thanks for the update and verification, let me discuss with the team about this PR, will get back to you.

Thank you.

Priyankasaggu11929 · 2026-05-07T09:37:54Z

Hello @yansun1996, could you help with some information on the following:

We were waiting for a new amdgpu driver modules release that supports SLES 16.0, and just noticed that the modules are available under tag v31.20: https://repo.radeon.com/amdgpu/31.20/sle/16.0/main/x86_64/

Previously, we had been using the v7.0.3 release as the latest release: https://repo.radeon.com/amdgpu/7.0.3/sle/
and were monitoring the latest branch here: https://repo.radeon.com/amdgpu/latest/sle/

What is the difference between the 7.x.x and 31.x.x versioning schemes? And Which release stream are the recommended one to use?

yansun1996 · 2026-05-08T22:06:01Z

Hello @yansun1996, could you help with some information on the following:

We were waiting for a new amdgpu driver modules release that supports SLES 16.0, and just noticed that the modules are available under tag v31.20: https://repo.radeon.com/amdgpu/31.20/sle/16.0/main/x86_64/

Previously, we had been using the v7.0.3 release as the latest release: https://repo.radeon.com/amdgpu/7.0.3/sle/ and were monitoring the latest branch here: https://repo.radeon.com/amdgpu/latest/sle/

What is the difference between the 7.x.x and 31.x.x versioning schemes? And Which release stream are the recommended one to use?

Hi @Priyankasaggu11929 ,

I will cherry-pick your commits for internal CI (not public available yet)

as for your question: v7.x.x and v30.x.x

there is a recent driver version change happened.

Previously in driver version <= v7.0.x you will see that each amdgpu release has followed the ROCm release version

However in recent amdgpu driver releases, the release version has diverged from ROCm release, start to use 30.x.x

So as of now, amdgpu driver has its own release and ROCm runtime libs has their release version

for more information please check https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/user-kernel-space-compat-matrix.html#user-and-amd-gpu-driver-amdgpu-support-matrix

yansun1996 · 2026-05-08T22:57:56Z

+var slesCSDPrebuiltDriverImages = map[string]map[string]string{
+	"15.7": {
+		"7.0.3": "registry.suse.com/third-party/amd/amdgpu-driver:sles-15.7-7.0.3",
+	},
+}


Bug — data tables are inconsistent. This prebuilt-image table only registers 15.7 → 7.0.3, but SLESDefaultDriverVersionsMapper (utils.go) defaults to 7.0.2 for SP6 and 6.2.2 for SP5/base. With those defaults, the lookup in getKM (around line 572) silently misses and SUSE_PREBUILT_DRIVER_IMG is never injected. The new Dockerfile template has no fallback — FROM ${SUSE_PREBUILT_DRIVER_IMG} AS driver-source resolves to FROM AS driver-source, which fails the build.

Net effect: with the defaults this PR ships, SP5 and SP6 nodes (which the PR claims to support) cannot build. Either add prebuilt entries for the SP5/SP6 default driver versions, narrow SLESDefaultDriverVersionsMapper to only return versions present here, or surface an explicit error on lookup miss.

Thanks for the pointer.

SLESDefaultDriverVersionsMapper in utils.go was supposed to be cleaned up as part of my previous commit refreshes.

I have narrowed the supported versions to SLES 15 SP7 only and keeping just the 15.7 -> 7.0.3 entry in the table. Since, we are now going to build the prebuilt driver container images starting SLES 15 SP7.

(I'll either send a new PR or update this one to add SLES 16.0 as well to the table, as soon as the respective prebuilt container image is ready).

Also addressed the silent-skip behavior to now properly return error messages on any version outside SLES 15.7 for now.

Also, please note - I will update the driver version to use the new amdgpu driver version - v31.20 once the respective prebuilt container image is ready and published. Thanks!

yansun1996

PTAL the comments @Priyankasaggu11929 , thanks

Priyankasaggu11929 · 2026-05-11T07:33:17Z

as for your question: v7.x.x and v30.x.x
there is a recent driver version change happened.
Previously in driver version <= v7.0.x you will see that each amdgpu release has followed the ROCm release version
However in recent amdgpu driver releases, the release version has diverged from ROCm release, start to use 30.x.x
So as of now, amdgpu driver has its own release and ROCm runtime libs has their release version
for more information please check https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/user-kernel-space-compat-matrix.html#user-and-amd-gpu-driver-amdgpu-support-matrix

Thank you. Then I will update the driver version to use v31.20 adhering to the new release version scheme.

…opriate AMD GPU driver versions * add new `slesCMNameMapper` to parse SLES version strings like 'SUSE Linux Enterprise Server 15 SP7' to 'sles-15.7' * add `SLESDefaultDriverVersionsMapper` to select driver versions * register both 'sles' and 'suse' identifiers in mappers Co-authored-by: alex-isv <alex.zacharow@suse.com>

… SUSE AMD GPU driver image

…sles" * although, use-specified `BaseImageRegistry` still takes precedence * also extend tests in `internal/kmmodule/kmmodule_test.go` to test above changes in `resolveDockerfile` func

yansun1996 · 2026-05-13T22:53:11Z

Hi @Priyankasaggu11929 , are all the changed done here ? If yes i will trigger internal CI pipeline

Priyankasaggu11929 · 2026-05-14T06:51:50Z

Hi @Priyankasaggu11929 , are all the changed done here ? If yes i will trigger internal CI pipeline

yes, all changes for configuration - SLES SP7 + amdgpu driver modules v7.0.3 are complete.

We're working on creating container images for newer amdgpu driver modules releases. But that is non-blocking for this PR and I'll add them in follow up PRs.

yansun1996 · 2026-05-19T23:15:31Z

Hi @Priyankasaggu11929 we have merged this PR, if you have any other pull request pls let us know, thanks for your contribution !

Priyankasaggu11929 · 2026-05-20T04:36:52Z

Hi @Priyankasaggu11929 we have merged this PR, if you have any other pull request pls let us know, thanks for your contribution !

I'll create another PR SLES 16.0 (as soon as the respective driver container images are published on registry.suse.com) - will ping you on that. Thank you for your help so far, @yansun1996.

yansun1996 reviewed Oct 24, 2025

View reviewed changes

Comment thread example/deviceconfig_example.yaml Outdated

yansun1996 reviewed Oct 24, 2025

View reviewed changes

Priyankasaggu11929 force-pushed the enable-sles-support branch from d46ce29 to 4da60d3 Compare October 27, 2025 06:57

Priyankasaggu11929 mentioned this pull request Oct 27, 2025

update "Requires: g++" to "gcc-c++" in rpm package spec amd/MxGPU-Virtualization#14

Closed

yansun1996 reviewed Oct 27, 2025

View reviewed changes

Priyankasaggu11929 mentioned this pull request Oct 28, 2025

[Staging] Add SLES support for AMD gpu-operator #371

Closed

1 task

leslie-qiwa pushed a commit to leslie-qiwa/gpu-operator that referenced this pull request Feb 6, 2026

Automate the helm README build in sanity (ROCm#365)

68d91ed

* Automate the helm README build in sanity * address comments

Priyankasaggu11929 force-pushed the enable-sles-support branch 2 times, most recently from 666be77 to 7dfec5e Compare May 4, 2026 07:32

yansun1996 requested changes May 8, 2026

View reviewed changes

Priyankasaggu11929 force-pushed the enable-sles-support branch from 7dfec5e to 017fcb5 Compare May 11, 2026 07:13

Priyankasaggu11929 and others added 4 commits May 11, 2026 11:05

add SLES Dockerfile template (DockerfileTemplate.sles) using prebuilt…

332a340

… SUSE AMD GPU driver image

tests: update internal/utils_test.go for added support for SLES 15 SP7+

2adfee0

use "registry.suse.com" as the default base image registry if OS == "…

5a0c824

…sles" * although, use-specified `BaseImageRegistry` still takes precedence * also extend tests in `internal/kmmodule/kmmodule_test.go` to test above changes in `resolveDockerfile` func

Priyankasaggu11929 force-pushed the enable-sles-support branch from 017fcb5 to 5a0c824 Compare May 11, 2026 11:07

sajmera-pensando merged commit 75c9cdd into ROCm:main May 19, 2026
3 checks passed

Conversation

Priyankasaggu11929 commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Technical Details

Test Plan

Test Result

Submission Checklist

Uh oh!

Priyankasaggu11929 commented Oct 23, 2025

Uh oh!

yansun1996 commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Priyankasaggu11929 commented Oct 24, 2025

Uh oh!

Uh oh!

yansun1996 left a comment

Choose a reason for hiding this comment

Uh oh!

yansun1996 left a comment

Choose a reason for hiding this comment

Uh oh!

Priyankasaggu11929 commented Oct 28, 2025

Uh oh!

Priyankasaggu11929 commented May 4, 2026

Uh oh!

yansun1996 commented May 4, 2026

Uh oh!

Priyankasaggu11929 commented May 4, 2026

Uh oh!

Priyankasaggu11929 commented May 7, 2026

Uh oh!

yansun1996 commented May 8, 2026

Uh oh!

yansun1996 May 8, 2026

Choose a reason for hiding this comment

Uh oh!

Priyankasaggu11929 May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yansun1996 left a comment

Choose a reason for hiding this comment

Uh oh!

Priyankasaggu11929 commented May 11, 2026

Uh oh!

yansun1996 commented May 13, 2026

Uh oh!

Priyankasaggu11929 commented May 14, 2026

Uh oh!

Uh oh!

yansun1996 commented May 19, 2026

Uh oh!

Priyankasaggu11929 commented May 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Priyankasaggu11929 commented Oct 23, 2025 •

edited

Loading

yansun1996 commented Oct 23, 2025 •

edited

Loading

Priyankasaggu11929 May 11, 2026 •

edited

Loading