We are trying to update the service annotations of the mongos service by updating the spec.sharding.mongos.expose.serviceAnnotations field. However, we found that updating this field has no effect, the operator never updating the annotations of the service no matter what changes are done to the field spec.sharding.mongos.expose.serviceAnnotations.
We think this behavior is very confusing, since there is no message passed to the users. It would be much better if there is an error message passed to user when they try to change the serviceAnnotations. We suggest to make use of the new validation feature in Kubernetes: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules to directly reject users input at kubectl level. This feature is alpha is 1.23, and will be beta in 1.25. You can use the CEL expression to express immutability.
Expectation
We expected that our changes to the spec.sharding.mongos.expose.serviceAnnotations field will be reflected to the mongos service.
Reproduce
Deploy the percona-server-mongodb-operator
Deploy a mongodb cluster instance through some minimum CR, with some initial spec.sharding.mongos.expose.serviceAnnotations set:
Description
We are trying to update the service annotations of the mongos service by updating the
spec.sharding.mongos.expose.serviceAnnotations
field. However, we found that updating this field has no effect, the operator never updating the annotations of the service no matter what changes are done to the fieldspec.sharding.mongos.expose.serviceAnnotations
.We later dug into source code and discovered that the annotations are intentionally left out for service objects: https://github.com/percona/percona-server-mongodb-operator/blob/f7c117cf58830a42166c655c0b89249cb730b04a/pkg/controller/perconaservermongodb/psmdb_controller.go#L1693
We think this behavior is very confusing, since there is no message passed to the users. It would be much better if there is an error message passed to user when they try to change the serviceAnnotations. We suggest to make use of the new validation feature in Kubernetes: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules to directly reject users input at kubectl level. This feature is alpha is 1.23, and will be beta in 1.25. You can use the CEL expression to express immutability.
Expectation
We expected that our changes to the
spec.sharding.mongos.expose.serviceAnnotations
field will be reflected to the mongos service.Reproduce
Deploy a mongodb cluster instance through some minimum CR, with some initial
spec.sharding.mongos.expose.serviceAnnotations
set:Change the
spec.sharding.mongos.expose.serviceAnnotations
to some new annotation kv pair, and apply the CRRoot cause
We checked the source code and found that the annotations of service object are intentionally left out.
Environment
Kubernetes version information: