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] New check for Pull Requests of RPM plugin
As of today there is a new check for PRs that checks the 'coverage.md' file in the root directory of RPM plugin github repository. This file keeps track of test coverage for pulp_rpm features. If you add any functionality, we would like to know if there is a functional test or not (or even just partial test coverage). Please update the file with your PR. If your PR is a small fix that doesn't need a new test or doesn't extend functionality, you can skip this check by adding '[nocoverage]' in your commit message. -- Pavel Picka Red Hat ___ 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
Re: [Pulp-dev] [Pulp-list] Bug triage is moving to #pulp-meeting on Freenode
The decision to do this was actually made a while ago when we noticed that holding meetings in #pulp-dev interrupted discussions that were happening in that channel around the same time as the meeting. However, I did not follow through to actually announce this decision and update the website. @bmbouter brought this up again on Friday during open floor. On Mon, May 18, 2020 at 8:35 AM David Davis wrote: > Any chance we can get some background on how, why, where this decision was > made? I'm not opposed to it but having some more information in this > announcement would be helpful. > > David > > > On Fri, May 15, 2020 at 11:21 AM Dennis Kliban wrote: > >> Starting on May 19th, bug triage will be held in #pulp-meeting on >> Freenode[0]. >> >> [0] https://pulpproject.org/get_involved/#meetings >> ___ >> Pulp-list mailing list >> pulp-l...@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-list > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] [Pulp-list] Bug triage is moving to #pulp-meeting on Freenode
I'll try to remember: First of all, the obvious. It is a meeting. But the more subtle point is that while triage takes place, "normal" discussions in pulp-dev are hard to follow, should be suspended, ... And with the recent change, that triage & OF was doubled in time, that effect became apparent. Maybe other folks have more reasons. Matthias On Mon, May 18, 2020 at 2:35 PM David Davis wrote: > > Any chance we can get some background on how, why, where this decision was > made? I'm not opposed to it but having some more information in this > announcement would be helpful. > > David > > > On Fri, May 15, 2020 at 11:21 AM Dennis Kliban wrote: >> >> Starting on May 19th, bug triage will be held in #pulp-meeting on >> Freenode[0]. >> >> [0] https://pulpproject.org/get_involved/#meetings >> ___ >> Pulp-list mailing list >> pulp-l...@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-list > > ___ > 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
Re: [Pulp-dev] Naming/Tagging-Schema for container images
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
Re: [Pulp-dev] [Pulp-list] Bug triage is moving to #pulp-meeting on Freenode
Any chance we can get some background on how, why, where this decision was made? I'm not opposed to it but having some more information in this announcement would be helpful. David On Fri, May 15, 2020 at 11:21 AM Dennis Kliban wrote: > Starting on May 19th, bug triage will be held in #pulp-meeting on > Freenode[0]. > > [0] https://pulpproject.org/get_involved/#meetings > ___ > Pulp-list mailing list > pulp-l...@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-list ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Consolidating plugin listing on pulpproject.org for user clarity?
Hi Brian, I agree with the problems identified. I'm concerned that the same plugins have a different set of features in Pulp 2 and Pulp 3, e.g, pulp_rpm. Having it just marked as compatible with both Pulp 2 and Pulp 3 might create an assumption that the same features are available for both Pulp 2 and Pulp 3. Some plugins are separated or renamed, it's hard to mark them compatible or not, e.g. Pulp 3 pulp_file should be marked as a part of Pulp 2 pulp_rpm? Pulp 2 pulp_docker - a part of pulp_container in Pulp 3? I wonder if we should keep pulp 2 and pulp 3 plugins separate, maybe on the same page but not in the same table? Alternatively, many footnotes with clarifications might help. Thanks, Tanya On Wed, May 13, 2020 at 5:37 PM Brian Bouterse wrote: > Melanie, > > I'm sending via pulp-dev for more visibility, but I wanted to see what you > think specifically. Recently a user gave us feedback via an issue on Pulp 3 > pain points for usage [0]. A lot of it is code and docs, and we're working > to address those, but the last bullet says: > > "On the project page you tells that Pulp can manage plainty of repo type, > but in fact if you take a fresh version only few plugins are working. Is > there at least a compatibility/status matrix explaining that?" > > There are two issues we identified at the installer meeting. 1) The > homepage claims one set of plugins that are pulp2 compatible but doesn't > clearly state they are for pulp two.2) the pulp3 plugin table is not on the > home page. > > What do you think about consolidating the "plugin list" on the homepage > and the pulp3 plugins page into one table with two new columns "Pulp 2 > compatible" and "Pulp 3 compatible" with X's or check mark icons in the > cells where that compatibility exists? > > What do others think also? > > [0]: https://pulp.plan.io/issues/6658 > > Thanks, > Brian > > ___ > 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
