List logically bound images

[omertuc]

Solves the second part of #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.

[cgwalters]

This looks sane to me to start!

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

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

[omertuc]

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]

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]

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

This overlaps a bit with #522 in that in theory we could expose this via varlink too? But eh, json seems like a sane baseline.

[omertuc]

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]

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]

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.

[cgwalters]

A few nits but looking sane to me!

[cgwalters]

This is OK as is but generally so far I've been trying to do things like this closer to cli.rs, keeping functions in other places expecting ambient state.