RFC: Feasibility of aging out old content
BenTheElder opened this issue · 2 comments
What would you like to be added:
Not necessarily implemented yet, but a temperature and feasibility check on eventually retiring old content from our file/image hosts.
Why is this needed:
See kubernetes/registry.k8s.io#144 for context. (Also previously discussed by community members in Kubernetes Chair & TL meetings, K8s Infra meetings, and other venues).
TLDR:
- Could reduce some cost from long tail usage of very old unsupported releases
- Could help reduce pain with promoter processing ever-growing set of content
The cost reduction would primarily be because we would break people, and encourage them to upgrade (?)
I think other OSS projects follow a similar strategy, e.g. the "normal" debian APT repos don't work with old releases, but there is a public archive.
I don't know the actual strategy for when debian distros move to the archive. For kubernetes, if we support 4 versions (?), we probably want to keep at least 5 versions "live" so that people aren't forced to upgrade all their EOL clusters at once, but we probably want to keep no more than 8 versions "live" so that people are nudged to upgrade. So I come up with a range of 5-8 releases if we wanted to split off old releases, and I can imagine a case for any of those values.
The cost reduction would primarily be because we would break people, and encourage them to upgrade (?)
Right, like today you can still pull gcr.io/google-containers/kube-proxy:v1.2.0 and even though it's been a few years since we switched to k8s.gcr.io (and now registry.k8s.io) gcr.io/google-containers still sees traffic.
This issue isn't about what the policy should be though, it's about how we'd actually handle implementing anything like this.
Right now all of the tooling is append-only and doesn't delete ever. Further the spec for what content should exist is stored in git and we only append.