`lxc image list images:` filtering issues

[simondeziel]

lxc image list images:'s architecture filtering uses unexpected values like amd64, arm64 and armhf instead of the x86_64, aarch64 and armv7l that are shown in unfiltered listing:

$ lxc image list -f csv -c lat images:alpine/3.16 | head -n 5
alpine/3.16 (3 more),x86_64,CONTAINER
alpine/3.16 (3 more),x86_64,VIRTUAL-MACHINE
alpine/3.16/arm64 (1 more),aarch64,CONTAINER
alpine/3.16/arm64 (1 more),aarch64,VIRTUAL-MACHINE
alpine/3.16/armhf (1 more),armv7l,CONTAINER

$ lxc image list -f csv -c lat images:alpine/3.16 architecture=x86_64  # no output
$ lxc image list -f csv -c lat images:alpine/3.16 architecture=amd64
alpine/3.16 (3 more),x86_64,CONTAINER
alpine/3.16 (3 more),x86_64,VIRTUAL-MACHINE
alpine/3.16/cloud (1 more),x86_64,CONTAINER
alpine/3.16/cloud (1 more),x86_64,VIRTUAL-MACHINE

Ideally, all arch name variations would work.

Also, using type=container (or type=virtual-machine) doesn't work with images: despite working locally for lxc list:

$ lxc image list -f csv -c lt images: type=container  # no output
$ lxc list -f csv -c nt type=container
foo,CONTAINER

The above was observed with:

$ snap list lxd
Name  Version      Rev    Tracking       Publisher   Notes
lxd   5.2-79c3c3b  23155  latest/stable  canonical✓  -

[stgraber]

That's because lxc image list <filter> works against image properties which is the arbitrary key/value provided as part of the image. If you look at lxc image show FINGERPRINT you'll see those properties.

In lxc list we were lucky enough that all config keys on the instances are namespaced which then made it possible to allow filtering BOTH by config key AND by object property.

For images, we're not so lucky, so I'm not sure how we could achieve the same result without breaking someone in the process.

[simondeziel]

Isn't there something special about the images: remote because for locally cached images, filtering works better:

$ lxc image list -f csv 
jammy,2b53b382715b,no,Ubuntu jammy amd64 (20220611_07:42),x86_64,CONTAINER,112.36MB,"Jun 12, 2022 at 2:36am (UTC)"
jammy-vm,a9ceb515d0f3,no,Ubuntu jammy amd64 (20220611_07:42),x86_64,VIRTUAL-MACHINE,246.88MB,"Jun 12, 2022 at 2:38am (UTC)"

$ lxc image list -f csv type=container
jammy,2b53b382715b,no,Ubuntu jammy amd64 (20220611_07:42),x86_64,CONTAINER,112.36MB,"Jun 12, 2022 at 2:36am (UTC)"

Yet, 2b53b382715b doesn't have the word container anywhere in its properties:

$ lxc image show 2b53b382715b
auto_update: false
properties:
  architecture: amd64
  description: Ubuntu jammy amd64 (20220611_07:42)
  os: Ubuntu
  release: jammy
  serial: "20220611_07:42"
  type: squashfs
  variant: default
public: false
expires_at: 1970-01-01T00:00:00Z
profiles:
- default

[stgraber]

Ah, looks like the API filtering feature lets you do property based filtering against LXD. That's going to make things extra confusing...

The public image servers don't use the LXD API so aren't going to support that.