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

Tue May 19 08:28:43 UTC 2020

Replying inline...

On Mon, May 18, 2020 at 5:28 PM Dennis Kliban <dkliban at redhat.com> wrote:
>
> On Mon, May 18, 2020 at 10:37 AM Matthias Dellweg <mdellweg at redhat.com> wrote:
>>
>> 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?
>>
> What is the purpose of publishing images that are based on different OSes? I am genuinely curious.
You could start shipping experimental images based on a prerelease of
a new version of the distribution while 'latest' still uses the stable
one.
Maybe company policy dictates a certain distribution (OK, you might
want to build your own images here).
In our case, I see us having one ci-image with centos8 & python3.6
next to fedora3? & python3.7.

>> 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?
>>
> Older images allow users to re-deploy the exact same thing that they had deployed somewhere else.
I don't think, we should keep those backups for everyone. This
obviously depends on the target audience, but i think if you have such
requirements, you should have your own backups (you could use pulp to
store all versions of the images you ever used).

>> 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.
>>
> I agree that it is more common to include just a name in the repository name. Pulp is different from most applications because it ships a variable number of plugins.
>
> We could create tags that include the name of all the plugins inside the container. So the user would be able to run a command such as
>
> podman run pulp/pulp:3.3.1-ansible-container-file-maven-rpm
>
> or
>
> podman run pulp/pulp:3.3.1-ansible0.2.0b12-container1.3.0-file0.3.0-maven0.1.0-rpm3.3.2
>
> This tag can get very long.
Now that is probably the biggest problem. However, i would not include
the names of all plugins in the tag. Admins probably want to run
something like
'podman run pulp/pulp:3.3-fedora31'
and get the latest build for that pulp-version which from a specific
point in time contains all the plugins they need.
As i understood, the plan is to ship a container with pulpcore and
pulp_file the moment a new release is tagged. Then each time a
compatible version of a plugin is released, we add that plugin.
So I think it is primarily a matter of communicating, when the time is
reached for administrators to switch to the new pulp-version depending
on their plugin needs. That complexity however seems to me to be there
no matter how we name stuff.

>> 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
>> >>
>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>