Upgrading or Replacing AutoQA

Kamil Paral kparal at redhat.com
Tue Jul 9 12:26:01 UTC 2013


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.

So, until we have something better, I'd aim for a very lightweight AutoQA instance that performs the most important tasks, but does not require too much maintenance.

My idea:
1. Disable all tests except for depcheck and upgradepath
2. Completely ditch autoqa-stg01 instance, we don't do any development anymore. That will also free all its clients: qa07 and qa08
3. In the production environment, ditch qa02, qa03, qa04 and qa05. That also disposes of all current VM clients.
4. Use qa01 as a host for two VM clients, virt01 and virt02. They can be both F18, or F19, or mixed. One i386 and one x86_64 (depcheck is arch specific).

The resulting infrastructure is extremely simple then:

                  .----------.
                  |   qa01   |
 .----------.     |.--------.|
 | autoqa01 |----->| virt01 ||
 '----------'     |'--------'|
       |          |.--------.|
       '---------->| virt02 ||
                  |'--------'|
                  '----------'

autoqa01 is RHEL6 and can't be in infra repositories due to software dependencies. qa01 can. So, we would have just a single machine to re-install and maintain. The test clients are pretty simple to set up, you just need to install them, adjust /etc/hosts and put their ssh key into autotest.

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.

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


More information about the qa-devel mailing list