Re: [Qemu-devel] [PATCH v3] qemu-ga: add guest-get-osrelease command

[Marc-André Lureau]

Hi

On Fri, Mar 31, 2017 at 3:41 PM Eric Blake <address@hidden> wrote:

> On 03/31/2017 05:19 AM, Vinzenz 'evilissimo' Feenstra wrote:
> > From: Vinzenz Feenstra <address@hidden>
> >
> > Add a new 'guest-get-osrelease' command to report OS information in the
> > os-release format. As documented here:
> > https://www.freedesktop.org/software/systemd/man/os-release.html
> >
> > The win32 implementation generates the information.
> > On POSIX systems the /etc/os-release or /usr/lib/os-release files
> > content is returned when available and gets extended with the fields:
> > - QGA_UNAME_RELEASE which is the content of `uname -r`
> > - QGA_UNAME_VERSION which is the content of `uname -v`
> > - QGA_UNAME_MACHINE which is the content of `uname -m`
> >
> > Here an example for a Fedora 25 VM:
> >
> > virsh # qemu-agent-command F25 '{ "execute": "guest-get-osrelease" }'
> > {"return":{"content":"NAME=Fedora\nVERSION=\"25 (Server Edition)\"\n
> > ID=fedora\nVERSION_ID=25\nPRETTY_NAME=\"Fedora 25 (Server Edition)\"\n
> > ANSI_COLOR=\"0;34\"\nCPE_NAME=\"cpe:/o:fedoraproject:fedora:25\"\n
> > HOME_URL=\"https://fedoraproject.org/\"\n
> > BUG_REPORT_URL=\"https://bugzilla.redhat.com/\"\n
> > REDHAT_BUGZILLA_PRODUCT=\"Fedora\"\n
> > REDHAT_BUGZILLA_PRODUCT_VERSION=25\nREDHAT_SUPPORT_PRODUCT=\"Fedora\"\n
> > REDHAT_SUPPORT_PRODUCT_VERSION=25\n
> > PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy\n
> > VARIANT=\"Server Edition\"\nVARIANT_ID=server\n\n
> > QGA_UNAME_RELEASE=\"4.8.6-300.fc25.x86_64\"\n
> > QGA_UNAME_VERSION=\"#1 SMP Tue Nov 1 12:36:38 UTC 2016\"\n
> > QGA_UNAME_MACHINE=\"x86_64\"\n"}}
>
> Uggh. This is a step backwards.  Now you are requiring the end user to
> parse a raw string, instead of giving them the information already
> broken out as a JSON dictionary.
>

yes otoh, it uses an existing standard to retrieve various guest os release
informations, which existing tool may know how to handle.

(I feel partially guilty about it since I suggested it, mainly in a
discussion over irc and Vinzenz adopted it)

The format is fairly straightforward to parse, but perhaps it should be
sent as a JSON dict instead? However, that would mean that the list of keys
is limited by what QGA protocol defines, and the agent would have to parse
the file himself. And we would have to duplicate the documentation etc..

I would rely on the XDG format instead, given its simplicity, extensibility
and documentation that fits the job nicely imho.

-- 
Marc-André Lureau