Skip to content

Allow image fields to be omitted from PerconaServerMongoDB resource #2134

@tmarback

Description

@tmarback

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-recommended and spec.image set to percona/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.image field in the PerconaServerMongoDB resource
  • 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-1 but the live resource has image: 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

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 PerconaServerMongoDB like 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
  • Configure ArgoCD globally to ignore the image fields in PerconaServerMongoDB resources
    • 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions