Upgrading or Replacing AutoQA

[Kamil Paral]

> > 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.