Now that 14.2-RELEASE publishes base images via the usual downloads website links, users are requesting these be made available on the more common public container registry platforms, such as docker.io github container registry etc. Something similar to `podman pull freebsd14-minimal:14.2-RELEASE` but this requires a few more moving parts than we have today. This requires a bit of coordination, and discussion: - naming is important - ensuring chain of trust for users & releng teams - what secteam guarantees / expectations are and how to communicate them - what should happen when patches/errata are released I will open this up with re@ and secteam@ and keep this updated.
Created attachment 256042 [details] proposed tagged images viewed in github container repo
Created attachment 256043 [details] list of images in github container repo
Comment on attachment 256042 [details] proposed tagged images viewed in github container repo I think with this tagging scheme, the ABI version embedded in the image name is redundant so I suggest changing to 'ghcr.io/freeebsd/freebsd-static:14.2p0' Given that the architecture metadata for non-amd64 images built for 14.2p0 are broken, we should only publish amd64 for this version. Later fixed builda can publish multi-arch images.
progress update ## public container registries - docker hub underway thanks to robak@ - github container repo up thanks to philip@ - github is private to registered committers until we have naming sorted, & docs & releng/secteam approval ## naming For the initial 14.2-RELEASE we want the 3 layers from the release (static, dynamic, minimal), with several tags: - a tag for the specific patch level - a more flexible tag that will move over time to the most recently patched This tagging enables a system administrator to rely on having the most up to date and patched version in production, or for an application tester, to be certain of the precise version that production validation was done for. ### specific tags These will be immutable, and should always match a -RELEASE-p0 tarball: ``` ### the typical release artifacts # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd14-minimal:14.2p0 # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd14-static:14.2p0 # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd14-dynamic:14.2p0 ``` ### mutable tags There is no difference from the registry's perspective, but users should assume these will move over time. For example, once 14.3-RELEASE is published, the `freebsd14-minimal:14` tag would point to 14.3-RELEASE. While we don't publish pX yet, I will give an example nomenclature for those too. ``` ### the latest -pX image would be tagged as 14.2 # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd14-minimal:14.2 # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd14-static:14.2 # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd14-dynamic:14.2 ### the latest RELEASE as cut from the 14/stable lineage # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd14-minimal:14 # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd14-static:14 # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd14-dynamic:14 ``` I'm not tied to the naming, if this should be more consistent with other places in FreeBSD, please suggest. ## docs My public notes with a view to this becoming a handbook eventually:
thanks Doug, this would then be: ### specific tags These will be immutable, and should always match a -RELEASE-p0 tarball: ``` ### the typical release artifacts # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd-minimal:14.2p0 # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd-static:14.2p0 # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd-dynamic:14.2p0 ``` ### mutable tags There is no difference from the registry's perspective, but users should assume these will move over time. For example, once 14.3-RELEASE is published, the `freebsd-minimal:14` tag would point to 14.3-RELEASE. While we don't publish pX yet, I will give an example nomenclature for those too. ``` ### the latest -pX image would be tagged as 14.2 # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd-minimal:14.2 # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd-static:14.2 # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd-dynamic:14.2 ### the latest RELEASE as cut from the 14/stable lineage # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd-minimal:14 # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd-static:14 # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd-dynamic:14 ``` I like this.
(In reply to Dave Cottlehuber from comment #4) I still think that referring to these images as 'layers' is confusing, at least for someone like me who vaguely understands how images are structured.
arrgh I missed one "layers" right at the beginning. Consider it purged.
(In reply to dfr from comment #6) Which terminology would you recommend instead?
(In reply to crest from comment #8) The correct term is 'image'. In OCI container images, layers are an implementation detail and users don't interact with them much. Calling images layers is confusing to someone used to working with OCI images.
After some discussion on irc, we may need to tag slightly differently. We should be able to distinguish between 14.2-STABLE and 14.2-RELEASE, for example. And it is more clear to use the exact same nomenclature as `uname -r` or `freebsd-version` would report. So, hopefully this is the last round of tag proposals: ### specific tags These will be immutable, and should always match a -RELEASE-p0 tarball. The release artifacts will be pushed as -RELEASE-p0, and tagged -RELEASE ``` ### these ones won't change # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd-minimal:14.2-RELEASE-p0 # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd-static:14.2-RELEASE-p0 # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd-dynamic:14.2-RELEASE-p0 ### but once 14.2-RELEASE-p1 is available, these would change - see below # podman push c5f3e77557a9 ghcr.io/freebsd/freebsd-minimal:14.2-RELEASE # podman push 7876fe59dbb3 ghcr.io/freebsd/freebsd-static:14.2-RELEASE # podman push ebf7538b22f4 ghcr.io/freebsd/freebsd-dynamic:14.2-RELEASE ``` ### mutable tags There is no difference from the registry's perspective, but users should assume these will move over time. For example, once 14.3-RELEASE is published, the `freebsd-minimal:14` tag would point to 14.3-RELEASE. While releng doesn't publish pX yet, I will give an example nomenclature for those too as a future reference. ``` ### the latest -pX image would be tagged as 14.2 # podman push abc123def456 ghcr.io/freebsd/freebsd-minimal:14.2-RELEASE-p1 # podman push abc123def457 ghcr.io/freebsd/freebsd-static:14.2-RELEASE-p1 # podman push abc123def458 ghcr.io/freebsd/freebsd-dynamic:14.2-RELEASE-p1 ### and update the mutable tags # podman push abc123def456 ghcr.io/freebsd/freebsd-minimal:14.2-RELEASE # podman push abc123def457 ghcr.io/freebsd/freebsd-static:14.2-RELEASE # podman push abc123def458 ghcr.io/freebsd/freebsd-dynamic:14.2-RELEASE ### the latest version cut from the 14/stable lineage (snapshots) # podman push abc123def459 ghcr.io/freebsd/freebsd-minimal:14-STABLE # podman push abc123def45a ghcr.io/freebsd/freebsd-static:14-STABLE # podman push abc123def45b ghcr.io/freebsd/freebsd-dynamic:14-STABLE ```
(In reply to Dave Cottlehuber from comment #10) I still prefer the pkgbase-style compact version numbers. Do we need to publish images for non-released branches? If it makes sense, perhaps follow the pkgbase naming, e.g. 'freebsd-minimal:14.snap20250119103653' for explicit image references and maybe add 'freebsd-minimal:14-stable' for the latest snapshot?