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. > 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 <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