This issue is transcribed from https://github.com/3scale/3scale-operator/issues/570

We're deploying 3scale via the operator's APIManager CRD, using the "external databases" (HA) topology, which places the database & cache dependencies outside the cluster. Per the instructions for this deployment topology, we need to pre-create a number of secrets so that they contain valid connection strings for these dependencies. When we do this using standard Secrets, everything works fine.

However, our preference is to deploy using a GitOps workflow, which includes using SealedSecrets in place of Secrets directly. When we deploy, the SealedSecrets controller successfully creates Secrets from the SealedSecrets CRDs. BUT, when we then proceed to create the APIManager instance, deployment fails, with the 3scale operator pod reporting errors in its logs along the lines of the following:

{"level":"error","ts":1611727646.4785838,"logger":"controller_apimanager","msg":"Error setting OwnerReference on object","APIManager Controller":"apimanager","Kind":"/v1, Kind=Secret","Namespace":"3scale-staging","Name":"backend-redis","error":"Object 3scale-staging/backend-redis is already owned by another SealedSecret controller backend-redis"...}

This occurs for both the backend-redis & system-redis secrets.

If we manually remove the ownerReference for the SealedSecret controller from each of the Secrets, the APIManager deployment works fine.

Given that, for the HA topology, these secrets need to be pre-created, why does the 3scale operator seem to need exclusive ownership of the secrets? Short of either NOT using SealedSecrets, or including removal of the SealedSecret controller ownerReference post Secret creation, are there any options for the 3scale operator NOT to behave in this way?

Since ownerReferences can include multiple ownerReference, can 3scale-operator and another owner coexist?