-
Notifications
You must be signed in to change notification settings - Fork 162
Description
Proposal
Currently, all the image fields in the PerconaServerMongoDB CRD (spec.image, spec.backup.image, etc) are marked as required, which forces the user to always manually specify the images being used by the cluster.
However, if the user configures automatic updates (as recommended by the documentation), the image fields are de facto managed by the operator, and any value configured by the user is at best redundant (because it will sooner or later be overwritten by the operator) and at worst actively harmful (if the user accidentally specifies an image that does not match the selected auto-upgrade strategy), and causes conflicts with configuration management tools (i.e. GitOps).
It would be very useful if the user was allowed to omit the image fields entirely (i.e. make them optional in the CRD), in which case the operator itself would initialize them to an appropriate image based on the configured auto-update settings (or to some appropriate default if auto-update is not configured).
Use-Case
The original use-case I'm looking to get unblocked is using ArgoCD to manage a PerconaServerMongoDB resource that has auto-updates enabled. Currently the following issue happens:
- The manifest is committed to git, with auto-update configured to
8.0-recommendedandspec.imageset topercona/percona-server-mongodb:8.0.4-1(because if it's missing the CRD will fail to apply) - ArgoCD applies the manifest
- The database starts up normally; everything is fine up to this point
- Eventually, the operator checks for and finds a new minor version that the cluster can upgrade to (
percona/percona-server-mongodb:8.0.12-4) - The operator overwrites the
spec.imagefield in thePerconaServerMongoDBresource - The database updates successfully; however, ArgoCD now has the resource as out-of-sync, because the git manifest specifies
image: percona/percona-server-mongodb:8.0.4-1but the live resource hasimage: percona/percona-server-mongodb:8.0.12-4- Additionally, if ArgoCD is set to automatically sync the resource, it will immediately roll back the change to
spec.image, and the cluster is downgraded again to the original version
- Additionally, if ArgoCD is set to automatically sync the resource, it will immediately roll back the change to
The only ways to currently work around this is to either
- Immediately have someone update the git-stored manifest as soon as an update happens
- Defeats the point of automatic updates
- Configure the ArgoCD application to ignore the image fields
- Requires non-obvious configuration on every ArgoCD application that uses a
PerconaServerMongoDBlike this - Requires even less obvious configuration to make sure that the image field isn't overwritten by ArgoCD anyway whenever it applies the manifest for other reasons
- Requires non-obvious configuration on every ArgoCD application that uses a
- Configure ArgoCD globally to ignore the image fields in
PerconaServerMongoDBresources- Prevents any instance of the resource from manually specifying an image
- Still requires application-level configuration to avoid overwriting the field
None of which are particularly great in the long run.
Additionally, there are some simpler use-cases that also benefit from being able to omit the image field entirely:
- As a user deploying a new PSMDB cluster for testing, I don't particularly care what version or image will be used, I want the operator to choose a sensible one for me
- As a user deploying a new PSMDB cluster with automatic minor version updates, I want the operator to automatically create my cluster with the latest image according to my chosen update strategy, without needing to manually find the right image and/or wait for the next scheduled update check
Is this a feature you are interested in implementing yourself?
No
Anything else?
It is worth noting that many major database operators out there support this kind of image defaulting.