-
Notifications
You must be signed in to change notification settings - Fork 1.3k
fix(cache): preserve CacheRuntimeClass template resources when unset #6165
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -195,9 +195,9 @@ func (e *CacheEngine) syncRuntimeSpec(ctx cruntime.ReconcileRequestContext, runt | |
| manager := component.NewComponentHelper(common.ComponentTypeMaster, e.Client) | ||
| // Only sync resources if they are explicitly set (not zero-value) | ||
| // This prevents overwriting template defaults when user hasn't specified resources | ||
| var resources corev1.ResourceRequirements | ||
| var resources *corev1.ResourceRequirements | ||
| if runtime.Spec.Master.Resources.Requests != nil || runtime.Spec.Master.Resources.Limits != nil { | ||
| resources = runtime.Spec.Master.Resources | ||
| resources = &runtime.Spec.Master.Resources | ||
|
Comment on lines
+198
to
+200
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks — the behaviour change is real. I've added the measurements to section 4. "Never set" and "removed after being set" are byte-identical in the CacheRuntime spec, so syncRuntimeSpec can't tell them apart by construction. Before this PR both meant "clear to {}", which wiped the template's values — that's #6161. After it, both mean "leave it alone". Step 3 in the table is your case, and I'd rather leave a stale limit than silently drop a cap the admin declared. The tri-state actually already exists after this change, no API change needed: omitting the field leaves the workload alone, resources: {requests: {}} clears it (I checked — empty maps survive CRD pruning and deserialize non-nil, so they pass the guard), and a set value gets applied. What's missing is falling back to the template on removal. That needs the desired pod template computed through the transform chain and diffed against the live one — the follow-up described in the PR body, which also covers the processMemory problem. updateResources and its unit test are untouched here. Happy to add a test pinning the explicit-clear path if you want it as a contract. |
||
| } | ||
| masterSpec := component.ComponentSpec{ | ||
| Version: runtime.Spec.Master.RuntimeVersion, | ||
|
|
@@ -219,9 +219,9 @@ func (e *CacheEngine) syncRuntimeSpec(ctx cruntime.ReconcileRequestContext, runt | |
| manager := component.NewComponentHelper(common.ComponentTypeWorker, e.Client) | ||
| // Only sync resources if they are explicitly set (not zero-value) | ||
| // This prevents overwriting template defaults when user hasn't specified resources | ||
| var workerResources corev1.ResourceRequirements | ||
| var workerResources *corev1.ResourceRequirements | ||
| if runtime.Spec.Worker.Resources.Requests != nil || runtime.Spec.Worker.Resources.Limits != nil { | ||
| workerResources = runtime.Spec.Worker.Resources | ||
| workerResources = &runtime.Spec.Worker.Resources | ||
| } | ||
| workerSpec := component.ComponentSpec{ | ||
| Version: runtime.Spec.Worker.RuntimeVersion, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When calculating resource requirements, should we consider the configuration of runtimeclass?
We need to clarify in the document how the resource defined in runtimeclass and runtime takes effect, and how changes affect the final resource calculation.
My thought is: we will first take the not nil resource value defined in the runtime (high priority) or runtime class. If both nil, then the value is nil.
So,
@cheyang What Do You Think?