Re: [Pulp-dev] Fwd: Naming/Tagging-Schema for container images
Replying inline... On Mon, May 18, 2020 at 5:28 PM Dennis Kliban wrote: > > On Mon, May 18, 2020 at 10:37 AM Matthias Dellweg 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 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 >> > 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]. >> >>
Re: [Pulp-dev] Fwd: Naming/Tagging-Schema for container images
On Mon, May 18, 2020 at 10:37 AM Matthias Dellweg 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. > 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 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. > On Mon, May 18, 2020 at 2:46 PM Dennis Kliban 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 > 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
[Pulp-dev] Fwd: Naming/Tagging-Schema for container images
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 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 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
