containers / bootc

Boot and upgrade via container images
https://containers.github.io/bootc/
Apache License 2.0
769 stars 83 forks source link

List logically bound images #871

Closed omertuc closed 3 days ago

omertuc commented 2 weeks ago

Solves the second part of https://github.com/containers/bootc/issues/846

The (hidden) image list command now has a --type flag to allow users to list only logical images, only host images, or all images.

Also the command has been adjusted so that it can run even when not booted off of a bootc system. In that case, it will only list logical images. If a user tries to list host images without a booted system, an error will be thrown.

The command also has a --format flag to allow users to choose between a human-readable table format and a JSON format.

omertuc commented 2 weeks ago

I suspect though to really meet the goal we need to think about machine-readable output, which raises its own set of questions.

I've played around with formats, none of it is final so feel free to suggest changes:

[omer@hal9000 ~]$ sudo bootc image list
 IMAGE TYPE   IMAGE
 host         docker://quay.io/otuchfel/bootc:listss
 logical      quay.io/curl/curl-base:latest
[omer@hal9000 ~]$ sudo bootc image list --help
List fetched images stored in the bootc storage.

Note that these are distinct from images stored via e.g. `podman`.

Usage: bootc image list [OPTIONS]

Options:
      --list-type <LIST_TYPE>
          Type of image to list

          [default: all]

          Possible values:
          - all:     List all images
          - logical: List only logically bound images
          - host:    List only host images

      --list-format <LIST_FORMAT>
          [default: table]

          Possible values:
          - table: Human readable table format
          - json:  JSON format
          - csv:   CSV format

  -h, --help
          Print help (see a summary with '-h')
[omer@hal9000 ~]$ sudo bootc image list --list-format json
[
  {
    "image_type": "Host",
    "image": "docker://quay.io/otuchfel/bootc:listss"
  },
  {
    "image_type": "Logical",
    "image": "quay.io/curl/curl-base:latest"
  }
]
[omer@hal9000 ~]$ sudo bootc image list --list-format csv
image_type,image
Host,docker://quay.io/otuchfel/bootc:listss
Logical,quay.io/curl/curl-base:latest
[omer@hal9000 ~]$ sudo bootc image list --list-format json --list-type logical
[
  {
    "image_type": "Logical",
    "image": "quay.io/curl/curl-base:latest"
  }
]
[omer@hal9000 ~]$ sudo bootc image list --list-format json --list-type logical | jq '.[].image' -r
quay.io/curl/curl-base:latest
omertuc commented 2 weeks ago

Also should be straightforward to change test-logically-bound-install.nu to cover this right?

Seems so, I'm trying to get at-least one successful run of the tmt tests on a clean main branch, then I'll see how I can extend the .nu script

cgwalters commented 2 weeks ago

I don't see the need to have both csv and json, let's pick json.

This overlaps a bit with https://github.com/containers/bootc/issues/522 in that in theory we could expose this via varlink too? But eh, json seems like a sane baseline.

omertuc commented 2 weeks ago

I don't see the need to have both csv and json, let's pick json.

Removed CSV (it was trivial to add and to remove so no harm done), it was mostly just an example of how we can add formats easily anyway

omertuc commented 2 weeks ago

Seems so, I'm trying to get at-least one successful run of the tmt tests on a clean main branch, then I'll see how I can extend the .nu script

Extending a bootc image with the following commands seems to be enough to prepare it , once booted on a VM, for cloning the bootc repo and running make test-tmt successfully:

FROM localhost/bootc

RUN dnf install -y --setopt=install_weak_deps=False cargo git genisoimage libvirt python-pip qemu-kvm rsync && \
    dnf clean all && \
    rm -rf /var/cache/dnf /var/log/dnf* /var/log/yum.*

RUN python3 -m pip install testcloud tmt && \
    rm -rf ~/.cache/pip

RUN systemctl enable virtqemud.socket

Is anything like this documented anywhere? Am I even doing it right or am I missing some obvious simpler way?

cgwalters commented 2 weeks ago

Is anything like this documented anywhere? Am I even doing it right or am I missing some obvious simpler way?

I run most things from a toolbox container personally where I have this stuff already installed. What you're doing there is "recursive" which is cool, but I am unsure I would have that be a primary target.