Fix: prevent panic in YurtAppSet status for StatefulSet workloads#2503
Fix: prevent panic in YurtAppSet status for StatefulSet workloads#2503Yashika0724 wants to merge 1 commit intoopenyurtio:masterfrom
Conversation
Signed-off-by: Yashika <ssyashika1311@gmail.com>
|
|
Hello @zyjhtangtang , I’ve submitted a fix for a controller panic related to StatefulSet-based |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2503 +/- ##
==========================================
- Coverage 44.09% 44.08% -0.02%
==========================================
Files 399 399
Lines 26554 26568 +14
==========================================
+ Hits 11710 11713 +3
- Misses 13782 13792 +10
- Partials 1062 1063 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| updatedReplicas = w.Status.UpdatedReplicas | ||
| hash = workloadmanager.GetWorkloadHash(w) | ||
| default: | ||
| klog.Warningf("YurtAppSet[%s/%s] unknown workload type: %T", yas.GetNamespace(), yas.GetName(), workload) |
There was a problem hiding this comment.
Would it be better to include the workload's name and namespace in the logs?
There was a problem hiding this comment.
Would it be better to include the workload's name and namespace in the logs?
That makes sense, including the workload name and namespace would improve debugging and log clarity. I’ll update the warning log to include those fields.
Thanks for the suggestion!
2 participants
Summary
This PR fixes a runtime panic in the YurtAppSet controller that occurs when calculating status
for YurtAppSets configured with a StatefulSet workload template.
The controller previously assumed all workloads were Deployments and performed an unsafe type
assertion, which caused a panic when workloads were actually StatefulSets. As a result,
StatefulSet-based YurtAppSets would crash the controller during reconciliation.
This fix updates the status calculation logic to safely handle both Deployment and StatefulSet
workloads.
Root Cause
In
conciliateYurtAppSetStatus, workloads are iterated as[]metav1.Objectand cast like this:go workloadObj := workload.(*appsv1.Deployment)However, the workload manager returns different types depending on the workload template:
• Deployment template → *appsv1.Deployment
• StatefulSet template → *appsv1.StatefulSet
When a YurtAppSet uses statefulSetTemplate, the controller attempts to cast a
*appsv1.StatefulSet to *appsv1.Deployment, resulting in:
interface conversion: metav1.Object is *v1.StatefulSet, not *v1.Deployment
This causes the YurtAppSet controller to crash during reconciliation and enter a crash loop.
⸻
Steps to Reproduce
Fix Applied
The unsafe type assertion was replaced with a type switch that supports both workload types:
• *appsv1.Deployment
• *appsv1.StatefulSet
For each workload, the controller now correctly extracts:
• replicas
• ready replicas
• updated replicas
• workload revision hash
Unknown workload types are skipped safely with a warning log instead of crashing the controller.
This preserves existing behavior for Deployments and correctly enables StatefulSet support.
Impact
Testing
Important: This + Your Previous Fix = STRONG Profile
You now have:
These are core controller reliability fixes — not docs, not trivial bugs.
For CNCF LFX Mentorship, this is exactly the kind of contribution mentors look for.
If you want, next I can help you with: