search

docker / roadmap

Welcome to the Public Roadmap for All Things Docker! We welcome your ideas.
https://github.com/docker/roadmap/projects/1
Creative Commons Zero v1.0 Universal
1.46k stars 246 forks source link

Deprecation of Advanced Image Management #534

Closed matwilsondocker closed 4 months ago

matwilsondocker commented 10 months ago

What? The Advanced Image Management feature allows managing the contents of a repository. Please note: not to be confused with Image Access Management here

When? The feature along with its API will be removed in the coming months.

What to use instead Users can continue to use the "Tags" view's functionality to manage their repository content. We will continue to look into alternatives and invite feedback and suggestions via our Public roadmap.

thaJeztah commented 9 months ago

Can we add deprecation banners on the relevant pages in the documentation?

edmorley commented 7 months ago

The Advanced Image Management feature is currently the only way to view/manage older versions of a tag.

I presume this functionality will be added to the tags view, before the Advanced Image Management feature is sunset?

mbentley commented 7 months ago

I was wondering the same as @edmorley. It's actually one of the main reasons I currently pay for a Docker Pro account.

hydrusbeta commented 6 months ago

Like @mbentley, being able to see older versions of a tag is one of the main reasons I pay for a Docker Pro account, too. Having knowledge of old tag digests is valuable when I accidentally break something for a small number of end users. I can give them the digests of older tags so they can continue to pull the older images until I fix the issue in the next release. Deprecation of Advanced Image Management is 2 days away and I don't see any way to view older tags in the Tags view. Since I won't be able to get digests from Docker Hub any more, I suppose I'll have to keep track of image digests myself. Either that, or I'll have to start giving every build a unique tag.

timpwbaker commented 6 months ago

Just been burned by this, it was part of our rollback process too. Disappointing to see it get removed without an alternative to see history.

mbentley commented 6 months ago

@matwilsondocker - it's pretty disappointing that there is no replacement feature or justification for the removal. Was this somehow causing significant cost for you all in some way?

I know it's only $7/mo but I am discontinuing my Docker Pro subscription because of the removal of this feature. If that means I end up hitting any of the pull limits, I'll then be seriously considering moving my 170+ public images to another registry.

sheltongraves commented 6 months ago

The decision to deprecate Advanced Image Management was made in our ongoing efforts to enhance and improve the user experience, security, and maintain the platform's efficiency. We appreciate your feedback and the development of a feature to replace this functionality is actively on our roadmap.

xcolwell commented 6 months ago

It has been extremely hard to follow this. Users are seeing 404 but no idea why, e.g. https://forums.docker.com/t/suddenly-getting-a-404-from-dockerhub-api-when-trying-to-access-repository-images/138899 . The API docs make no mention that /images is deprecated. It would be really helpful to document this in the API docs. Most people read the docs not the roadmap notes.

rimelek commented 6 months ago

Although I didn't use this endpoint, I tried to help users on the forum and I understand why this change was a problem. There was an API version v1 which was retired and replaced by v2. There is a page in the docs which shows the v2 alternatives to v1 endpoints:

https://docs.docker.com/docker-hub/api/deprecated/

This still shows the "images" endpoint. That's not the problem as that was about deprecating v1, but the API version didn't change while an endpoint was removed. That could make users wonder what a version number means and how stable the API is. The API reference shows its a Beta, so maybe you could use v2beta1 v2beta2 in the URL instead of just v2 and have a "release cycle" page in the documentation for the API. On the other hand, if it changes frequently, it would require users changing their API endpoint frequently so maybe not the best solution for those who use one actually stable endpoint.

You could also either return a message for a month containing the reason why it is missing instead of returning HTTP 404 or introduce some kind of "deprecation_status" or "available_until" field when you know you will deprecate and remove an endpoint so users can check that and implement notifications for themselves so they have time to change their code. As @xcolwell wrote, people will not read the roadmap, but even if it is mentioned in the documentation, they won't read it unless they want to find something in it :)

lopesrichard commented 4 months ago

Any update on this? You can't just remove a feature used in rollback systems and not give an alternative.

sheltongraves commented 4 months ago

While I don't have a specific timeline for the release of this alternative solution, this is something our development team is actively working on.

stepheUp commented 4 months ago

The release note now also includes API endpoints that were removed : 2023-12-11

rysearle commented 4 months ago

While I don't have a specific timeline for the release of this alternative solution, this is something our development team is actively working on.

@sheltongraves is there an issue for tracking progress on the alternative solution?

sodul commented 1 month ago

We are no longer able to delete older tags in our private repositories. Having APIs to evolve is ok, but being able to delete stale tags is a basic functionality which should still be provided.