Skip to content
This repository has been archived by the owner on Oct 22, 2024. It is now read-only.

operator: specify resource requirements for operator pod #1067

Open
pohly opened this issue Feb 17, 2022 · 1 comment
Open

operator: specify resource requirements for operator pod #1067

pohly opened this issue Feb 17, 2022 · 1 comment

Comments

@pohly
Copy link
Contributor

pohly commented Feb 17, 2022

operator-sdk 1.16.0 adds a new "best practices" check. That one warns about our bundle:

$ _work/bin/operator-sdk bundle validate --select-optional=name=good-practices deploy/olm-bundle/1.0.2/
WARN[0000] Warning: Value pmem-csi-operator.v1.0.2: unable to find the resource requests for the container: (pmem-csi-operator). It is recommended to ensure the resource request for CPU and Memory. Be aware that for some clusters configurations it is required to specify requests or limits for those values. Otherwise, the system or quota may reject Pod creation. More info: https://master.sdk.operatorframework.io/docs/best-practices/managing-resources/ 
INFO[0000] All validation tests have completed successfully 
@pohly
Copy link
Contributor Author

pohly commented Feb 17, 2022

Once this warning is fixed, we probably should treat warnings as validation failures.

pohly added a commit that referenced this issue Feb 21, 2022
v1.16.0 added "good-practices" checks. Apparently optional checks cannot be
combined, so we now run validation twice. There is one
warning (#1067) which wasn't seen
earlier when using "make operator-validate-bundle" because warnings are not
treated as failures and the output was suppressed. Now we check for warnings
and at least show them, but still don't treat them as failure.
pohly added a commit to pohly/pmem-CSI that referenced this issue Mar 17, 2022
v1.16.0 added "good-practices" checks. Apparently optional checks cannot be
combined, so we now run validation twice. There is one
warning (intel#1067) which wasn't seen
earlier when using "make operator-validate-bundle" because warnings are not
treated as failures and the output was suppressed. Now we check for warnings
and at least show them, but still don't treat them as failure.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant