There was an old initial discussion topic here: Keeping Images Current that was never fully discussed and fleshed out.
in short, image producers and consumers do not align on their desired image targets. producers wish to always build freshly using obvious targets (latest version of 10, for example) and consumers desire more static deployments.
we should resolve:
- image naming
- image build/release schedule (& associated naming convention)
- storage implications of not having rolling image updates (i.e. not overwriting named images)
- custom images and how they are stored/expired
- facility manager image management (build, pull, push, etc)
naming
- the distro should be included explicitly
- some kind of versioning (preferably official) should be indicated explicitly
- if there is a purpose, project, or special role, it should be included somewhere
an example of an existing image name might be ubuntu2404 or fedora43, and this includes the 2 major information points needed, but there are different states of ubuntu2404 or fedora43 – early or late in the release cycle – that may change the way certain things operate, kernel patches, etc. see the examples in the next section about scheduling.
my current proposal is something like
- distro/shortdistro – either ubuntu|fedora|debian|kali|etc or ubnt|fdra|debn|kali
- dash
- official major release version – 2604|44|13|2026.2
- dash
- point release OR function or role – 4|c or hypervisor|aarch64
- dash (optional)
- function or role hypervisor|aarch64|portalvte
so for example,
- ubuntu 2404 release 4 on arm would be ubuntu-2404-4-arm64
- fedora 44 hypervisor would be fedora-44-hypervisor
- debian 13 would be debian-13
we should create a feature that allows us to specify minimal metadata such that we can include debian and ubuntu codenames for user convenience and legibility. that way we can display noble numbat, resolute racoon, and trixiealong side things like ubuntu 2404, 2604, and debian 13.
building/releasing schedule & associated names
-
examples of point releases & naming them
here is an example of ubuntu server versions that are point released as things change within the package tree.
these can either be referenced directly as ubuntu24044 or some other method like ubuntu-2404.4, or we could simply use the date that we auto-built the system and update the build process on the back-end to include the latest version, i.e.
ubuntu-2404-202606and have quarterly or semi-annual builds from whatever is latest at the time. -
this would alter the naming of point releases from default image names to dated image names
-
ubuntu-2404-202512
-
fedora-43-202512
storage implications of scheduled builds
- tbd, but each image costs about 4-10gb uncompressed i think, or 2-5gb compressed
- given that scheduled builds are maintained and stored by the merge operators, we should consider an archival/expiration strategy, but allow users to utilize our old images by artifact and include them or upload them as a custom image
custom images & storage/expiration
- custom images should probably not muck up the portal storage and be per facility?
facility manager operations WRT images
building
a facility manager should be able to trivially build and upload images to the facility. this must be a first class operation supported by mrg/mrs tools.
pulling
- a facility manager should be able to pull our pre-built images
- a facility manager should be able to schedule pulling our pre-built images or any given image registry from github or gitlab pipeline or custom location
pushing (portal → facility)
- new feature: a facility manager should be able to “synch” remote images from other facilities or from the portal to the local facility image storage area.