Comments (6)
@mjgallag I generally agree with you and share in your frustrations here.
One would like to be able to manage image lifecycle via Docker Registry HTTP API V2 which tools like skopeo & reg use. Deleting an untagged image works just fine and is great for when tag is moved from an old sha to a new one. The problem is that Docker Registry HTTP API V2 doesn't support deleting tags separately from shas, see containers/skopeo#489 (comment).
So we've been discussing some of this over in the OCI world, and the draft distribution spec includes the ability to delete tags: https://github.com/opencontainers/distribution-spec/blob/e734841aa1c74860e6371086cdaf5d52ec220602/spec.md#content-management
The distribution spec is intended to be an evolution of the registry spec, as there are some inaccuracies and outdated information in the registry spec.
So when your intention is to delete a tagged image you cannot do so in GCR/GAR without first figuring out the GCR/GAR specific API call to delete a tag (ugh). I can understand the desire for this safety mechanism rather than just removing the tags along with the sha. But, ideally, when deleting via Docker Registry HTTP API V2, GCR/GAR would go ahead and just delete the tags along with the sha to allow for interoperability.
You'll perhaps find it even more frustrating that it is impossible to delete anything from Docker Hub via the registry API, at all.
The decision around requiring explicit tag deletion was made before my time, and I doubt we would change that behavior now, given that some customers likely rely on it. I understand the desire for compat here, but I also don't want to break anyone.
I would be open to some standard headers or error messages that communicate what a client needs to do in this situation. You can imagine some HTTP header that is the equivalent of --force-delete-flags
from gcloud, or even a standard error response body code/body that indicates exactly which tags need to be deleted (or which manifest lists still reference the image).
There's some discussion in the distribution spec around improving tag deletion, if you're interested in joining in: opencontainers/distribution-spec#114
from docker-credential-gcr.
Since it is internal I'd like to find a way to easily identify and delete unused images, i.e. garbage collection. If I can't find a flow that works with the current spec I'll definitely join in there.
I've been pushing on this problem for a while. I put together a rough proposal as a starting point here: opencontainers/distribution-spec#222 (comment)
I haven't been able to get much feedback from registry folks other than Steve bikeshedding it, but I'll be happy to put together a proposal PR once I can get some rough consensus on it.
from docker-credential-gcr.
@jonjohnsonjr ugh, thanks for trying to push this thru! I'm focusing on some other parts of the CI/CD work I'm doing at the moment but I will likely get back to the image garbage collection piece within a few weeks as I see it as a requirement for MVP. The company that'll be making use of this first is already on Google Cloud so I'll very likely drop directly to into GAR API as needed but goal is, of course, to standardize.
from docker-credential-gcr.
I don't think this repo is the right place for this issue, you probably want skopeo?
from docker-credential-gcr.
@jonjohnsonjr not sure this is exactly the right repo either but I just hit this issue as well and would love to hear thoughts from GCR/GAR perspective. One would like to be able to manage image lifecycle via Docker Registry HTTP API V2 which tools like skopeo & reg use. Deleting an untagged image works just fine and is great for when tag is moved from an old sha to a new one. The problem is that Docker Registry HTTP API V2 doesn't support deleting tags separately from shas, see containers/skopeo#489 (comment). So when your intention is to delete a tagged image you cannot do so in GCR/GAR without first figuring out the GCR/GAR specific API call to delete a tag (ugh). I can understand the desire for this safety mechanism rather than just removing the tags along with the sha. But, ideally, when deleting via Docker Registry HTTP API V2, GCR/GAR would go ahead and just delete the tags along with the sha to allow for interoperability. One could see this error still being enforced by Google for non Docker Registry HTTP API V2 delete calls if desired. Thanks in advance for your thoughts.
from docker-credential-gcr.
@jonjohnsonjr thanks for pointing me to the new spec. I'm definitely going to look at that more closely as I try to figure out a reasonable spec compliant image lifecycle flow, specifically for images consumed internally by CI/CD. I'm building on every push in every branch so storage requirements can quickly grow. Since it is internal I'd like to find a way to easily identify and delete unused images, i.e. garbage collection. If I can't find a flow that works with the current spec I'll definitely join in there. Then I'll move to nudging various container registries to fully support the spec.
from docker-credential-gcr.
Related Issues (20)
- Fix auth test issue
- Handle reauth / invalid_rapt errors more gracefully
- Release versions messed up?
- Non $PATH setup HOT 2
- "Could not retrieve GCR's access token" when using Workload Identity
- OOB OAuth just got turned off HOT 16
- Unable to install a pinned version using `go install` HOT 9
- Seems that Artifact Registry username has changed HOT 3
- Adding an option to extend the life of the token HOT 1
- Output contains invalid Username for AR when installed using normal `go install` HOT 1
- Unable to use binary built from source HOT 1
- Missing version number when running `docker-credential-gcr version`
- Check for either podman or docker in $PATH HOT 2
- Update docker-credential-gcr version in the google cloud sdk install tarball HOT 1
- Use ldflags to set version
- All v2.0.4 binaries have unexpected SHA256 checksums HOT 5
- Crash when used by Kaniko in Google Cloud Build HOT 2
- Wrong version using component install of Cloud sdk HOT 2
- No release artifacts for v2.0.5? HOT 3
- Does this support Identity Federation from external accounts? HOT 4
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 docker-credential-gcr.