Move our container images to a different repository?

[sebastian-luna-valero]

Docker has updated its TOS:

What are the new container image retention limits?
Docker is introducing a container image retention policy for inactive images which will be enforced starting November 1, 2020. > The container inactive image retention policy will apply to the following plans:

• Free plans will have a 6 month inactive image retention limit
• Pro and Team plans will have unlimited image retention

What is an “inactive” image?
An inactive image is a container image that has not been either pushed or pulled from the Docker Hub image repository in 6 or more months.

• info: https://www.docker.com/pricing/resource-consumption-updates

[jonesmg]

That sounds like it's going to be an issue for us as part of the idea here is the preservation of the pipeline, even if no one looks at it for months or years. Would zenodo be a reasonable alternative? Would this complicate how the docker containers are downloaded/initialised?

[sebastian-luna-valero]

Thanks, Mike. You are right and we need to look out for alternative repositories to avoid the preservation issue.

I just came across this one:

https://github.blog/2020-09-01-introducing-github-container-registry/

But I would like to explore a little bit more; it's just than I am currently busy with other, more urgent tasks.

As far as I remember zenodo is not intended for container images but I will double check.

A priori changing the repository for container images should have little impact on this work.

[julian-garrido]

We might create a job that pulls the container every XX time, so it doesn't become inactive. Would that make sense at least for HCG16 paper (which is already published)?

[jonesmg]

I think that would work from the published paper standpoint, but it's certainly not the only solution. As long as the container remains the same then the final output (which is what matters for the paper) will be the same. So I'm fairly agnostic about what the approach should be, the container just needs to be accessible do that the script can pull it when it is executed. Creating a job to periodically ping the container seems like a patch rather than a solution, but I'm not sure. For example, moving forward for future projects we probably won't want to use the same approach.

[julian-garrido]

Sure, that is what I meant: a patch for HCG 16. I don't remember right now if there was a link in the paper to the container, for example. If that if not the case, then there is more flexibility