keycloak deployment not removed on upgrade from 0.26 or below.

[k-wall]

The enmasse-operator removes the keycloak-controller deployment if it is detected, but the the keycloak deployment is left behind. I suspect this is an oversight. The operator should take care of its removal too.

[lulf]

The intention is that when you upgrade using ansible playbooks for instance, and standard authservice is enabled, the enmasse-operator will take ownership of the existing keycloak deployment rather than deleting it. This is to ensure that user database is not accidentally deleted on upgrades.

If you upgrade without creating an authentication service matching the existing keycloak deployment, then I agree the keycloak deployment should be deleted.

[k-wall]

The intention is that when you upgrade using ansible playbooks for instance, and standard authservice is enabled, the enmasse-operator will take ownership of the existing keycloak deployment rather than deleting it. This is to ensure that user database is not accidentally deleted on upgrades.

Ah.. Thanks for the advice. I was trying to upgrade using a YAML bundle. After the upgrade (oc apply -f install/bundles/enmasse) there was no authenticationservice resource. I applied the examples, which left me with the orphaned keycloak and its orphaned postgres.

However, I have since tried to upgrade again (starting from scratch) using Ansible (ansible-playbook -i enmasse-next/ansible/inventory/with-standard-authservice.txt enmasse-next/ansible/playbooks/openshift/deploy_all.yml). There is an authenticationservice created which detects my existing keycloak deployment, but the storage is wrong. It refers to h2 rather than my existing postgres.

If you upgrade without creating an authentication service matching the existing keycloak deployment, then I agree the keycloak deployment should be deleted.

[k-wall]

2857 makes improvements to improve the upgrade use-case