canonical-ci-engineering team mailing list archive

[Vincent Ladeuil <vila+ci@xxxxxxxxxxxxx>]

>>>>> Julien Funk <julien.funk@xxxxxxxxxxxxx> writes:

    > There is a major reorganization of the machines in the lab right now, the
    > majority of them are being repurposed for the CI team.  There is a deck for
    > this at the sprint and I need to know what the QA Hardware Lab Story is for
    > us going forward.

    > Thoughts?

I'm not sure I understand the root need here.

Specific hardware is needed by devs to fix hardware specific bugs.

Who else needs exclusive access to hardware ?

I'd go even further: devs strongly prefers reproducing bugs *locally* so
*they* should get priority access to hardware and have them on their
desktop.

The ci lab manages reference hardware so automated tests can be run
there to guarantee the support.

This can (and should) be available to devs as a fallback because we
can't give every reference hardware to every dev.

So for very specific cases, devs can get exclusive access to a given
hardware.

AFAICS, all other uses should be pooled in the ci Lab to maximize:

- use of any available hardware,
- access to any available hardware.

I.e. no exclusive access for anybody as a rule.

We're far from there yet even internally for the ci engine, there are
already different pools targeted at different kind of tests.

This has already been identified as a paint point and a weakness because
the actual pools are of course smaller and when they become empty, the
ci engine is blocked and then everybody suffers.

The solution is clear for us: all those pools should be merged.

Defining *new* exclusive pools therefore sounds like a no-go to me.

Instead, we should make sure that QA and devs can define jenkins jobs or
even jenkins servers that *can* access that shared pool.

        Vincent