On Wed, 24 May 2017 23:51:55 +0200 Tomáš Golembiovský <tgole...@redhat.com> wrote:
> On Wed, 12 Apr 2017 15:05:02 -0500 > Michael Roth <mdr...@linux.vnet.ibm.com> wrote: > > > 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. > > > > So what about the following, would that be acceptable? > > > ## > # @GuestOSRelease: > # > # @content: > # POSIX systems the @kernel_version, @kernel_release and > # @machine_hardware correspond to the values release, version and > # machine returned by uname(2). On Windows, they correspond to the > # version number, build number and architecture. > # > # On Linux-based system where os-release info is available either > # from /etc/os-release or from /usr/lib/os-release, the fields @id, > # @name, @pretty_name, @version, @version_codename, @variant, > # correspond to the fields of the same name defined in > os-release(5). > # On Windows, the data is generated based on the available > # inforamtion. > # > # Since: 2.10 > ## > { 'struct': 'GuestOSRelease', > 'data': { > 'kernel_release': 'str', > 'kernel_version': 'str', > 'machine_hardware': 'str' > 'id': '*str', > 'name': '*str', > 'pretty_name': '*str', > 'version': '*str', > 'version_codename': '*str', I forgot version_id here, maybe it can go in place of version_codename... or do we want both? > 'variant': '*str', And here I forgot variant_id. Tomas > } } > > > Tomas > > > -- > Tomáš Golembiovský <tgole...@redhat.com> -- Tomáš Golembiovský <tgole...@redhat.com>