Bug 193142

jkt said:
> > * number of kernel-hugemem, kernel-smp, & kernel-largesmp systems
>
> This might have been discussed already, but what does the above mean
> exactly?

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.

Ah . . . gotcha.  Number of capable systems.  That certainly makes sense.

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

Yup, this is still a valid request.

Bulk reassignment of issues as Bill has moved to another team.

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.

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.

*** Bug 500835 has been marked as a duplicate of this bug. ***

*** Bug 877267 has been marked as a duplicate of this bug. ***

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

Admin guide updated to include the above information: http://gerrit.beaker-project.org/#/c/1546/

(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

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

http://gerrit.beaker-project.org/1625

Beaker 0.11.0 has been released.