On 04/03/2017 10:17 AM, Marc-André Lureau wrote: > Hi > > On Fri, Mar 31, 2017 at 3:41 PM Eric Blake <ebl...@redhat.com> wrote: > >> On 03/31/2017 05:19 AM, Vinzenz 'evilissimo' Feenstra wrote: >>> From: Vinzenz Feenstra <vfeen...@redhat.com> >>> >>> 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.
I like the idea of using an existing standard, but if they really want to get at a raw dump of /etc/os-release to use with existing tools then I think guest-file-open/read are the more appropriate interfaces. Knowing that they *can* get at information like that for a particular guest, or do things like execute 'uname -m' via guest-exec, is where I think an interface like this has it's place. So I think a more curated/limited set of identifiers is sufficient, and still flexible enough to enable to more os-specific use-cases. But I also don't like the idea of re-defining what terms like "version_id", "variant", "varient_id", etc mean, so I think it's still a good idea to use the os-release-documented fields as the basis for the fields we decide to return in our dictionary, and note that explicitly in the schema documentation.