44,178 separate tags listed for envoyproxy/envoy on docker hub

[utopiasedge]

Title:
Unable to find desired images due to overwhelm

Description:
I went to Docker Hub when I noticed that the auto complete while trying to pull an image was taking a long time and consuming a lot of resources.
At present, "latest" images start at the bottom of page 44 (25/page) and there's 1768 pages. So there's ~1100 images since "latest".

[adisuissa]

cc @phlax

[phlax]

not sure there is much we can do about this although open to suggestions

the problem is created by publishing the dev images - which happens from every push to main

we did previously publish variants to separate repos - but tbh i think its better with them in one - we also added information about the images to our releases to make it easier to find them

[utopiasedge]

I think at the core this ends up being a question about use cases. And I know nothing of the history or anything other than my own use case. I was just trying to find an envoy image to use and was unable to find the version number of the most recent stable without a LOT of extra steps.

And sure, for a developer having all the incremental images easy to hand is probably helpful, but for someone who has exactly no knowledge of envoyproxy's internal workings: It was unusually difficult to find the information I was looking for. Namely: envoyproxy/envoy:v1.33.0

And the current information about the releases on Docker Hub is out of date by 2 minor versions:

If the purpose of the envoyproxy/envoy repo is to provide people with the image they need as quickly as possible, then making things super easy for the core maintainers and much harder for the noobs doesn't advance the goals. I don't care if you waste Docker's storage with images that no one is using, but can you not do it in your main repo?

---

So, after looking into this more, I think there are two main issues, one is unnecessary duplication without a pruning policy, the other is not respecting a proper tree structure with the variant repos.

I went and drilled down into a semi-random recently updated tag: distroless-dev and found that yes, there's the envoyproxy/envoy:distroless-dev images, but those 2 images(amd64+arm64) are also available in at least 3 other tags.

Here's the envoyproxy/envoy tags:

And yes, the variants are CURRENTLY being published to separate repos. 22 variant repos have been updated this year out of the 34 total.

So looking at the envoyproxy/envoy-distroless-dev repo, the two most recent tags are the same images as envoyproxy/envoy:distroless-dev

So, those images are available in 4 places:
envoyproxy/envoy:distroless-dev
envoyproxy/envoy:distroless-dev-cedb633dafc8fe69cb52098a8db2527126db9ee7
envoyproxy/envoy-distroless-dev:latest
envoyproxy/envoy-distroless-dev:cedb633dafc8fe69cb52098a8db2527126db9ee7

I would argue the second one shouldn't be created in the first place, as there's minimal use cases for it that cannot be served by one of the other 3. The only difference between 2 and 4 is swapping a - and : so it shouldn't be too hard for anyone to adjust.

Additionally, I would recommend moving the first one to envoyproxy/distroless:dev-latest.

The variant repos shown here aren't getting each dev image pushed to them.

These only have the stable versions. So why are dev images being pushed to the top of the tree constantly?

As I see it:

envoyproxy/envoy should just have the stable versions and latest of envoy as well as the most recent X stable versions and latest for each variant repo.
-> Each variant repo should have exactly what it does currently + the latest -dev image.
for example: envoyproxy/envoy-distroless should have envoyproxy/envoy-distroless:dev-latest
-> -> Each variant-dev repo is mostly good as is.

I had momentarily thought that the variant-dev repos could have the stable versions added, but decided that's just another form of unnecessary duplication. However, it appears that the stable versions are separate images from -dev, so it wouldn't technically be a duplicate.

[phlax]

I was just trying to find an envoy image to use and was unable to find the version number of the most recent stable without a LOT of extra steps.

i think this is the main issue to address

And the current information about the releases on Docker Hub is out of date by 2 minor versions:

hmm yep - this was one of the things i added to make it clearer when we shifted to a single repo

this is an actual bug - the implementation was lost in a migration

the variants are CURRENTLY being published to separate repos ... So, those images are available in 4 places

we should probably just stop pushing to the variant repos - it was kept initially to prevent breaking anyone - but its been that way for a couple of years now and is documented to use the envoyproxy/envoy:* images

Additionally, I would recommend moving the first one to envoyproxy/distroless:dev-latest.

i dont think we want to do that - otherwise devs must know the hash of the latest - better to keep this i think

envoyproxy/envoy should just have the stable versions and latest of envoy as well as the most recent X stable versions and latest for each variant repo.

i dont think we want to revert to using variant repos - i think better we get rid of them altogether

[phlax]

@utopiasedge any help to address the concrete issue/s here would be greatly appreciated

feel free to ping me here or on slack and i would be happy to give some pointers to address

[utopiasedge]

@phlax

First, let me respond to you, then I'll quote you and I'd like more clarity on the concrete issues.

Main issue == usability/accessibility of the main repo. Agreed.

Even if the documentation was correct, that still only shows the major and minor versions, the patch version is omitted, which could still leave people like me looking for a definitive full version number for stability because latest changes without warning.

Unfortunately, any changes are going to require someone somewhere to change their process or code. My previous suggestions could have been implemented in a purely forward way, keeping all previous images and repos.

And documentation vs facts is always a lose-lose situation. Usually easier to fix the docs than change the facts, but you do you. I looked through the documentation to see if I could find the parts that you were referring to and honestly those need to be re-written for clarity anyway. I submitted a PR for a couple of tiny inconsistencies that had been missed. I'm curious if that is going to create additional images further exacerbating the problem.

