Add configurable container resource requests and limits via CR spec#27
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: omkarjoshi0304 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
689bf70 to
afd7706
Compare
afd7706 to
66f5db6
Compare
|
/retest |
1 similar comment
|
/retest |
lpiwowar
left a comment
There was a problem hiding this comment.
Just very quickly skimmed through it and there is one thing that crossed my mind we should try IMO but overall I like the PR 👍.
479d7e8 to
652455c
Compare
|
/retest |
228d137 to
b529180
Compare
328b200 to
df8997a
Compare
| lightspeedStackLogLevel: ERROR | ||
| dataverseExporterLogLevel: ERROR | ||
| resources: | ||
| consolePlugin: |
There was a problem hiding this comment.
question: Why aren't we testing the resources setting also for other pods / containers (e.g., lightspeed)? Also, I think we could validate in the 03-assert-openstack-lightspeed-instance.yaml that the default resource requests and limits were set on the pods / containers.
There was a problem hiding this comment.
oh I'll add resource overrides for llamaStack and lightspeedService as well
Add a Resources field to OpenStackLightspeedSpec that lets users override CPU/memory requests and limits for each container managed by the operator. Defaults are applied by the API server via kubebuilder:default markers on ContainerResourcesSpec fields; any user-supplied value replaces the default entirely. Extend the update-openstacklightspeed kuttl test to exercise resource overrides for consolePlugin and postgres (separate reconciler paths) and assert custom values propagate to deployment specs.
df8997a to
bd3a911
Compare
|
/retest |
Summary
This adds a
spec.resourcesfield to the OpenStackLightspeed CR that accepts per-containercorev1.ResourceRequirementsoverrides following the same pattern used by other openstack-k8s-operators (e.g. test-operator). Defaults are declared via kubebuilder:default markers on the API types, so the API server sets them automatically — no fallback logic needed in the controllers.How it works
Example CR
Test Proof