> I would simplify it as much as possible. We have only two tests
now
> that have some kind of impact - depcheck and upgradepath - and that's
> just because of their bodhi integration. It's nice that we execute
> some other tests... but I don't think anyone really reads them.
Yeah, but if the maintenance burden isn't very high and we don't have
to do much extra work to keep them around, I don't see much harm in
doing so.
We would need more clients to execute more tests, that's the only increase of
maintenance effort I see here.
We *might* be OK with just a single host (qa01) with four VM test clients (virt01-virt04),
if we keep all the tests scheduled. Not sure.
That's the other reason I wanted to do this now - we still have
stg. I
figure that since there have been reports of issues with autotest on
f18, we can work on stg and getting the playbooks done before moving
everyting to production and reclaiming the infrastructure.
Autotest is used just on the RHEL6 machines, so there should not be any problems with
that. But we're not using the most current autotest version and if we would like to
change that, it would require some code changes. In this point, I'd rather continue
using the old version.
> I don't know anything about ansible, how much work it is and is it
> worth it just for a single machine? Or do you want to asible-ize the
> virt clients as well? (I don't think they need to be maintained).
> I'll be glad to help with all these tasks.
My plan was to re-use a lot of what infra has been doing with their
in-progress move from puppet to ansible. We would manage the virt and
bare-metal clients and the virt hosts (including VM spawning) with
ansible playbooks. A lot of the base machine and vm management stuff is
already in the infra repo.
In this point we don't need any bare-metal clients, so it's even easier.
Are there any parts that you're more interested in than others?
I'll gladly learn something about ansible and get some experience with it. I'm not
sure what the different available tasks are, but I can help with manual re-installation as
well.
> If we go this path, we end up with 6 free beefy machines
> (qa02-05,qa07-08) that we can hand back to Fedora Infra or we can use
> them for different purposes (TaskBot?).
Yeah, I suspect that we can get away with 3 machines for production and
all virt-clients since we're not actually running RATS or anything that
requires bare metal.
As noted above, autoqa01 as the scheduler and qa01 as a virt host might be enough
(depending how many tests we schedule); adding qa02 as another virt host should definitely
satisfy the needs.