Closed siegfriedweber closed 6 months ago
The Helm installation does not have a requirement on the namespace. It would be possible to also set the namespace in the SecretClass where the operator is installed to, but if the secret-operator will be installed in another namespace then running products would break. So we decided, to keep the default namespace for the Helm installation.
IMO: The breaking rationale applies equally in both cases, but on Helm we can trivially put it in the target ns.
There is a PR that fixes this issue for the next SDP release.
I propose to move this issue to the track column until the next certification round.
Tested successfully on OKD/4.15.
This has beed shipped with 24.4.0-1
Sorry to bring this back from the dead, but: Do we have any migration documentation/release notes on this one?
Use the namespace
stackable-operators
in the SecretClasstls
in the OLM packageCurrently the namespace
default
is set which means that the secretsecret-provisioner-tls-ca
is generated in thedefault
namespace.Installing via OLM requires the operators to be installed in the namespace
stackable-operators
because the ClusterRoleBinding of the secret-operator points to this namespace. Therefore, it is consequent to keep things together and also create the secretsecret-provisioner-tls-ca
in this namespace.This is a breaking change which must be announced prominently. If pods would use different root CAs at the same time, they cannot communicate with each other anymore.
The Helm installation does not have a requirement on the namespace. It would be possible to also set the namespace in the SecretClass where the operator is installed to, but if the secret-operator will be installed in another namespace then running products would break. So we decided, to keep the default namespace for the Helm installation.