Steven Hawkins

> if the operator is controlling the service account it creates from the keycloak CR, i think it makes sense it would not accept an existing service account I might...

And the operator would also set this service account name on the StatefulSet? Can you clarify what you mean by the operator can only create the service account? Does this...

I'm not sure how 3 works in practice. I don't think the operator should delete / recreate arbitrary service accounts. If we delete and the original role bindings are left...

> if you error on the SA creation (because its already exist), then you don't set the serviceAccountName in the Statefulset. Should the user be responsible for naming the SA,...

> I think that the operator should generate the ServiceAccount name (best from a security point of view) Okay, I think we have a good understanding of what this enhancement...

The watching check was refined and is now more acurate. You should be careful using that as part of a health check as the status is ephemeral and is supposed...

If you never stop your informers, then isRunning=false would be a hard, and unlikely, error. hasSynced once true, won't flip to false again, so it belongs more to a startup...

I started on the operator controller logic again based upon this pr - a couple of additional thoughts: - specialization via subclassing will require separate controllers for each type. I...

> Does it mean we'd have a single Client CR? Yes it does. The other way to do this without a structural schema, and which is supported by the CRD...

> IMHO separate CRs are a better approach than a single one. It's better UX for the users that they see only fields relevant to given client type. After thinking...