On 07/10/2013 11:13 AM, Amit Saha wrote:
----- 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.
lshw getting fixed doesn't happen magically - it gets updated when
people with access to relevant hardware offer patches and they get
incorporated into a new release. People like us :)
> 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.
I think it's entirely worth it to keep offering patches to lshw - we
have access to more systems than most, so we're well positioned to
ensure lshw works properly across a wide range of hardware. However, we
also need to deal with the near term problem of wanting to decouple
improvements in our inventory scripts from upstream releases of lshw.
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.
It's not a matter of "taking charge" - it's a matter of approaching
Lyonel and explaining that we'd like to help with lshw maintenance and
support for non-x86/x86_64 systems, as well as making more regular
releases (whether that's through the existing SVN/Trac setup on
ezix.org
or through populating the empty Git repo he created for it on GitHub).
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.
Independent of what happens upstream, I think it is worth our while to
create a "beaker-lshw" package that we use in our inventory task. Over
time, the number of custom patches we have to carry will hopefully
decline, especially if Lyonel is open to the idea of more direct
assistance with maintenance.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (
http://beaker-project.org/)