Bug 193142 - [RFE] Report for hardware utilization and coverage
[RFE] Report for hardware utilization and coverage
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: reports (Show other bugs)
0.5
All Linux
high Severity medium (vote)
: 0.11
: ---
Assigned To: Dan Callaghan
Nick Coghlan
Measurements
: FutureFeature
: 500835 (view as bug list)
Depends On: 883606
Blocks: 593663
  Show dependency treegraph
 
Reported: 2006-05-25 12:42 EDT by Ben Levenson
Modified: 2013-01-16 23:33 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-16 23:33:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Levenson 2006-05-25 12:42:09 EDT
Description of problem:
Here are the features I'd like to see, but I'm sure everyone else has a request
or two:
* number of systems by architecture
* number of kernel-hugemem, kernel-smp, & kernel-largesmp systems
* total number Available, Unavailable, Developer, etc.
* number of systems by cpuinfo:vendor_id:family
* Tom mentioned something about # of systems by manufacturer too

Additional thoughts after looking at systems.cgi
* the number of days a system has been Available, Unavailable, Developer, etc.
* a dashboard with a summary of # Available, # Unavailable, etc...
* total number of days active in RHTS -- to give us a sense of system 
"freshness"
Comment 1 Ben Levenson 2006-05-25 12:58:01 EDT
jkt said:
> > * number of kernel-hugemem, kernel-smp, & kernel-largesmp systems
>
> This might have been discussed already, but what does the above mean
> exactly?
Comment 2 Ben Levenson 2006-05-25 12:58:52 EDT
I think it would be useful to see the number of systems in RHTS that are
targeted by those kernels.  For example:
# of systems with 16 or more Gigabytes of RAM
# of x86_64s with more than 8 CPUs
# of PPCs with more than 64 CPUs
# of ia64s with more than 64 CPUs

The answers might be 1, 0, 0, 0 right now, but I imagine it won't be too long
before we have some systems to track.
Comment 3 Jay Turner 2006-05-25 14:01:21 EDT
Ah . . . gotcha.  Number of capable systems.  That certainly makes sense.
Comment 4 Bill Peck 2010-04-07 08:37:19 EDT
Notice:

Legacy RHTS is soon to be retired and replaced by Beaker. As part of
this migration process all RHTS bugs need to be re-verified against a
Beaker instance by the cut-off date

   5pm Monday April 12th UTC-4. 

Please confirm this bug is still relevant to Beaker by re-verifying it
against the stage deployment of Beaker https://beaker-stage.app.eng.bos.redhat.com.

To keep this bug open please comment on it

If it has not received a comment by that date the bug will be closed/wontfix.

After the cutoff date all commented bugs will be moved to the Beaker
product.


thank you
Comment 5 Ben Levenson 2010-04-08 12:48:16 EDT
Yup, this is still a valid request.
Comment 6 Nick Coghlan 2012-10-17 00:38:45 EDT
Bulk reassignment of issues as Bill has moved to another team.
Comment 7 Nick Coghlan 2012-11-07 07:37:17 EST
Note that the current version of Beaker includes a comprehensive system search capability which reports the number of systems that meet those criteria.

However, keeping this open as good tracking of usage over time is a desirable feature which could still use some improvements.
Comment 8 Nick Coghlan 2012-12-04 20:51:26 EST
Amit, please look into this one (since you've been trawling through the activity table a bit lately). I suspect we're going to need some additional activity table entries to make it practical to extract the desired usage data (e.g. creating a new one in install_done).

The existing utilisation graph may provide some pointers.
Comment 9 Nick Coghlan 2012-12-04 20:53:35 EST
*** Bug 500835 has been marked as a duplicate of this bug. ***
Comment 10 Nick Coghlan 2012-12-04 21:01:15 EST
*** Bug 877267 has been marked as a duplicate of this bug. ***
Comment 11 Amit Saha 2012-12-05 22:02:49 EST
Feature list and possible solutions:

* number of systems by architecture

I think we are really talking about capability here since a system can be provisioned with  distros of different arch:

mysql> select arch.arch,system.fqdn from system,arch,system_arch_map where system.id=system_arch_map.system_id and system_arch_map.arch_id=arch.id;

Would return the architectures currently active and systems.

To get a list of all the possible archs and systems, if any:

mysql> select arch.arch,system_arch_map.system_id from arch LEFT OUTER JOIN system_arch_map ON system_arch_map.arch_id=arch.id;


* number of kernel-hugemem, kernel-smp, & kernel-largesmp systems

I think this roughly translates to the memory and number of cores in a system, which can be found using the cpu and system tables, as also outlined below.


* total number Available, Unavailable, Developer, etc.

The systems available is subject to constraints such as being private, belonging to a certain group, etc. The status field in the System table can be queried for systems in Automated (available to the scheduler, but subject to permission constraints), Manual (reserved and not available to the scheduler), broken machines or systems which have been removed.

The user_group, system_group, system tables can be used for this purpose.


* number of systems by cpuinfo:vendor_id:family
* Tom mentioned something about # of systems by manufacturer too

The CPU table (with system_id field) can be used to obtain information on systems with a particular CPU family, vendor, model, processors, sockets, cores, etc. Of interest is also the key_ and key_value_string tables from which system inventory information can be retrieved.  


* #of systems with 16 or more Gigabytes of RAM

mysql> select system.fqdn  from system where memory>16;


* # of x86_64s with more than 8 CPUs
* # of PPCs with more than 64 CPUs
* # of ia64s with more than 64 CPUs

The cpu and system_arch_map tables can be used to retrieve this information.


* Total number of days active in RHTS:

mysql>select system.fqdn,timediff(current_timestamp,date_added) from system group by system.fqdn
Comment 13 Amit Saha 2012-12-11 02:55:22 EST
Admin guide updated to include the above information: http://gerrit.beaker-project.org/#/c/1546/
Comment 14 Dan Callaghan 2012-12-17 23:27:32 EST
(In reply to comment #11)
> * number of systems by architecture
> * total number Available, Unavailable, Developer, etc.

These will be satisfied by the new Graphite metrics.

> * number of kernel-hugemem, kernel-smp, & kernel-largesmp systems

I don't think we need to worry about this anymore, modern RHELs don't have such distinctions as far as I can tell.

> * number of systems by cpuinfo:vendor_id:family
> * Tom mentioned something about # of systems by manufacturer too
> * #of systems with 16 or more Gigabytes of RAM
> * Total number of days active in RHTS

http://gerrit.beaker-project.org/1577
Comment 15 Nick Coghlan 2013-01-09 23:40:24 EST
system-age.sql
    The "age_days" calculation in is MySQL specific - this should be noted as a comment (I'm not aware of a cross-DB way to do that calculation)

system-count-by-arch-cpu-cores.sql
  Needs to use cpu.cores throughout (no cpu_cores)
  Needs to group by arch.arch rather than arch.id

system-count-arch-memory-gb.sql
  I can't get this to work at all in psql (the round call fails, plus the same inability to group by an aliased value or display a non-grouped value as seen in the previous one).

system-count-by-cpu.sql and system-count-by-vendor.sql both work correctly in a psql client
Comment 17 Dan Callaghan 2013-01-10 00:30:14 EST
http://gerrit.beaker-project.org/1625
Comment 18 Dan Callaghan 2013-01-16 23:33:48 EST
Beaker 0.11.0 has been released.

Note You need to log in before you can comment on or make changes to this bug.