Lxd: Add more flags to `lxc list`

[toby63]

Context:
See request in Forum by SeventhSon: https://discuss.linuxcontainers.org/t/list-running-containers/7049

Description:
More flags for the lxc list command would be useful, to list more details or filter the list.
For example:

container status | flag |
------------------- | ----- |
running | -r |
stopped | -s |
freezed | -f |

container type | flag |
------------------- | ----- |
container | -con |
virtual machine | -vm |

Further ideas (don't seem to be implemented in list yet):

value | flag |
------------------- | ----- |
size/disk-usage of container/vm | -size |
show image the instance is based on | -img |
date of creation | -date
sort by creation date | -age |
network devices | -net |

[stgraber]

Don't quite agree with proposed naming, but proposed functionality is fine.

[chang-andrew]

Hi there, my name is Andrew and I'm a CS student at UT Austin. Would it be okay if I worked on this issue as part of a learning requirement for a Virtualization class I am taking right now?

[stgraber]

@chang-andrew certainly, that sounds good. I'll assign it to you.

As mentioned, we agree with the general need to add more filtering options to lxc list though don't really agree with the proposed options above and will need to think about this a bit more to come up with a set of options that should cover most needs, is easily extensible and doesn't end up consuming too many command line flags.

[stgraber]

@chang-andrew btw, not sure how many more in that class are looking for good first contributions but I've just gone through some of our backlog and created suitable issues on the LXD project. They can also all be found (for all our projects) at https://discuss.linuxcontainers.org/t/easy-issues-for-new-contributors/7454

Feel free to circulate that link to anyone else interested. We've had great contributions in the past from that class so hoping that this year will be no different :)

[chang-andrew]

@stgraber that is amazing and very helpful, thanks so much! I will be sure to share that with the class 😃

[toby63]

@chang-andrew @stgraber Could you post the resulting propositions for the flags?
Maybe some people would like to comment :slightly_smiling_face: .

[stgraber]

@toby63 my current hope is that we can do away with flags completely and extend the filter syntax instead to match based on API fields. This may be slightly longer to type but would never need updating as it would just automatically evolve as we add more properties in the API.

lxc list type=virtual-machine location=node03 status=RUNNING user.foo=bar abc -c n46

This would list anything which:

• Is a virtual machine
• Is running on cluster node node03
• Is running
• Has a name which starts with abc
• Has user.abc config key set to foo
• Print columns name, ipv4 and ipv6

Which is a combination of what we have and what we could add to filters without introducing a bunch of new flags.

[toby63]

my current hope is that we can do away with flags completely and extend the filter syntax instead to match based on API fields.

:thinking: While I understand the benefits of this approach, it seems a bit too long and complicated for me.
I thought about something like this:
For example typing lxc list r or (at least) lxc list running would list all running containers.

While one could maybe add something like this with lxc alias (I suppose it's possible?), this is not very convenient, because it would need many entries and need to be setup for every server that someone might uses.

Potential Alternatives:

1. Shorter version of your idea, for example:

| key: | alternative: |
| --- | --- |
| type=virtual-machine | type=vm |

1. (Assuming it's possible) Add lxc aliases by default, this way lxc list r or lxc list running could work, but behind the scenes it's the longer command.

[stgraber]

lxc list r is already a valid syntax listing all containers starting with the letter r.

And yeah, we can make the existing API filtering code in LXD understand vm to be virtual-machine to keep that one short.

Ideally this feature should be built on the filtering API that the UTexas students implemented last year as it allows just passing those filters (in much the same syntax I listed above) directly to LXD and have the server filter the data returned to the client, making the whole process a lot less heavy weight.

[toby63]

But is it possible to shorten it with lxc alias then?

[stgraber]

Yeah, you can still alias things, just don't alias a valid command to something else or you'll get surprised.

Setting an alias from lxc lsvmr to lxc list state=RUNNING type=virtual-machine for example would be fine, not that we would ship with any of those by default though.