#1246 Toolbx: Fix the 'name' label
Opened 2 months ago by rishi. Modified 2 months ago
rishi/pungi-fedora wip/rishi/name-fedora-toolbox  into  main

Toolbx: Fix the 'name' label
Debarshi Ray • 2 months ago  
file modified
+1 -1
@@ -205,7 +205,7 @@ 

                  'dockerversion': "1.10.1",

                  'docker_cmd':  '[ "/bin/bash" ]',

                  'docker_env': '[ "container=oci" ]',

-                 'docker_label': '{ "name": "fedora", "license": "MIT", "vendor": "Fedora Project", "version": "41", "com.github.containers.toolbox": "true"}',

+                 'docker_label': '{ "name": "fedora-toolbox", "license": "MIT", "vendor": "Fedora Project", "version": "41", "com.github.containers.toolbox": "true"}',

              },

          }

          ],

file modified
+1 -1
@@ -262,7 +262,7 @@ 

                  'dockerversion': "1.10.1",

                  'docker_cmd':  '[ "/bin/bash" ]',

                  'docker_env': '[ "container=oci" ]',

-                 'docker_label': '{ "name": "fedora", "license": "MIT", "vendor": "Fedora Project", "version": "41", "com.github.containers.toolbox": "true"}',

+                 'docker_label': '{ "name": "fedora-toolbox", "license": "MIT", "vendor": "Fedora Project", "version": "41", "com.github.containers.toolbox": "true"}',

              },

          }

          ],

The Container/Dockerfile equivalent of the fedora-toolbox OCI images had
the name label set to fedora-toolbox, not fedora.

Compare this:

  $ podman inspect \
      --format '{{ .Labels.name }}' \
      --type image registry.fedoraproject.org/fedora-toolbox:38
  fedora-toolbox

... with:

  $ podman inspect \
      --format '{{ .Labels.name }}' \
      --type image registry.fedoraproject.org/fedora-toolbox:39
  fedora
  $ podman inspect \
      --format '{{ .Labels.name }}' \
      --type image registry.fedoraproject.org/fedora-toolbox:41
  fedora

The name label doesn't really matter today, which is why it went
unnoticed during the Fedora 39 development cycle. However, it would be
good to fix it, in case someone or something starts using it.

Signed-off-by: Debarshi Ray rishi@fedoraproject.org

rebased onto 47a894e

2 months ago

@ngompa is working on https://pagure.io/pungi-fedora/pull-request/1248 , which would render all of this pretty much moot anyway, AIUI.

@ngompa is working on https://pagure.io/pungi-fedora/pull-request/1248 , which would render all of this pretty much moot anyway, AIUI.

Yeah, I am trying to sort out the KIWI builds in parallel. Last time I checked, the KIWI sources of the fedora-toolbox image had the same problems that the Kickstart/Pungi based images had during the Fedora 39 cycle, which I fixed at the tail end of the cycle.

It looks like the fedora-toolbox images are still being built by Image Factory, not KIWI:

$ podman inspect --format '{{ .Comment }}' --type image registry.fedoraproject.org/fedora-toolbox:40
Created by Image Factory

... which is why I filed this PR.

I got myself a thin slice of free time to work on the fedora-toolbox images, and I want to take advantage of it to fix everything, so that nothing slips through the cracks. For example, what if something goes wrong and we have to activate the contingency plan and switch back to Image Factory?

I will soon have to context switch away from image maintenance to other things in Toolbx land, so I want to get everything sorted out.

Last time I checked, the KIWI sources of the fedora-toolbox image had the same problems that the Kickstart/Pungi based images had during the Fedora 39 cycle, which I fixed at the tail end of the cycle.

What problems are those?

Last time I checked, the KIWI sources of the fedora-toolbox image had the same problems that the Kickstart/Pungi based images had during the Fedora 39 cycle, which I fixed at the tail end of the cycle.

What problems are those?

From a quick read of the KIWI sources, I spotted this one:
https://pagure.io/fedora-kickstarts/c/30f76d387d9e7f5ce6cfb395a96a392435fd6f60

I have only just started to build the KIWI sources, so that's all I have right now.

Various people on the Internet tend to treat the fedora-toolbox images as some sort of de facto reference, and copy paste them to create their own. That's another reason I try to keep all variants of them (Container/Dockerfile, Kickstarts/Pungi and KIWI) updated, as long as the relevant branches and sources do exist. For example, I stopped updating the Container/Dockerfile after Fedora 39 came out because we sunset the repository, except the f38 branch, which is still useful as a reference for maintaining the RHEL images.

@ngompa can you please check the above and make sure it's fixed in the kiwi toolbox definitions?

