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

["Tomáš Golembiovský" <tgolembi@redhat.com>]

On Wed, 24 May 2017 23:51:55 +0200
Tomáš Golembiovský <tgolembi@redhat.com> wrote:

> On Wed, 12 Apr 2017 15:05:02 -0500
> Michael Roth <mdroth@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 <eblake@redhat.com> wrote:
> > >     
> > >> On 03/31/2017 05:19 AM, Vinzenz 'evilissimo' Feenstra wrote:    
> > >>> From: Vinzenz Feenstra <vfeenstr@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ý <tgolembi@redhat.com>


-- 
Tomáš Golembiovský <tgolembi@redhat.com>