[Beaker-devel] Tool for Inventory gathering

Amit Saha asaha at redhat.com
Wed Jul 10 01:13:07 UTC 2013



----- Original Message -----
> From: "Don Zickus" <dzickus at redhat.com>
> To: "Amit Saha" <asaha at redhat.com>
> Cc: "Beaker development" <beaker-devel at lists.fedorahosted.org>
> Sent: Tuesday, July 9, 2013 11:55:10 PM
> Subject: Re: [Beaker-devel] Tool for Inventory gathering
> 
> On Tue, Jul 09, 2013 at 02:51:08AM -0400, Amit Saha wrote:
> > 
> > 
> > 
> > The 'lshw' based inventory task also uses /proc/cpuinfo in addition to it's
> > own
> > profiled information for the CPU details.
> > 
> > Currently the inventory gathered from 'lshw' is used for the CPU details,
> > the
> > memory details and the device details. I think it's worth a shot to see if
> > reading
> > from udev's database (via pyudev) can substitute the last purpose of lshw
> > and hence
> > just be free from the external tools.
> > 
> > Suggestions and thoughts welcome.
> 
> While it is nice to avoid unnecessary dependencies on external tools,
> remember the advantages of doing so too.  That is if the output format
> changes for any arch, those tools will be adjusted accordingly or if new
> information presents itself, that would be immediately available using the
> tool (one would assume).  On the other hand, doing this by hand as you
> propose might keep things out of sync and increase the maintaince of such
> a custom tool.
> 
> There are tradeoffs, it would be nice to know that the dependency on lshw
> is so high that it benefits beaker to write its own tool.  Right now I
> don't see it (doesn't mean it is not there though).

Thanks Don for sharing your thoughts.

Yes, indeed there is a trade off between choosing 'lshw' (since smolt, our existing tool
has been well and truly abandoned and it's planned replacement doesn't seem to have 
had a start yet) and investing time to write our own scripts.

My experience with 'lshw' earlier this year was that it does very well on Intel and perhaps AMD
systems as well. But, it's capability decreases when it comes to ARM, s390 and PPC architectures, 
which is understood, since the Kernel itself exports far less information on these architectures.

So yes, I think the question is ultimately whether we take charge of 'lshw' and maintain it as our 
own tool enhancing it where we find it lacking. This will prevent us from depending on the upstream 
patches being merged by the author - which also means shipping our own versions of lshw in our 
repositories. Understanding the current code base is not the biggest of issues here, since I spent 
time with it earlier this year and the code is easy to understand. This is a definitely attractive 
option, since lshw is pretty much a "standard" for these kind of things.

And the alternative is is to use our scripts (standard library modules and using pyudev) to extract 
the information we need. I do believe that we will be able to get all the information on all the 
architectures we need using this approach, but I haven't done a lot of quantitative analysis. 
My preliminary analysis does however tell me that we can get what 'lshw' would get for us.


Best,
Amit.

-- 
Amit Saha <http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.


More information about the Beaker-devel mailing list