Feature request: Add policy for selecting as latest any alias tag that matches the `latest` tag

[aristapimenta]

When pushing new release tags to image repositories, it's a common practice to also update the special tag latest to the new release tag being pushed.

It would be really nice if ImagePolicy could have a policy option for selecting as latest some specific alias tag that points to the same image currently pointed by the latest tag.

My company uses git commit SHAs as image tags, and none of the three current policy options work great for this use case. For example:

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: podinfo
spec:
  imageRepositoryRef:
    name: podinfo
  policy:
    latestAlias: true

Then when I push the tag 90780e5f8f821983cdab22a6a528154e2e00a935 and also update latest to point to this tag, then 90780e5f8f821983cdab22a6a528154e2e00a935 becomes the latest tag choice of this policy.

This works much better than simply hardcoding imgrepo:latest in the deployment, because imgrepo:latest doesn't cause the pods to be restarted with a newer image when the latest tag is updated. By using the image update automation features of Flux I would be able to be specific with which version I'm running, and also cause the pods to be restarted with a newer version when the latest tag is updated in the image repository (because this event would be reflected as a config change in the deployment with the specific alias tag selected by the policy).

What if there are multiple tags matching the special tag latest at the moment? Which one to choose? For my specific use case this wouldn't happen, but for a more general solution then the same policy options already available could be applied for this subset of tags. For example:

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: podinfo
spec:
  imageRepositoryRef:
    name: podinfo
  latestAlias: true
  policy:
    alphabetical:
      order: asc

In this case latestAlias: true moves up under spec and then after filtering the tags by this criterion the other policies available for picking a specific tag could be applied.

[aristapimenta]

By the way when I use the word "alias" here I don't mean any particular feature of any particular piece of software, I just mean that all the image tags pointing to the same concrete image can be considered "aliases" of each other, i.e. just the meaning in plain English.

[relu]

Hello @aristapimenta and thank you for submitting this feature request!

I think this could be a valid use case for situations where users don't have the ability to change the tagging format and can only rely on the latest or other rolling tags. However, for other situations, where the user does have the ability to control the tagging format, I think it would definitely be better to use sortable image tags as it can be way more convenient and predictable.

This could probably be implemented better as a policy type (calling it rolling based on Bitnami's approach) and once we have latest tag digest implemented, we could just use that in the image update automation rather than pick one of the other tags associated with the latest tagged image.

A possible spec would look like this:

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: podinfo-latest
spec:
  imageRepositoryRef:
    name: podinfo
  policy:
    rolling:
      tag: latest # pointing to the tag to track

I would imagine a possible image automation configuration with setter markers would end up looking something like this: image: podinfo:latest@sha256:<digest> # {"$imagepolicy": "flux-system:podinfo-latest"} (note that this is not currently supported).

The only downside I see is that you will not be able to easily correlate the image tag back to the git commit from the workload state itself.

I'm positive this would work for your use case. Let me know what you think of this alternative implementation proposal.

[matheuscscp]

Thanks @relu, it's so exciting to see Flux moving forward so fast! I'm very happy to see that you actually already got covered part of the request with the digest fetching feature.

The only downside I see is that you will not be able to easily correlate the image tag back to the git commit from the workload state itself.

I'd say this is enough in most cases and if I was just by myself, that would definitely be enough for me. But we use git SHA especially to correlate images with git easily. Can I discuss this with my teammates and come back to you?

By the way, is the reason for this counter-proposal a technical limitation or is it just from a design perspective?

[relu]

By the way, is the reason for this counter-proposal a technical limitation or is it just from a design perspective?

A bit of both. From the design perspective, I think having this defined through a policy type makes more sense than introducing a new spec attribute, since there's no value in combining that with the existing policy types as the tag never actually changes so there's no reason to process the single-item list of tags. Note that I mentioned nothing about adjacent matching tags pointing to the same manifest as latest, the reason for that is explained below.

There is also a technical limitation because of the registry API as it doesn't allow us to retrieve a list of tags starting from a single tag. Tags are pointers to manifest digests and the relationship is unidirectional, discovering all tags that point to the same manifest is cumbersome and requires multiple calls being made to the registry API.

[aristapimenta]

Yeah I'd rather not add this unnecessary extra burden on the controller and on the registry API (and get rate-limited), definitely aligned with this choice.