test data request

[Zygmunt Krynicki]

On Mon, Jan 16, 2012 at 1:55 PM, Alexander Sack <asac at linaro.org> wrote:
> On Mon, Jan 16, 2012 at 1:44 PM, Paul Sokolovsky
> <paul.sokolovsky at linaro.org> wrote:
>> On Sun, 15 Jan 2012 21:14:05 +0100
>> Zygmunt Krynicki <zygmunt.krynicki at linaro.org> wrote:
>>
>>> On Sun, Jan 15, 2012 at 7:48 PM, Alexander Sack <asac at linaro.org>
>>> wrote:
>>> > On Sun, Jan 15, 2012 at 3:49 AM, Zach Pfeffer
>>> > <zach.pfeffer at linaro.org> wrote:
>>> >> Do you have a way we can dump the date and time of every build
>>> >> that we've done?
>>> >>
>>> >> Then we can take the data Zygmunt produced and merge it with that
>>> >> data, and come up with our super cool graphs!
>>> >
>>> > Unfortunately, we don't have infinite history on android-build
>>> > (think just 1 build).
>>> >
>>> > Not sure if we can grep some log from our server that isn't subject
>>> > to our retention mechanisms?
>>> > Maybe jenkins has more logs that date back longer?
>>>
>>> I would recommend to store the build date as an attribute
>>> 'android.build-date' in the standard format 'yyyy-mm-ddThh:mm:ssZ', we
>>> can harvest that in lava and will build improved history for the
>>> future.
>>
>> If it would useful to start doing that from now on, yes that can be
>> added. Otherwise, we'd need to join LAVA and Android Build data anyway,
>> and primary key is (job_name, build_no), which is already present in
>> LAVA (in the form of build URL).
>>
>
> Yes, having our build data go into central lava database next to the
> test results etc. can only be beneficial and would be awesome. Would
> we replay the data for the builds of last three month?
>
> On this front to remember to think about: How can we ensure that
> bundles don't get lost if lava is temporarily down?

We were considering two options here:

1) Make each part of linaro infrastructure spool data instead of
assuming lava is always up
2) Run a centralized spool in the cloud. This 'spool' would 'never' go
down and would store&forward all requests back to the lab. This is
harder to do because some of our requests reply with a response ID of
some kind. We'd have to ensure that id can be client-assigned and that
our key API is response-free.

ZK