[Libosinfo] Libosinfo tools, could you help me to have a better understanding of those?

[Daniel P. Berrangé]

On Fri, May 03, 2019 at 04:24:44PM +0200, Fabiano Fidêncio wrote:
> People,
> 
> As part of libosinfo, we have a few tools: osinfo-detect, osinfo-
> install-script, and osinfo-query.
> 
> About osinfo-detect, it seems clear that the intetion of the tools is
> to detect whether we're able to recognise a media or tree. It's output
> is something like:
> ```
> fidencio at laerte ~ $ osinfo-detect ~/Downloads/Fedora-Workstation-
> netinst-x86_64-29-1.2.iso
> Media is bootable.
> Media is an installer for OS 'Fedora 29 Workstation'
> 
> fidencio at laerte ~ $ osinfo-detect --format env ~/Downloads/Fedora-
> Workstation-netinst-x86_64-29-1.2.iso
> OSINFO_BOOTABLE=1
> OSINFO_INSTALLER=http://fedoraproject.org/fedora/29
> OSINFO_MEDIA=http://fedoraproject.org/fedora/29:1
> ```
> Now, the questions that come to my mind are:
> - What kind of information should we return when a media is recognised?
> - How the information would be used? By whom?
> - Do we still care about --format env?

--format env was intended for udev scripts which was dropped in

  commit 16cf1f797728dff9e361033937faea9f38ffbe49
  Author: Zeeshan Ali (Khattak) <zeeshanak at gnome.org>
  Date:   Fri Feb 15 19:00:37 2013 +0200

    Ditch udev rule

What I find particularly horrible about --format env vs plain is
that they output different pieces of information.

I'd probably drop "env" and make a property JSON based format
for machine readability, while ensuring we report equivalent
set of info in all formts.

> About osinfo-install-script, it seems clear that the intention of the
> tool is to generate an install script for a supported distro. However,
> it doesn't generate any command line to be used together with the
> script. In any case, I'm really interested to know:
> - How those scripts are supposed to be consumed?
> - What was the idea behind the tool when it was created?
> - What do we want to achieve with this tool? (As in, who should be
> consuming the generated script and how?)

Mostly I intended it for people who are customizing the install
scripts to provide an easy way to see the expanded XSLT template.
ie an end user would take the template we provide, modify it some
and this is useful to see the results.

I also intended that users could take the output and use it with
the --initrd-inject arg to virt-install. Obviously they'd have
to also give the right --extra-args to go with it.

It would be useful if there was a flag to make it print the
extra args

Of course virt-install has native integration now, but I think
the general concept is still applicable / useful. For example
somone could use it to generate  kickstart that it then uploaded
to a tool like oVirt or OpenStack to automate an install.

> Last but not least, two general questions that involves all the tools
> we have and that may end up being answered by the questions raised
> above:
> 
> - Are those tools intended to be used together? As in:
>   - detect whether a media is recognised or not via osinfo-detect;
>   - use osinfo-detect output (or part of it) and pass it osinfo-query
> in order to get its id
>   - use the parsed output of osinfo-query and pass it to osinfo-
> install-script in order to generate an install script

There's no real grand unified vision like that, but obviously it
would be useful if the tools provide/accept the right kind of info
that lets them be used together.

osinfo-detect is particularly bad at this as it doesn't output
enough info todo reliable matching to osinfo-query

> - What to be tested on those tools in order to ensure we're not
> introducing any regression on them?

Whatever you think it useful. Any testing is better than the testing
we have today (none)

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|