Replying inline... On Mon, May 18, 2020 at 5:28 PM Dennis Kliban <dkli...@redhat.com> wrote: > > On Mon, May 18, 2020 at 10:37 AM Matthias Dellweg <mdell...@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 <dkli...@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 <mdell...@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@redhat.com >> >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> _______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
