Image update automation parity with Flux v1

[squaremo]

Image update automation will work differently in Flux v2, since GOTK is oriented around custom resources and Flux v1 works entirely without them. The extent to which it's different is up for negotiation -- is it enough to support the same use cases, or should we aim for a close fit with existing configuration of Flux v1?

To help the discussion, here's a list of features of Flux v1's image update automation:

Flux v1	Flux v2 (so far / planned)
Image update
Automation is controlled with annotations on resources	Automation is controlled with ImageUpdateAutomation resources
Individual workloads are marked as automated	Individual images are set up to be automated; workloads can be selected (planned)
With fluxctl release, you can update arbitrary workloads with arbitrary images (whether or not marked as automated)	No fluxctl release equivalent at present (but could be part of a GitUpdateJob system)
You can lock a workload, meaning it can't be updated until it's unlocked	No equivalent at present
You can give containers within a workload a filter to select the acceptable images	ImagePolicy resources encode the filters
HelmRelease resources are also updatable	HelmRelease and possibly other custom resource types are also updatable (planned)
Image scanning
Credentials for image registries are picked up from imagePullSecrets	You can refer to credentials to use, in an ImageRepository resource (planned)
ECR credentials are requested from AWS IAM	You can specify that AWS IAM should be used for an ImageRepository (planned)
GCR credentials are requested from GCP	You can specify that GCP authentication should be used for an ImageRepository (planned)
You can mount a docker config and use that for credentials	You can refer to a Secret with credentials (planned); potentially could hostMount a config

[stefanprodan]

You can lock a workload, meaning it can't be updated until it's unlocked

Most GOTK APIs support toggling the reconciliation with spec.suspend. While it's not the same thing as locking a workload, the ImageUpdateAutomation should support suspend/resume and on-demand sync, similar to https://toolkit.fluxcd.io/components/kustomize/kustomization/#reconciliation

[squaremo]

Oh yes, have been meaning to add those. fluxcd/image-automation-controller#16 and fluxcd/image-reflector-controller#19

[stefanprodan]

Great 🎉

[squaremo]

flux v1: With fluxctl release, you can update arbitrary workloads with arbitrary images (whether or not marked as automated)
flux v2: No fluxctl release equivalent at present (but could be part of a GitUpdateJob system)

Stefan pointed out in a discussion IRL that you can achieve the same goal by pinning a particular ImagePolicy and letting automation do its thing.

Pros:

• does not involve another subsystem (jobs).
• no "locking" mechanism needed; this was introduced in Flux v1 because otherwise fluxctl release and automation would fight

Cons:

• would not support image and workload selection in the same way (no --all-images or whatever). This was at times a dubious feature of fluxctl release, because selection was sloppy and most things didn't qualify and get updated anyway. If there's specific bulk operations needed, they could be built into the ImageUpdateAutomation spec.

We'd need to take care that it's accessible from CI and from laptops, and put some user interface around it.