RFE: Create machine-readable output option for "stratis ... list" commands

[bgurney-rh]

It would be nice for the "stratis ... list" commands to have a "machine-readable" output option (e.g.: YAML, JSON, TOML, etc.), to allow other programs to interpret the results without resorting to "screen-scraping".

Example output from a stratis pool created on a test device:

# stratis pool create spool1 /dev/nvme0n1p5
# stratis fs create spool1 sfs1
# stratis fs create spool1 sfs2
# stratis fs create spool1 sfs3
# stratis pool list
Name    Total Physical Size  Total Physical Used
spool1           228.83 GiB             1.85 GiB
# stratis fs list
Pool Name  Name  Used     Created            Device                UUID
spool1     sfs1  545 MiB  Jun 12 2019 15:46  /stratis/spool1/sfs1  5e4244e98f814df1be8247430ab3e741
spool1     sfs2  545 MiB  Jun 12 2019 15:46  /stratis/spool1/sfs2  446cd0f3b08a4a7f976774427d664b4e
spool1     sfs3  545 MiB  Jun 12 2019 15:46  /stratis/spool1/sfs3  f9dc03a10e694c6b94024512f835af7a
# stratis blockdev list
Pool Name  Device Node     Physical Size  State  Tier
spool1     /dev/nvme0n1p5     228.83 GiB  InUse  Data

[mulkieran]

We would like to avoid having anybody commit to parsing the output from the CLI as it stands now w/ anything but their human eyes, that's for sure. One, among many, excellent reasons for this is that the sizes displayed in general do not represent exact values, but a range of values containing a finite, but potentially quite large, set of elements.

We're in a different position from a lot of other apps, because the CLI talks to the daemon across the D-Bus. In particular, the information about sizes that is transmitted across the D-Bus is exact, unlike that which is displayed in the CLI (which for formatting reasons is generally inexact).

We should anticipate specifying a structured output mode, and responding w/ structured output for every command, not just the list commands, in order to maintain consistency. We should also expect that the structured output should be richer and more exact than the human-reader directed output, since it is unconstrained by the formatting issues that plague human readable output.

The implementation of this should be relatively easy; the design of the structured output is the more challenging part. I would like it to be able to be formally validatable, if at at all possible.

[mulkieran]

How should we request machine readable output? I like the environment variable approach.

[mulkieran]

Blocked by #301.

[mulkieran]

See stratis-storage/project#77 (comment) for some remarks about __str__ representation of dbus types.

[mulkieran]

I think we should close this. The D-Bus API provides a good programmatic way of getting all the information that the daemon makes available. We can therefore straightforwardly write, e.g., an ansible module directly in Python. If a Stratis user has a reason to want to export information about the engine as structured text, it is very easy to write a small module to do so. If they do it in Python, they can choose to make use of our Python libraries for D-Bus, but as our blackbox tests demonstrate, these are not necessary. If they want to write it in another language, there are facilities for that. In fact, dbus-rs provides some automatic codegen from XML introspection data facilities that might help. So, we should leave it to a Stratis user to find the specific need and implement it, and then we should be happy to support them in their work.