Upgrading or Replacing AutoQA

[Tim Flink]

On Tue, 9 Jul 2013 08:26:01 -0400 (EDT)
Kamil Paral <kparal at redhat.com> wrote:

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

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

Yeah, I think we're of mostly the same idea. The infra needs to be
updated to make sure things continue to run but I don't want to put
much more effort into this than we have to.

> 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

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.

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

Agreed that maintaining the single RHEL6 machine isn't a big problem -
I was more noting that ansible-izing it would be a problem.

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

Are there any parts that you're more interested in than others?

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

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20130710/137b24bb/attachment.sig>