At the moment we test a full Aegir install using Rackspace cloud, basically we do the following:

  1. Deploy a new Rackspace server from a pre-built image that has MySQL and some other bits already set up for Aegir.
  2. Run the Aegir install process on the server.
  3. Run the Aegir tests.

Rackspace fails to deploy the new server intermittently and is quite slow, circa 7~8 minutes to deploy the server. This means that half our time is spent waiting for Rackspace to do stuff.

Omega8cc has kindly given the Aegir project a very nice dedicated server that we can use for automated testing.

We should thus switch step one above to use Vagrant to deploy new virtual machines on this new dedicated machine. Now, there is a Jenkins plugin that helps one deploy Vagrant boxes and what not, but it only works if the Jenkins master == Vagrant host. So we'd need to move our Jenkins over to the new machine it would seem if we want to use that plugin. Vagrant is pretty easy to use though, so for a little more work we could just call vagrant directly, instead of going through a plugin. In theory I guess this means that actually the script that runs the test doesn't depend on Jenkins at all, as it will take care of calling vagrant correctly and provisioning etc.

I guess that we'll want to set up some puppet config for this new server so that we capture all the config for it also.

This thread is largely just going to be a brain dump of thoughts, so feel free to add to it!

Comments

steven jones’s picture

steven jones commented

I guess something we need to decide is do we want the existing Jenkins master server still? Or should we just get rid of it? It also hosts the debian packages, so we'd need to move those too.

I'm torn, and could be persuaded either way I think.

omega8cc’s picture

omega8cc commented

I didn't try/compare doing this with Vagrant, and have no idea if Jenkins could use existing on this machine VServer setup (why not, it is simple), but provisioning VServer based guest from local image is just one command and takes seconds, or maybe there are better reasons to use Vagrant instead, I don't know.

In this case Jenkins should be able to do stuff on the remote server, but then I agree that it is worth to re-think if we still need separate servers.

steven jones’s picture

steven jones commented

So the main reason for using Vagrant is that it means we have a single system for testing Aegir that I can also use on my machine here, so the automated tests are testing the same thing, and working on them is also useful for developers developing Aegir.

I think the more I think about it we just need some scripts that use Vagrant to provision a machine and then run our existing install and setup scripts on it. No special Jenkins plugins.

anarcat’s picture

anarcat commented

This is all quite resonable. I believe we should just move the server off to omega8cc's, not try to fool around with slaves....

Anonymous’s picture

Anonymous (not verified) commented

+1 for moving/decommissioning the Jenkins server to Omega8cc. It only means I save money :) though I am happy to keep it if you want to leave the debian repos there and 'spread around' the responsibility of aegir infrastructure among the team (e.g no bus factors)

I think Jenkins still has its uses mainly in its ability to track git changes: e.g it could detect the change from git, and *then* run a series of scripts to execute vagrant.

anarcat’s picture

anarcat commented

I think we should also move the repo. I am therefore putting the 2.x repository creation on hold until we move the repository, no use in creating this twice, see #1599606: publish debian packages for 2.x and 2.0-alpha1.

Note that the exact instructions used to create the debian repository are here: https://wiki.koumbit.net/RepreproConfiguration

Koumbit also has puppet code for this: https://redmine.koumbit.net/projects/puppet-reprepro/repository

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented

While still under heavy development, Aegir-up and Drush Vagrant are being built specifically to support creation of and collaboration across local development and testing environments.

Provisioning a Vagrant VM and installing Aegir on it (both from .debs, and 'manually' from arbitrary Git repos) is already well-supported, and requires only a single command (e.g., drush vagrant build --project-name=test2 --blueprint=utility or drush vb --project-name=test3 --git-repo=git://arbitrary/git/url/containing/a/vagrant/project -y). Also, installation is handled via the Drush and Aegir Puppet modules, and so also stress tests these components.

Recall that using Vagrant, we aren't limited to just provisioning a single VM, but can in fact deploy an entire network of systems, each individually configured. This is relatively easily accomplished with Aegir-up (though not yet in place), and will allow testing of remote db servers, webpack, &c.

In addition, Aegir-up can build a Jenkins server in a Vagrant VM, though this functionality is still relatively basic. In the medium-term, I'd like to enable deployment of a local CI server that'll be capable of running Aegir through it's paces with minimal intervention. This should help in development of both Aegir contrib modules and Aegir core patches, as well as the creation of new tests. If we handle our testing in a fashion that easily allows others to deploy their own CI servers and such, we'll allow the community to help develop and improve this testing infrastructure. I suspect that this would allow the codification of dev-staging-prod best-practices and help vault Aegir into a position of prominence as a Drupal development tool.

So, I'd like to suggest an evaluation of these tools by the maintainer team, for possible inclusion in the testing process.

steven jones’s picture

steven jones commented
Assigned: Unassigned » mig5
Status: Active » Postponed (maintainer needs more info)

Mig5 we moved over to using Vagrant and Omega8cc's new server, ping me on IRC and I will set you up with a user account on that machine.

We may want to keep the old server around just in case, and then at some point in the near future retire it.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented
Status: Postponed (maintainer needs more info) » Fixed

I believe this is all done. Feel free to re-open if there's anything outstanding.

anarcat’s picture

anarcat commented

Did we retire the old server?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.