[RFC] Attributes in image automation

[GregoireW]

Is flux image automation a good solution to extract additional data from image tag?

Signed-off-by: GregoireW 24318548+GregoireW@users.noreply.github.com

[dungdm93]

It would be nice if image SHA256 available.
In some case I wanna use app/foobar@sha256:294d69bb580a614ed3128969b95b5355c480e84704d826cdf73e790b5a6e63fc

[relu]

@GregoireW I'm sorry for the delay on this, I've started to review this and I'd like to resume the discussions. If you're still interested in contributing, would you be able to reach out to me in CNCF Slack workspace?

[relu]

Here are some suggestions after a first pass, I hope these help.

Thank you for putting this together!

[relu]

Would you mind changing this to something that more directly explains what the RFC covers? Something like "Flux should allow referencing more container image metadata attributes in the image automation Setters strategy"

[GregoireW]

I rewrote a little bit this part.

[relu]

Maybe change this to a list and add the digest information extraction under the umbrella of this RFC:

• Allow referencing filterTags pattern extracted parts from image policies
• Extract digest information and make it available in the markers Add image digests image-reflector-controller#214

[GregoireW]

I rewrote a little bit this part. But the Additional digest requires much more work. It would means downloading the image manifest for every tag then filter the correct one.
Manifest wouls also means access to OCI label and cleaner filter / attributes, but it may increase the database size (some build tools put a lot of data in label!)

[relu]

What would happen if we'd just use regular capture groups instead of named groups? Maybe we should be able to support that as well by referencing the indices?

[GregoireW]

I'm not found of regular capture group when the use of the capture is not in the same code space as the capture itself. The definition is on the ImagePolicy then the use is on a comment of another kubernetes object. What's 1, 2, 3 in this context... not sure. (I Am Not A Number, I Am A Free Man! )

[relu]

It might make sense to delimitate the attributes extracted from .spec.filterTags.pattern from the others to avoid any collisions or confusion.
I'm proposing we go with: # {"$imagepolicy": "{namespace}:{imagepolicy}:tagparts[{attribute}]", where attribute can be either a named capture group or a index number.

[GregoireW]

I think there is 2 aspects to consider:
The simplicity would means to use {namespace}:{policy}:{attribute} simple to read and to understand. I added a part on collision where a warning should be logged, but the value should remains as today norm.

The tag parts would be interesting if in the future multiple way to retrieve data would be permitted. For instance label from OCI container ... if you then be interesting to split "extracted attributes" to "manifest attributes". Or perhaps it would simply be a configuration on the ImagePolicy like "attributes X = json path in the manifest" which would kept Image Automation Controller simple.

[relu]

What should happen if the user would reference a non-existent attribute?

[GregoireW]

I guess a warning in the log and no update. BTW a capture producing empty attributes will need to be tested

[relu]

Since this heavily depends on what information image policies expose I think we need to detail how this would be implemented in the IRC as well.

[GregoireW]

@dungdm93

You mention you are interrested by the image digest. Can you elaborate on your use case ?