Bug 1037690

The system history data is particularly problematic for machine parsing, because we do not really treat the history data as an API, it is intended just for human consumption. So field names, actions, and format of values have all changed at various times in the past. Also in some cases the old/new values are truncated because of MySQL limitations (bug 968715). We tried writing code to scrape system history for usage statistics and it was very hard to extract useful data for this reason.

Can you tell us what specifically in the history you want to extract? For example, if you're looking for reservation records (who reserved the system when) Beaker stores that separately in a properly structured way. We could expose an API for that which would be much simpler to use and more stable than scraping the system history.

I'd like to have some way of retrieving what distro tree was provisioned last (and therefore is likely to be still installed on the machine) and at what date/time (to guess whether the original owner still needs the machine).

I guess we could use beaker jobs for this, but we would need complete control over the installation and the final system - ie. no beah, no beaker kickstart, no tasks, ability to switch jobs between team members, ..., probably too much to work around.

In that case, this seems more like a use case for the time limited manual reservations planned for 0.16: http://beaker-project.org/dev/proposals/time-limited-manual-reservations.html

Although it does also suggest another RFE, which is to allow a group to be specified for manual reservations (so the SSH keys for all group members would be added to the system)

(In reply to Nick Coghlan from comment #4)
> In that case, this seems more like a use case for the time limited manual
> reservations planned for 0.16:
> http://beaker-project.org/dev/proposals/time-limited-manual-reservations.html

(In reply to Nick Coghlan from comment #5)
> Although it does also suggest another RFE, which is to allow a group to be
> specified for manual reservations (so the SSH keys for all group members
> would be added to the system)

Neither of those is really what we want.

We don't want time-based reservations because of (sometimes) very important nature of the software installed on the machines - the release process needs to be human-controlled. I wrote "to guess whether the original owner still needs the machine" meaning "whether we should ask the current user to release it or whether the machine is obviously in active use".

By "I guess we could use beaker jobs for this" I meant "jobs with very long test time, >1year, for safety".

We also don't want to reserve machines as a group without the ability to point out who (from the people in the group) reserved it and is responsible for it.

In contrast to all this, making simply history available via the bkr(1) command sounds simpler. I plan to write a regularly-executed script (bash), which would get various info from Beaker (current user, last installed tree and date, ...) and use these information to keep a certain table on a certain wiki page up-to-date.
We currently use etherpad and do all this work manually, which is not only somewhat time-consuming, but also inaccurate and hard to parse (or rely upon) from automated scripts, which automatically allocate free machines and perform nightly testing (with HEAVY use of expect(1) and ssh) on them.

Like group jobs, group reservations would still have a specific submitting user - it would just be a way to easily get additional SSH keys onto the system. However, it sounds like that isn't what you need at this point.

Bug 1037592 will make more system status information available through the CLI (either in the output of "bkr system-details" or through a new command). 

I'm also not clear on how it is OK to not reprovision the machine from scratch each time - how do you know the previous user hasn't left it in a broken state, even if it nominally has the right distro tree installed?

It's starting to sound to me like making the system note system available through the CLI would be a better solution than assuming that particular historical events mean particular things.

(In reply to Nick Coghlan from comment #8)
> Like group jobs, group reservations would still have a specific submitting
> user - it would just be a way to easily get additional SSH keys onto the
> system. However, it sounds like that isn't what you need at this point.
> 
> Bug 1037592 will make more system status information available through the
> CLI (either in the output of "bkr system-details" or through a new command). 
> 
> I'm also not clear on how it is OK to not reprovision the machine from
> scratch each time - how do you know the previous user hasn't left it in a
> broken state, even if it nominally has the right distro tree installed?

That's not a big problem for a team of 3-4 people - we simply ask each other. However we do that based on an "overview", which is now generated manually. My goal is to automatize that overview as much as possible.
The cost of a full reprovision is not that trivial for us as the kickstart does only a portion of the total work needed to bring the system to a testworthy configuration. Not to mention lots of distro bugs we have to work around.

> It's starting to sound to me like making the system note system available
> through the CLI would be a better solution than assuming that particular
> historical events mean particular things.
Making the note available would be great as well, we could store notes about provisions in Beaker, instead of sourcing them from an external storage, though I would classify the feature as low priority at this point.