Re: AutoQA Staging Related Proposals
I put together some draft proposals on how I'd like to see us use
the
new staging environment.
As a whole, the two proposals will require a decent amount of time and
effort but I've tried to break them up into smaller chunks so that we
can start seeing the benefits sooner rather than later.
This all makes sense in my head and I think that I've put enough
detail
into the proposals for them to make sense to everyone else but I'm
sure
that I forgot some details. Please let me know what parts of this
aren't clear and I will add detail and/or clarify.
Other comments and/or suggestions are also very welcome.
Thanks,
Tim
The proposals sound wonderful. Unfortunately I don't have any experience with this
stuff, so I can't really imagine the amount of work involved, the action plan, or even
how to begin. Naive questions below.
AutoQA in a box:
- https://fedoraproject.org/wiki/User:Tflink/Sandbox:AutoQA_in_a_box
- The idea here is to automate the creation and updating of the AutoQA
environment. This would make it easier to setup dev environments and
simplify the management of the production infrastructure.
You speak about VMs. Does that mean you suppose everything will be in VM (even autoqa
server, etc)? Not everyone may want to set up the server in a VM, is bare-metal counted
in? Furthermore some clients need to be installed on bare-metal.
Will this approach be useful even for our development purposes? For example I don't
want to re-deploy some client VM image every time I make a change in AutoQA code.
If we use VM, how does that work with infrastructure team managing our machines? Will they
manage only bare-metal machines and we will manage the VMs (upgrading Fedora releases,
etc)?
When speaking of this, I'd like to have client so lightweight that they don't
require ANYTHING have maintained on them. Only the initial SSH key setup would be needed,
and nothing else, ever. Autotest already copies itself from server to client, tests are
copied from server to client, and when we implement #254 also AutoQA library will be
copied from server to client. Then we don't really have to care about clients - no
need to update in production environment, no need to do NFS mounts in dev environment.
AutoQA Staging:
-
https://fedoraproject.org/wiki/User:Tflink/Sandbox:AutoQA_staging_environ...
- This is the longer of the two proposals. I think that it will be
good for us in the long run and ties together some of the things
that we've talked about for testing AutoQA.
As for Stage 1: Isn't good enough just setting up cron to regularly do 'git pull
&& make clean install' as our "CI process"? If we are going to
examine tests results and autoqa logs manually, what are the benefits of hudson/buildbot?