ratify-project
Why can't both tag and digest mutually exist?
What happened in your environment?
Tag is removed from the image name if both tag and digest exists.
What did you expect to happen?
Why is the tag removed and only digest kept? Why can't both exist mutually? Is there a special reason as to why the tag is removed? In a similar case with tags being mutated to digest; can't we keep both tags and digest in the name? The digest will be automatically used by K8s and the tag ignored. Keeping the tag makes it easy for devs to debug. Only having digests makes it harder during debugging, and only keeping digest doesn't seem to have any special benefit over having both?
What version of Kubernetes are you running?
No response
What version of Ratify are you running?
No response
Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this bug fix?
- [X] Yes, I am willing to implement it.
@emalprokt thanks for reaching out! We've discussed this issue in the community meeting. Before moving on, just wonder if you're asking to support docker reference convention like: <image>:<tag>@<digest>. And is keeping the tag for debugging purpose?
Hi @binbin-li ,
Sorry for the late reply. Yes, I'm asking to support convention like <image>:<tag>@<digest> for debugging purposes so its easy to know which tag is deployed. Even though the tag can be present, digest will be used instead and tag can be there for debugging purposes.
Currently, it's very difficult to know which image is deployed and cross-checking with the image repository can sometimes give very confusing results.
@emalprokt I did some investigation, seems docker/containerd support reference in format <image>:<tag>@<digest> just for backward compatibility, which is not a recommended option. Since you just wanna find out the mapping between tag and mutated digest, as a workaround I wonder if we can log the corresponding digest and tag in mutation workflow to make debugging a bit easier.
@binbin-li Thanks for the prompt response, Logging during the mutation workflow is helpful if the debugging engineer (who owns the image and/or the system that uses the image) and the engineer who deployed Ratify & its corresponding logging are on the same page. This needs interaction and communication between the two systems and people. This can cause friction and lag.
Something that exists as a reference throughout the lifetime of deployment of the image would be more helpful than a log.
Maybe the mutator can add a label in the spec we're mutating to specify the tag that was mutated?
@emalprokt Thanks for following up! If I'm understanding correctly, engineers who deployed an image may not have access to Ratify logs. In this case, the engineer does not know original tag of the deployed image.
We bring this issue into the community discussion today, and agreed to support mutating a tag to tag@digest for debugging purpose. But it's better to have a configurable option to enable/disable it like how we enable/disable mutation feature.
Since you're willing to implement it, could you post a brief proposal on user scenarios and how you plan to implement it, thanks!
@binbin-li Thanks for the approval. I'll submit a design doc soon. Thanks.