Is it possible for imagepolicies to differentiate between images and Helm charts?

[Mo0rBy]

I've come across this problem quite recently and looked at the documentation and generally around the internet to see if my understanding is correct.

In my cluster, I am using images and Helm charts pulled from an AWS ECR (which is OCI compliant). I am using imagepolicy and imageupdateautomation objects to automatically commit the latest version of an image or Helm chart tag.
I have my AWS ECR's setup like myEcr/myApp1, myEcr/myApp2, etc and each ECR can store many images and Helm charts for that particular service.

My issue arrises from the fact that my image tags and Helm chart tags follow the same format, meaning that both my imagepolicy's for myApp1, for example, are updating at the same time. It looks like Flux is unable to differentiate between a tag for an image object and a tag for a Helm object.
Now, I'm no expert in OCI compliance, but I think you can know if a tag is for an image or Helm chart from the metadata you get back from the registry.

Here are some AWS docs on Helm charts in OCI compliant ECR service: https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html

and this doc states in step 7 that "In the output, verify that the artifactMediaType parameter indicates the proper artifact type", showing that the aws ecr describe-images command gives you the relevant metadata to know if the artifact type is a Helm chart or an image.

Would it be possible to add a feature to Flux such that imagepolicies can filter for specific object types.

If this is not possible, then I'm just going to add a suffix to all my Helm chart tags with -helm, as I think that would be the only way to segregate the tags according to the filterTags.pattern value.

[stefanprodan]

Flux simply lists tags, so you need to use some prefix. We cannot pull manifests of every single tag to look at their oci type, this would create enormous traffic.

[Mo0rBy]

Ok thanks @stefanprodan .

It would need to be a suffix not a prefix as Helm charts are required to start with a semver format, but they can have whatever you want after the initial semver.

I'm not sure if this is a limitation within Helm or something to do with OCI compliance or something else, I just know that it's required from experience.

EDIT: Helm charts are required to follow the semver 2.0 format and it is a restriction imposed by OCI compliance.

[matheuscscp]

Why not just use two separate ECR repos?? It doesn't cost extra, does it?

[stefanprodan]

It is super confusing to push the app and chart to the same repo with same semver tags, never seen this before. How would you tell between “app:1.0.1” and “app:1.0.2” which one is the app image and which one is the chart? What if the versions end up to be the same? The chart will simply override the container image and the deployment will fail.

[Mo0rBy]

@matheuscscp Getting that change to happen requires me to go to another team, and they are a headache to deal with, so I just don't want to. Plus it would mean some large blanket changes across our Kubernetes cluster and CI/CD pipelines, which I also don't want to deal with.

I just have to take away the lesson that image and Helm chart repositories should be kept separate.

[Mo0rBy]

@stefanprodan the tagging mechanism was different until recently and now we have this issue of some images now have the same tagging format as all our Helm charts.

I wasn't aware that there would be a problem with this until now. Hence why I started this discussion, because it is possible to have 2 tags with 1.0.1 in AWS ECR, as long as they are different artefact types (e.g. 1 image, 1 Helm chart). I was hoping Flux would be able to gather that metadata and use it filter tags for only images and only Helm chart objects.

Well that was a lie ^^