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@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@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@xxxxxxxxx> 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 :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
