We are going to fix this with https://jira.percona.com/browse/K8SPSMDB-558.

In a nutshell we are going to ignore annotations changes.

Exceptions are always introducing complexity and maintenance cost. I believe that when you say "tolerate" it means that Operator should not do anything if annotation was added to the Service manually:

I don't see how to do it easily and without adding some weird logic. Do you have any ideas?

I agree with you though that we should:

1. Have it documented

   1. say that such manual annotation changes can cause the infinite loop

   2. provide an exact example with google could

2. Log such events properly

Hello
I understand this is the intended way and the workaround is quite straightforward. But maybe the operator could tolerate extra annotations ?

Also, it took me a while to find out the issue. Since the operator was constantly re-creating the service, the resource was always in a failed state with a connection error. It would be nice for the error message to be more accurate.
Or at least update the documentation because I used a standard GKE deployment, I think other will encounter this issue in the future

Hey @Guillaume Coupelant, thank you for submitting this.

Obviously it is intended behavior of the Operator: monitor the resources and primitives it creates and keep their state in sync with Custom Resource.

Adding this annotation into mongos definition would solve the case (spec.sharding.mongos.expose.serviceAnnotations).

Do you have something in mind how this can be tackled differently? 

Sorry, the first link was not formatted properly, here's the GKE feature: https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#container-native_load_balancing