Description of problem: While configuring resources section for CLO through the instance CR. I missed a letter 's' in resources and it took the config. ~~~ resource: limits: cpu: 2 memory: 32Gi requests: cpu: 2 memory: 32Gi ~~~ The CLO logs at the moment of the above change. time="2020-10-16T20:13:13Z" level=info msg="Elasticsearch resources change found, updating elasticsearch" time="2020-10-16T20:23:53Z" level=info msg="Elasticsearch resources change found, updating elasticsearch" time="2020-10-16T20:23:53Z" level=info msg="Updating status of Elasticsearch" W1016 20:25:59.821205 1 reflector.go:270] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:126: watch of *v1.ConfigMap ended with: too old resource version: 12885671 (12888851) time="2020-10-16T20:27:34Z" level=info msg="Elasticsearch resources change found, updating elasticsearch" time="2020-10-16T20:29:12Z" level=info msg="Elasticsearch resources change found, updating elasticsearch" The elasticsearch CR was still on its default value of 16Gi, ~~~ image: registry.redhat.io/openshift4/ose-logging-elasticsearch5@sha256:8736910d99141fc5698c4d3a754091be722ca6438b76f4f6a0e989cd81e79a9d resources: limits: memory: 16Gi requests: cpu: "1" memory: 16Gi ~~~ The moment I make the changes to the CLO CR and correct the word "resources" the changes are applied. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Configure CLO and cluster logging CR. 2. Include the resources value but make sure the keyword is mentioned as 'resource' 3. Save the config and the operator logs there is no error and only says config is updated as mentioned above. Actual results: Ideally an incorrect keyword should not allow the cluster logging CR to be saved and an error should be reported there itself. Expected results: Additional info:
Maybe resolved in 4.6 with schema validation. Need to validate
This is generally the behavior of all kubernetes resources to ignore fields the apiserver does not know about. This is user error in not crafting it correctly and the only recourse would be to create some sort of webhook to block admission.
Hello Jeff, I understand the concern but should the operator not give better error logging so that if someone tries this, atleast they get a warming from the elasticserach operator or cluster logging operator. We can include a validation for the custom resource so that a better error logging will have customers make the right change and also delete the incorrect keywords are unknowning getting added while the user is exploring the operator feature or updating the config with new resources. Let me know your thoughts on it. Thanks.