----- Original Message -----
From: "Amit Saha" <asaha(a)redhat.com>
To: "Beaker development" <beaker-devel(a)lists.fedorahosted.org>
Sent: Monday, July 8, 2013 4:53:59 PM
Subject: [Beaker-devel] Tool for Inventory gathering
Hi all,
I spent some time on Friday to see how the lshw based inventory task is doing
by running on one of our test systems - both in terms of what it gets
and how does it compare to the existing smolt based task.
I didn't go far with the comparison. Why? Because, lshw's parsing script
broke due to the XML being different for the particular CPU I was running on
and what the parsing script was expecting. I could fix it (like I have done
earlier) to accommodate for this formatting change..and do the same for
similar errors when I come across one.
But, here is what I am thinking:
Why don't we just get rid of the smolt and lshw tasks and instead query
directly from the /proc and /sys (procfs and sysfs)?
I have done some exploration in this area [1] and [2]. In [1], I am reading
directly off /proc and using Python's in built text
processing methods to get the information I want. Today I explored using
pyudev (Python interface to libudev for accessing the device
attributes from /sys) which you can see in [2].
From what I can see these are the information we usually look to get from our
inventory task and how
we could get them using one/both of the approaches (/proc and/or /sys):
- CPU details (easily done by reading /proc/cpuinfo)
- Memory details (easily done by reading /proc/memenfo)
- Disk details (we could continue using libparted - we will need to deal with
the shared library version choices that we currently have).
The total size is easily gettable from /sys/block, but I don't see a way to
get the geometry details.
- Devices (Gettable from /sys/devices)
What do you all think?
Here are the links:
[1]
http://amitsaha.github.io/site/notes/articles/python_linux/article.html
[2]
http://nbviewer.ipython.org/5946601
Best, Amit.
This morning, I spent some more time trying to see how much the Kernel exports into /proc
and /sys
on non-x86 archs. I tried s390x, ppc64 and armv7hl. And the data exported is not a lot.
On s390x running a 2.6 kernel, /proc/cpuinfo doesn't even have the CPU frequency:
vendor_id : <masked>
# processors : 2
bogomips per cpu: 11061.00
features : <feature list masked>
processor 0: version = FF, identification = <masked>, machine = <masked>
processor 1: version = FF, identification = <masked>, machine = <masked>
(<masked> stands for original data masked)
For comparison, all 'lshw' comes up with is:
description: Computer
width: 64 bits
*-core
description: Motherboard
physical id: 0
*-memory
description: System memory
physical id: 0
size: 491MiB
*-cpu
physical id: 1
bus info: cpu@0
*-network
description: Ethernet interface
physical id: 1
logical name: eth0
serial: 02:de:ad:be:ef:04
capacity: 1Gbit/s
capabilities: ethernet physical fibre 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd
autonegotiation
configuration: autonegotiation=on broadcast=yes driver=qeth_l2 driverversion=1.0
duplex=full firmware=V611 ip=<blah> link=yes multicast=yes port=fibre
This is not surprising, since it's probably a fair assumption to make that most user
space utilities
would depend on what the Kernel is exporting.
Of course things could be different on more recent Kernels.
On the other hand, querying devices using udev (via pyudev) works fairly well
even on these archs.
--
Amit Saha <
http://echorand.me>
Infrastructure Engineering and Development
Red Hat, Inc.