Comments (8)
I see tags carrying classifying information, tagging an image with production
vs staging
makes a difference. For floating tags I still wish to distinguish between two different versions of an image tagged with the same tag. Seeing the tag alone doesn't give me tracking, and not seeing the tag doesn't give me the classifier. Having both I can reason about an image that is classified for production
being of certain version via the hash. Seeing that in an image reference I can be sure that the right image gets deployed to the right environment with the expected version.
I don't really care how this is handled internally as outlined in the two different ways Docker handles it on the comment you linked. I'd like to use that :tag@digest syntax and I'd like to propagate it throughout all the tools I use, skopeo being one of them and the issue of skopeo not supporting this syntax originates from containers/images.
Seems to me like the second option of, disregarding the tag if the digest is specified would not be difficult to implement, if that's something the project is willing to accept I'd be happy to contribute a pull request.
from image.
Thanks for your report.
Yes, and that’s mostly intentional.
The historical reasoning is containers/buildah#1407 (comment) .
Since then, https://github.com/moby/moby/releases/tag/v20.10.20 has changed again to the older and less problematic “require both the tag and digest to match” behavior; so that at least removes the strongest reason to completely and strictly reject such input.
Still, now we have to worry about c/image users assuming that valid references only have one of (tag, digest), being broken if c/image starts accepting both. That’s just a worry, not a complete show-stopper.
But then the benefit of accepting the :tag@digest
syntax, in the first place, is unclear — in which situations does the consumer, which has a specific digest pinned, really care that the tag still exists and points to that tag? Would the consumer not be better off removing the tag from the input, and keeping the deployment/build process working even if the tag is moved?
So… I think it’s definitely worth discussing, but it’s not obvious to me that it’s worth the risk and review effort.
from image.
Are you saying that you want to intentionally, simultaneously, use image:production@digest1
and image:production@digest2
?
That’s seems so disconnected from how the registries actually operate that I think that should be strictly rejected. The tag field is not a general-purpose comment storage space.
from image.
I don't care how registries operate, I care how the tools are used. I want to be certain that an image tagged with production
of a certain digest is the one I'm operating on. Not given that opportunity I'll need to resort to using digests or tags alone. Given tags or digests alone I can't tell looking at the image reference if the image in question is for production
and the correct version.
I outlined the second option as easy to implement from the comment, I also offer to provide a pull request for the first option. Again, I'm happy to contribute this if there is a consensus in which direction the implementation should be heading.
Seems to me the trade-off is between correctness and compatibility, and one of those needs to give.
from image.
I don't care how registries operate, I care how the tools are used. I want to be certain that an image tagged with
production
of a certain digest is the one I'm operating on.
AFAICS that makes the rolling production
tag contradictory: it can’t be updated it to a newer digest because it would break production deployments. It just doesn’t work at the scale where deployments are automated and automatically re-started. Hence my “not a comment storage space” description. The deployment configuration must choose between deploying the tag, whichever digest it points to, and deploying the digest, whether or not the tag points to — or the practical certainty of downtime that could be avoided either of the two other choices.
Seems to me the trade-off is between correctness and compatibility, and one of those needs to give.
There are actually more layers to this: containers/common#1248 at a caller of c/image. c/common values compatibility more; but as the lower infrastructure, c/image is primarily in the business of reliably and correctly doing what the caller asks it to do, or refusing to do it if it can’t be done.
That c/common issue might end up requiring the c/image feature to be implemented, purely for compatibility. But it will remain a bad idea to use in production, IMHO.
from image.
Thank you for raising containers/common#1248, I'm looking forward to the conclusion there.
from image.
AFAICS that makes the rolling
production
tag contradictory: it can’t be updated it to a newer digest because it would break production deployments. It just doesn’t work at the scale where deployments are automated and automatically re-started.
Using digests to verify floating tags does have a use-case. You run test for a floating tag with digest, and if image passes tests, add non-floating tag for that digest. After which the floating tag can be updated. Digest is extra safety to make sure test results match the final tag.
Alternatives, and why they would be worse:
- Adding non-floating tag beforehand: a version/date tag is typically an indication of some extra testing being passed, so adding it beforehand and removing it later on if tests do not pass, is violation of that expectation
- Using just digest for testing: with a tag, it's much easier to see from e.g. logs which of the image variant is being tested and potentially causing trouble
(I assume it's obvious why digest for non-floating tags is desirable.)
from image.
Image tags nicely map to build-job ids (main-25) or git tags (1.20.5) and are human-readable. The digest is good for avoiding surprises in what actually gets run. Yes the VCS / build tag could be put in annotations, but the image name is much more readily available.
from image.
Related Issues (20)
- Docker client code can no longer talk to the latest verson of the docker daemon 25.0.0 HOT 5
- Allow empty OCI configs for artifacts HOT 9
- policy.json overwrite not honouring $XDG_CONFIG_HOME HOT 3
- Podman cannot pull image from local registry HOT 4
- copy.Options.EnsureCompressionVariantsExist doesn’t detect existing variants with zstd:chunked
- support multiple sigstore keys HOT 6
- How can I copy from a tar file stream HOT 7
- "slices" module only in go 1.21 HOT 1
- Cannot pull sigstore signed image with podman HOT 4
- Error inspecting local manifest-lists HOT 6
- platform.WantedPlatforms is noisy on macOS HOT 7
- Incorrect syntax highlighting in containers-transports.5
- Why do we get the whole image when inspect with docker daemon? HOT 2
- Support sigstore BYO PKI verification HOT 1
- Support more arbitrary credential helper executable names? HOT 4
- OCI image index loose the artifactType property on copy HOT 4
- zstd:chunked and layer encryption don’t make sense together HOT 3
- How to change the policy.json default path? HOT 1
- Mirrors are ignored when registry is blocked HOT 11
- Support Witnessing Sigstore Signing with a Timestamp Authority Server HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from image.