DanielePalaia
commented
3 months ago Regarding this issue after some exploration/research done:
The operators deployments can't be edited directly (adding env variables or mounting volumes ecc..) because the csv (cluster service version) will revert the modifications back. We can directly modify the csv, the csv will upgrade the deployment. The issue with this strategy is that whenever the operator get upgraded (with a newer version) OLM is reverting back the deployment modifications done.
A persistent solution is that the deployment can be overridden with the Subscription itself for some fields like env and volume/volume mounts: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/subscription-config.md#configuring-operators-deployed-by-olm
This fields are the ones we need for our scenarios (adding env variables to the container for example for the vault scenarios) or mounting a volume for the messaging operator in case of tls.
I tested this strategy and is working fine.
Is your feature request related to a problem? Please describe.
Like tls, vault ecc (this issue as an example https://github.com/rabbitmq/messaging-topology-operator/issues/500)
It looks like we can't directly modify a deployment but the csv which will eventually modify the deployment.
To see if this has some drawbacks on upgrade for example or some other edge cases to cover
Describe the solution you'd like
Nothing in particular, to better tests all these scenarios
Describe alternatives you've considered
No response
Additional context
No response