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?).
_______________________________________________
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
