define ownership between operator and clusters via annotation

[FxKu]

to run more than one operator next to each other without interfering

could also be used to detach a cluster from the operator

[sdudoladov]

the Namespaces section of the operator doc should also mention that there are now 2 complementary ways to isolate operators: namespaces and ownership annotations

[sdudoladov]

1. Why does this PR use annotations and not labels ? From Annotations docs:

You can use either labels or annotations to attach metadata to Kubernetes objects. Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify and select objects.

Here we employ the controllerId to split PG clusters into groups managed by different operator instances. Using labels can eliminate filtering out irrelevant clusters in the operator code

[sdudoladov]

also one needs to carefully configure separate operator instances to use different CRD / configmaps ; when the ownership annotations are used

[FxKu]

1. Why does this PR use annotations and not labels ? From Annotations docs:

From our K8s experts: "Labels are for humans, annotation for robots. The whole class etc patterns are based on annotations in all controllers!"

[FxKu]

also one needs to carefully configure separate operator instances to use different CRD / configmaps ; when the ownership annotations are used

That's up to the user. Multiple operators can share one ConfigMap/CRD or use their own dedicated configuration.

[FxKu]

the Namespaces section of the operator doc should also mention that there are now 2 complementary ways to isolate operators: namespaces and ownership annotations

Hm, I mean the two paragraphs are next to each other. I think, it's fine. I did not want to advertise the feature too much as it should be used with care.

[sdudoladov]

👍

[FxKu]

👍