----- Original Message -----
From: "Don Zickus" <dzickus(a)redhat.com>
To: "Amit Saha" <asaha(a)redhat.com>
Cc: "Beaker development" <beaker-devel(a)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.