Description of problem: Aggregated time used by given user for testing, possibly split by architecture. Ability to get the metric for given time frame (day, week, month). Additional info: Motivation is that managers want to have at least a basic usage accounting. Encourage users to keep https://wiki.test.redhat.com/Beaker/Etiquette. Requester: Platform QE
The reservation table is able to give the per machine data per user and other related information. To get the most accurate machine usage data per architecture, the per provision data from activity tables have to be mined. However, I learnt that these tables should not be used as their data storage formats have changed in the past and not to be relied upon for robustness. From my understanding, that leaves us with no direct way to to get the architecture of a provision (or a system reservation) considering the system as the central point. However, we do have the static data about what distro architectures a system can support. This can give an approximate idea about what architectures have been most used by a user - but ofcourse it can be very highly misleading. I can use x86_64 all the time on a system capable of running both x86_64 and i386. This doesn't mean I also used i386.. That said, it is possible to extract architecture specifications made by the user from the "_distro_requires" field of the recipe table for all the recipes which were either "Completed", "Cancelled" or "Aborted". I think this will be a good way to get the architecture specific information.
Welcome to the world of data mining - pristine data is a luxury, not a necessity. The activity table is what we want, even if it isn't pretty - sorting out inconsistent data over time is just part of the data miners task. If there are additional entries we can record to make this easier in the future, then that's mainly what this (and other issues targeted at 0.11) are about.
Admin guide updated to include the above information: http://gerrit.beaker-project.org/#/c/1546/
As discussed, patch using alternative approach with literal SQL query and test: http://gerrit.beaker-project.org/1575
Setting back to ASSIGNED. Report needs to include manual reservations also. Nick suggested the following approach to the problem of systems having multiple arches: combine them, so that i386, x86_64, and i386+x86_64 are distinct categories. (May want to apply this approach throughout the metrics code and reporting queries for consistency?)
http://gerrit.beaker-project.org/1609 Split into two queries: recipe-hours and machine-hours.
http://gerrit.beaker-project.org/1628
Beaker 0.11.0 has been released.