Support multiple global postgres-operators with filter on annotation

[pcallewaert]

This is a first draft, and is untested (I'm in the process of setting up some infra to test it properly). I already open this PR to get some early feedback.

Currently you can run multiple postgres operators, and configure which namespaces it should watch. Unfortunately I am having an use-case where the namespaces are dynamic.

I liked the idea of https://github.com/movetokube/postgres-operator/issues/46, but it seems to be stale, and it would also mean a major refactor with breaking changes.

This PR is just add the "basic" feature of running multiple postgres-operator's that can watch all the namespaces, but with a filter on the annotation. We introduce a new config POSTGRES_INSTANCE, that defines the "filter" for the CR's. If this is defined the operator will only process the CR's with the annotation postgres.db.movetokube.com/instance, and where the value equals the configured value in POSTGRES_INSTANCE. If the config POSTGRES_INSTANCE is not set, it will process all CR's that have no annotation postgres.db.movetokube.com/instance. This means it should be fully backwards compatible with the current way of working.

I also updated to go 1.18, and had to updated the golang.org/x/sys package to be compatible with the new golang version. Dockerfile.dist is bumped to ubi8 (not sure if ubi7 still gets security updates?). If you want I can split up the PR for this.

Some thoughts:

• "Migrating" between postgres-operators is not supported (and I don't know if we even can). The CR has to be deleted (in kubernetes) first, then the annotation has to be added and then apply it back to kubernetes.
• ~~No idea how the code will respond if a Postgres is handled by operator X, and the PostgresUser by operator Y.~~ Added check for this

[pcallewaert]

I was distracted by another project, so didn't had time to follow-up on this, until today. Added some fixes, but it worked to manage different postgres database servers with running 2 different operators. The one was the default setup, and would process all the CR's without any annotations, the other one had POSTGRES_INSTANCE configured and only managed CR's with the correct annotation.

I still need to update the README, but would love to have some feedback if this is mergeable or not. @hitman99 ?

[hitman99]

Thanks for putting some work into this proposal. I was super busy since the January and will finally have some time to allocate to this project starting July

[pietervincken]

We'd also be interesting in this. We're currently using the operator to manage 1 central azure database, but we're evaluating moving to flexible server as well.

How can we help with this PR?

[hitman99]

I'm planning to review this and other PRs and issues on Monday 08-29 as it's long overdue.

[pcallewaert]

Hi @hitman99

I missed it that you reviewed this, I just processed your feedback.