Inconsistency between "state" and "status"

[candlerb]

Required information

incus 0.6-202403181629-ubuntu22.04

Issue description

"incus list" shows a column called "STATE" (for default -f table, or -f compact). Buf if you filter the listing, you have to filter on "status".

Attempting to filter on "state" gives a confusing error message about pointers.

Steps to reproduce

$ incus list | head -3
+----------------+---------+---------------------+----------------------------------------------+-----------------+-----------+
|      NAME      |  STATE  |        IPV4         |                     IPV6                     |      TYPE       | SNAPSHOTS |
+----------------+---------+---------------------+----------------------------------------------+-----------------+-----------+

$ incus list state=running
Error: Invalid type "ptr" for field "state"

$ incus list status=running
+--------+---------+---------------------+----------------------------------------------+-----------+-----------+
|  NAME  |  STATE  |        IPV4         |                     IPV6                     |   TYPE    | SNAPSHOTS |
+--------+---------+---------------------+----------------------------------------------+-----------+-----------+
| sphinx | RUNNING | 10.65.5.179 (eth0)  | fd42:81e:c751:8c26:216:3eff:fe44:3f28 (eth0) | CONTAINER | 0         |
+--------+---------+---------------------+----------------------------------------------+-----------+-----------+
| unifi  | RUNNING | 100.64.0.234 (eth0) |                                              | CONTAINER | 0         |
+--------+---------+---------------------+----------------------------------------------+-----------+-----------+

Would it be reasonable to change the table column heading to STATUS? I can't see that it will affect scripts (which will use either csv or json/yaml output)

Observations

Looking at the JSON, it's both status and state.status

$ incus list status=running -f json | jq .
...
    "status": "Running",
    "status_code": 103,
...
    "state": {
      "status": "Running",
      "status_code": 103,

Filtering on a non-existent setting is quietly allowed (which makes it hard to know whether it's valid or not).

$ incus list statezzz=running
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
$ incus list state.status=running
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
$ incus list status_core=103
+------+-------+------+------+------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+-------+------+------+------+-----------+
$ incus list status_code=103
Error: Unsupported filter type "int" for field "status_code"
$

"status" and "type" and "name" filters are case-insensitive, but some other filters are case-sensitive:

$ incus list volatile.last_state.power=running
... no results
$ incus list volatile.last_state.power=RUNNING
... results

$ incus list status=running image.os=ubuntu
... results
$ incus list status=running image.os=UBUNTU
... no results

[stgraber]

Yeah, it's been a bit of a historical decision to have the UI say "STATE" for columns when the API often refers to the same thing as "status", changing that at this point is likely to cause more harm than good.

I actually meant to fix a couple of places where we do have a STATUS column rather than STATE, those two are in very seldom used commands so not going to be breaking anyone.

For case sensitivity, this is again an area where state/status as well as the type are special cased so they work using the values as display in the list itself (where they're capitalized for readability).