[Pulp-dev] Fwd: Naming/Tagging-Schema for container images

[Matthias Dellweg]

In the long run, i want to publish a ci image based on centos and
another one on fedora? Would you rather put the os_name in the tag? Or
would you only include the os_name if it's not centos8?
How would you see the transition to centos9?

As i see it, we have three information that we need to encode:
1. Purpose of the container: pulp, pulp-ci, pulp-molecule, ...
2. Base OS: centos8, centos9 (eventually), fedora31, debian10, ...
3. (Y-stream) Version of pulpcore involved: master, devel, latest, 3.2, ...
[ 4. Build number of the image ]

With respect to 4., I am unsure how much value there is to keep older
builds lying around. Is that a common practice?

I guess, we could skip "centos8" as the default value (but it should
not hurt to tag the same image with the fully qualifying name anyway).

The (harder) question is, which of these information should make up
the (docker-/quay-)repository name and which encode the tag?
e.g.
  - The fedora and alpine repository have one tag for each
(pre-)released version.
  - Debian has tags for each version and again for the version with
added '-slim' or '-backports'.
  - Python uses python version with debian or alpine release as tags.
      * [3.8.3-slim-buster, 3.8-slim-buster, 3-slim-buster,
slim-buster, 3.8.3-slim, 3.8-slim, 3-slim, slim] all refer to the same
container image.

It seems quite common to have simple repository names and combine a
lot of very different images with an elaborate tagging schema. Also
certain images tend to have several tags.

On Mon, May 18, 2020 at 2:46 PM Dennis Kliban <dkliban at redhat.com> wrote:
>
> Long term, I would like to stop publishing container images based on Fedora. Images for production use should be built on top of CentOS 8 stream[0]. The name of the image repository should not contain the OS name.
>
> Each 3.y release of pulpcore should live in its own repository called pulp/pulp-3-y. The initial release should be tagged as both 'latest' and '0'. Each time a compatible plugin is released, this image should be updated and the tag should be incremented by 1. The project website should contain a table that is automatically generated. The table should list what versions of plugins are included in each of the tags.
>
> What do others think?
>
> [0] https://pulp.plan.io/issues/6676
>
>
> On Thu, May 14, 2020 at 12:54 PM Matthias Dellweg <mdellweg at redhat.com> wrote:
>>
>> We have recently started a new repository calles pulp-oci-images that
>> should emit according to its name OCI compatible images with pulp
>> installed.
>> In the first go, this includes the single-container promoted though
>> this blog post [0].
>> Soon to be added is the base container image that shall speed up our CI [1].
>> In the future, i envision a similar single-container solution based on
>> centos instead of fedora,
>> as well as ci base images based on centos having python3.6 installed.
>> Does anyone think, we even need different ci-images for pulp release branches?
>>
>> The big question now is: How are we going to name and tag those images?
>>
>> The one from [0] is called "pulp/pulp-fedora31:latest".
>> We could go with that and add names like:
>> - "pulp/pulp-centos8:3.2"
>>   installation of core version 3.2 with all compatible plugins on centos8
>> - "pulp/pulp-ci-fedora32:latest"
>> - "pulp/pulp-ci-centos8:latest"
>>
>> BTW, the ci-base images can be built by using the same Conteinerfile
>> interrupted early.
>> (with --target in a multistage build)
>>
>> What do you think?
>>
>> [0] https://pulpproject.org/2020/03/15/pulp-fedora31-single-container/
>> [1] https://github.com/pulp/pulpcore/blob/master/.travis/Containerfile.ci_base
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>