From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-devel(a)lists.fedorahosted.org
Sent: Wednesday, July 10, 2013 12:15:26 PM
Subject: Re: [Beaker-devel] Tool for Inventory gathering
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.
Valid points, Nick. If I understand correctly, this is what you are proposing:
- Patch lshw as and when needed and submit those patches upstream. When and whether
at all they get into lshw is lyonel's call.
- However, create and maintain a beaker-lshw package which will be rebuilt whenever we
have a substantial patch to server our immediate goals and will be the one we depend on
for our needs.
Did I get that right?
Best,
Amit.
--
Amit Saha <