Add a "time of last job" column (in relative times if that's ok). We could populate this dynamically client side, similar to the slave health page. I am not sure if we have this exact information, but I suspect we do and can make a new column on the table with this item.

How this data can be fetched? Is there some API?

oh, this is missing :( We have starttime and endtime to calculate duration: https://github.com/dminor/ouija/blob/master/src/updatedb.py#L122 we also store the date, but this is the date of the push to the tree. Should we change what date we store? Should we add another field for job start or job end? :edmorley- what would be a useful time to base off, starttime or endtime? I would vote for starttime :dminor- would you prefer a new field for the timestamp or changing the date that we use? I would vote for changing the date

(In reply to akruglov from comment #1) > How this data can be fetched? > Is there some API? See bug 936610 comment 2 :-) (In reply to Joel Maher (:jmaher) from comment #2) > :edmorley- what would be a useful time to base off, starttime or endtime? I > would vote for starttime Yeah starttime :-)

Changing the date makes sense to me.

(In reply to Ed Morley [:edmorley UTC+1] from comment #3) > (In reply to akruglov from comment #1) > > How this data can be fetched? > > Is there some API? > > See bug 936610 comment 2 :-) > It requires authentication.

(In reply to akruglov from comment #5) > It requires authentication. Yeah this is expected (and unavoidable afaik) to set this up test, you may need to request that your LDAP account have the appropriate bits set to access slavealloc (see bug 887033 for an example of such a request). Callek - is there any way we could get read-only access to slavealloc without requiring non-default LDAP bits be set?

(In reply to Ed Morley [:edmorley UTC+1] from comment #6) > (In reply to akruglov from comment #5) > > It requires authentication. > > Yeah this is expected (and unavoidable afaik) to set this up test, you may > need to request that your LDAP account have the appropriate bits set to > access slavealloc (see bug 887033 for an example of such a request). > > Callek - is there any way we could get read-only access to slavealloc > without requiring non-default LDAP bits be set? I don't think so, but I'm not an expert here, redirecting to :dustin

Slavealloc doesn't distinguish read-only from read-write, so that's not possible. We're simultaneously starting to make the data in slavealloc more security-sensitive, so having external tools talking to it is probably not a good idea.

can we make the process/tool when enabling/disabling a slave write to a secondary data source that is public?

(Even if it's just enable/disable state)

I think that would be slaveapi. In fact, I'd argue we should make slavealloc a component of slaveapi.

We're planning to move this functionality to Treeherder anyway (Bug 1071152) so there is no point in fixing it here.