i dont think we want to do that - otherwise devs must know the hash of the latest - better to keep this i think

My question is what do you mean by "devs must know the hash of the latest"? Isn't the point of the "latest" tag so that devs don't need to know the hash?

---

Ok, so the concrete issues:
So far I have Agreed: "usability/accessibility of the main repo", Observed: "dev convenience prioritized over general usability", and Implied: "No one (devs or users) can find the images they are looking for quickly" on my list. Not trying to be annoying, just to clarify the situation.

I assume the entire point of the hash is to function as a permanent reference to that exact imageset. And that only the devs are interested in the hash identified imagesets. And as we've already agreed the proliferation of hash imagesets is the cause of the usability issue.

If that's the case, then occam's razor is to separate the hash imagesets from the imagesets that the majority of users are looking for. I don't really care how that gets done, but that seems like the most logical solution.

I'm curious why there was a migration to a single repo. I couldn't find any information about that until I went to the website and scrolled all the way down to https://www.envoyproxy.io/docs/envoy/v1.33.0/start/install#image-variants and if I didn't already know about this issue, I would have overlooked it. Especially since even KNOWING about this, I tried to read the listed variants as envoy-distroless: not envoy:distroless-.

Maybe update all other partial documentation to point to the latest docs on the website as the first line of the READMEs, as I assume that is the definitive and most correct docs.

---

So far my solutions are:

• Do nothing.
• Update only 2 repos: envoy and envoy-dev. envoy will have stable releases only, envoy-dev will look like envoy currently does.
• Update only envoy (without dev imagesets written to envoy) and the -dev repos (stop writing releases to variant repos)
• Update currently updating repos without hash imagesets written to envoy.
• Update currently updating repos without dev imagesets written to envoy.
• Update currently updating repos without variants or dev imagesets written to envoy

There's some other options, but they're splitting hairs. BTW, I tried to order these options from what I feel would be least to most organized and intuitive.

[phlax]

Unfortunately, any changes are going to require someone somewhere to change their process or code. My previous suggestions could have been implemented in a purely forward way, keeping all previous images and repos.

if we can agree a way forward im happy to show you what needs to change where

i think we dont want to revert to using separate repos for the variants, so on that basis i think the first step is to remove those repos - i can check their downloads again - but last time i looked it was minimal

My question is what do you mean by "devs must know the hash of the latest"? Isn't the point of the "latest" tag so that devs don't need to know the hash?

i think i misunderstood your suggestion but either way i dont want to bring back the old separate repos

apart from anything it has been documented that all images are in one repo for a couple of years now - so we would still need to keep both

"No one (devs or users) can find the images they are looking for quickly" on my list. Not trying to be annoying, just to clarify the situation.

i dont think i agree with that - we publish and document our releases in multiple places

wrt the dockerhub repo itself - this needs to be fixed - i added the README specifically because if you arrived there first it was not obvious which image/s were available/recommended etc - fixing this is not rocket science but will take some work

And as we've already agreed the proliferation of hash imagesets is the cause of the usability issue.

only if you are expecting the latest to be at the top of the list in dockerhub - i dont think we can meet that expectation

also - it does have search - if you search on latest or v1 it quickly shows you the non-dev images

we moved to a single repo to simplify documentation and maintenance - i think the legacy repos are now confusing and unhelpful so i think removing these is the first priority

i think the actionable items are:

• remove legacy repos (&update CI to stop pushing there)
• fix the dockerhub README publishing

[utopiasedge]

@phlax

I appreciate the speed of your responses. I had noted while researching my comments that it was mentioned that the maintainers frequently are receiving a salary from a company that allows them to put time into this project. I'm glad to hear that and hope you are being paid well for your work here.

I think you have my intentions confused. I opened this issue with the intention of informing the project about an unexpectedly frustrating experience I had attempting to use your code. Because I know that 99% of users with my exact experience are just filing it as "further enshittification of the internet" and NOT informing you. For myself and my fellow users that are not being paid to use or work on this project, the time spent here is a distraction from income producing activities.

So, you have been informed. In fact, this conversation shows that you were already aware, but unwilling to do anything to improve it, but possibly do a few things to make it worse.

You say that it was documented. Only on the website, which I only found while actively writing my previous comment. Your documentation says completely different things in different places.

The readme doesn't help avoid the initial frustration. It only helps after you've suddenly learned that the envoy repo is a mess! You've got a whole document https://github.com/envoyproxy/envoy/blob/main/REPO_LAYOUT.md showing how the GitHub is laid out, but don't have that for your dockerhub, because you've actively made it not follow an organized structure.

And yes, I do expect to find the most recent stable and latest at the top of the list, because the functional projects do that. Searching for latest only shows you latest. You can't get a full major.minor.patch from that. And requiring the v in the search bar to find your project's releases is not universal behavior. Many projects just have them under 1.2.3, 3.2.1, etc. because they don't have hashes poisoning the results for tags starting with numbers.

So I think actionable items for the project:

• Unification of all docs.
• User Surveys to determine what the end users and downstream maintainers would find helpful.
• Discussions with other maintainers to figure out whether to prioritize the UX of millions of users over the 7 maintainers.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.