Implicit scanning for image update automation

[squaremo]

One thing in favour of the way automation works in Flux v1 is that the specification is right there with the resources, so if you want to change it, that's where you go; and if a workload is removed, so is the scanning and automation.

I think it would be possible to recreate a similar system by a/the controller examining the workloads in git, and creating ImageRepository and ImagePolicy objects as necessary, then using those as the reference for updates.

For example, an ImageUpdateAutomation object might look like this:

kind: ImageUpdateAutomation
spec:
  gitRepository:
    name: config
  update:
    calculateFromAnnotations: {}

Then, for a suitably marked-up workload,

kind: Deployment
metdata:
  annotations:
    automated.toolkit.fluxcd.io/server: true
    tag.toolkit.fluxcd.io/server: 'semver:1.1.x'
spec:
  template:
    spec:
      containers:
      - name: server
        image: helloworld:1.1.0

the controller would create an ImageRepository pointing at helloworld and an ImagePolicy with semver 1.1.x; and when the latter had a latest image to report, it would update it in the workload.

Pros:

• continuity

Cons:

• complicated

Unanswered questions:

• where do credentials come from?

[squaremo]

I think the design in #107 (comment) has the desired properties -- instead of annotations, the fields for updating are marked with field metadata (a kyaml term for JSON-formatted comments).

In that design, the image policies are not derived from the manifests or resources themselves, so it does differ from Flux v1's scheme in that respect. I think it would be possible to scan the field metadata in manifests to create the image repos and policies, but perhaps for consideration later.