@ngompa can you please check the above and make sure it's fixed in the kiwi toolbox definitions?

I was trying to figure this out myself, because I am still learning how to drive the KIWI toolchain properly.

When I look at the definition of the Container-Toolbox profile:

    <preferences profiles="Container-Toolbox">
        <type image="oci">
            <containerconfig
              name="fedora-toolbox"
              tag="rawhide"
              maintainer="Fedora Project Contributors &lt;devel@lists.fedoraproject.org&gt;"
            >
                <subcommand execute="/bin/bash"/>
                <labels>
                    <label name="org.opencontainers.image.vendor" value="Fedora Project"/>
                    <label name="org.opencontainers.image.url" value="https://fedoraproject.org/"/>
                    <label name="org.opencontainers.image.license" value="MIT"/>
                    <label name="org.opencontainers.image.version" value="rawhide"/>
                    <label name="com.github.containers.toolbox" value="true"/>
                    <!-- Legacy attributes for backward compatibility -->
                    <label name="vendor" value="Fedora Project"/>
                    <label name="license" value="MIT"/>
                    <label name="version" value="rawhide"/>
                </labels>
            </containerconfig>
        </type>
        <timezone>Etc/UTC</timezone>
        <locale>en_US</locale>
        <rpm-locale-filtering>false</rpm-locale-filtering>
        <rpm-excludedocs>false</rpm-excludedocs>
    </preferences>

... I see name="fedora-toolbox" in containerconfig, but no such label.

I built the image and imported it into containers-storage:

$ sudo ./kiwi-build --image-type=oci --image-profile=Container-Toolbox --output-dir ./outdir
$ skopeo copy oci-archive:./outdir/Fedora.x86_64-Rawhide.oci.tar.xz containers-storage:localhost/fedora-toolbox-kiwi:41

... and I don't see the aforementioned name or any label in podman inspect --type image.

I suppose, if there's no name label for the KIWI built images, then that's a good state to be in too. The reason I sent this pull request is that, I didn't want the name to exit as before, but be set fedora and not fedora-toolbox.

name is used for storing the image in container storage, it's not a label.

If we need more labels or want more identifiers, feel free to add them.

Oh, to make it clear, the reason why it doesn't do anything is because we're not having kiwi do any of the push/upload stuff. So the labels take effect but the name+tag does not really.

name is used for storing the image in container storage, it's not a label.

I see.

If we need more labels or want more identifiers, feel free to add them.

I don't think we need anything new, at least not for Toolbx.

I did notice that the the version label gets set to rawhide in the KIWI sources, while in the past with both Image Factory and OpenShift Build Service, we always used a numerical version. I was about to send a pull request for that, but then had second thoughts about whether that was by intention.

I started using a number because that's what the Fedora guidelines said for Dockerfiles, and it just stayed that way after the port to Kickstarts and Pungi.

Does it impact the tag used to publish the image? eg., registry.fedoraproject.org/fedora-toolbox:41 versus fedora-toolbox:rawhide. Currently, toolbox(1) really expects the former.

Other than that, I don't have any opinion. :)

I think we need both identifiers, but I think our releng script that pushes them to registries can actually do that for us.

I think we need both identifiers, but I think our releng script that pushes them to registries can actually do that for us.

Having both of these would be definitely good:
- registry.fedoraproject.org/fedora-toolbox:41
- registry.fedoraproject.org/fedora-toolbox:rawhide

... because with rawhide you don't have to bump the version every six months or so. However, if we really are publishing or want to publish one tag, then it would be good if we kept the number for the sake of backwards compatibility, both for Toolbx and what manual users had gotten used to.

For Toolbx, I always wanted to do a quick query and map rawhide to a number. Or we can use rawhide directly if there's an image with that tag. Then the corresponding fedora-toolbox-rawhide container would remain Rawhide after Branching, which would avoid a lot of confusion.

Whatever we do, the existing toolbox(1) code really expects the tag on the registry to be a number. Having only a rawhide tag will require code changes.

It looks like the images that I just pulled are still built by Image Factory:

$ podman inspect \
    --format '{{ .Comment }}' \
    --type image \
    registry.fedoraproject.org/fedora-toolbox:41
Created by Image Factory
$ podman inspect \
    --format '{{ .Comment }}' \
    --type image \
    registry.fedoraproject.org/fedora-toolbox:40
Created by Image Factory

Yes, this is because of https://pagure.io/releng/issue/12013 . I am trying to write a minimal fix for it right now, and cursing that this script is written in bash not python...

Yes, this is because of https://pagure.io/releng/issue/12013 . I am trying to write a minimal fix for it right now, and cursing that this script is written in bash not python...

I see. Thanks, @adamwill !

Metadata