On Tue, 10 Jan 2023 at 14:13, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2023-01-10 10:28:21 +0100 (+0100), Radosław Piliszek wrote: [...]
I meant a permanent, publicly-available-for-download storage of versioned container images. Unless you somehow omitted that one option from your answer, I think you have answered that it is not supported at the moment which would agree with my upfront knowledge. On that note, are there any plans to add that support? Or is the best recommendation to use Quay (as DockerHub's limits are hurtful).
It's still not clear from your description whether you intend to only publish images for the software hosted in OpenDev, or copy images from other container repositories into it. Is it failing uploads into DockerHub which are causing pain, or downloading the dependency images from DockerHub in CI jobs, or some other limits?
I think this got answered by another mail - it will be OpenDev-hosted only. As for what is failing - nothing, because there is nothing. :D I was scoping the interest/vision on the side of OpenDev to be able to characterise it properly for stakeholders.
If it's that DockerHub's download limits are impacting outside users of your published images (not just CI jobs, where we can try to do a better job of proxying/caching those), then that suggests the bandwidth needed to host these is probably astronomical, and that would be my biggest concern. DockerHub is clearly imposing limits for a reason, so if it's not cheap/easy for them to serve the content then I don't expect it to be any easier for a volunteer community relying on donated services to do so.
(continued)
Yes, knowing storage needs is one important aspect, but estimating bandwidth utilization is probably an even bigger concern for a potential service like this. Hard drives are cheap, relatively speaking, while capacity on Internet uplinks tends to be much harder to scale.
That is a very good argument and it has indeed crossed my mind before. That said, it is close to impossible to estimate for a not-yet-existent project how often it will be downloaded. Anyways, thank you all for your answers. I know all I wanted to know. Summarising: * CI aspects are well-covered (proxies, shared insecure registry, buildset registry) * public hosting of container image artifacts is not in the current scope and unlikely to be due to the impact it might have on the overall infrastructure