I have devoted my last 2 years to testing Eucalyptus. In that period the QA team and I have gone through many iterations of tools to find those that make us most efficient. It has become a never ending and enjoyable quest.
We have evolved our testing processes through the following stages:
Using command line tools exclusively
Writing scripts that call command line tools and parsing their output
Writing scripts using a library to make test creation easier and more efficient without the need for command line tools
Running scripts through a graphical tool in order to make test execution more flexible and simple
Each of these iterations was fueled by some tool chain that came along to solve a problem. My journey at Eucalyptus started between the second and third stages. Euca2ools were the go to favorite for manual testing and there was a library aptly named ec2ops floating…
Allows you to build production-ready, AWS-compatible private and hybrid clouds by leveraging your existing virtualized infrastructure to create on-demand cloud resource pools.
What happens when you combine all three of these tools? A potent combination for continuous integration on a easy-to-configure PaaS and an on-premise, AWS-compatible IaaS. With this combination, developers can take advantage of easy configuration that Stackato brings to the table, running on top of Eucalyptus – bringing an AWS-like cloud environment into your datacenter.
This blog entry will discuss the steps that I took to get Jenkins installed on a Stackato instance store-backed instance running on Eucalyptus. But before I get started, I would like to thank the folks from ActiveState for all their guidance. Their support staff is really top notch, and very helpful. Check them out in #stackato on freenode.net. They can also be checked out on Twitter at @ActiveState. Now on to the dirty work…..
After downloading the Stackato VM for KVM and unzipping the file, we will need to pull out the root file system, the kernel and ramdisk. These will be uploaded, bundled and registered as the EMI, EKI, and ERI. To extract the root filesystem, do the following:
Use parted to locate the root filesystem as follows:
# parted stackato-img-kvm-v2.6.6.img
GNU Parted 2.1
Welcome to GNU Parted! Type 'help' to view a list of commands.
Unit? [compact]? b
Disk /root/images/Stackato-VM/stackato-img-kvm-v2.6.6.img: 10737418240B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1048576B 200278015B 199229440B primary ext3 boot
3 200278016B 1237319679B 1037041664B primary linux-swap(v1)
2 1237319680B 10736369663B 9499049984B primary ext4
In this example, the root filesystem is partition 2. The value for “Start” and “Size” will need to be used. Next, run dd to extract the root filesystem:
Once it has completed, mount stackato-rootfs.img to the loopback device:
mount -o loop stackato-rootfs.img /mnt/
Copy out initrd.img-3.2.0-27-virtual and vmlinuz-3.2.0-27-virtual from /mnt/boot.
In /mnt/etc/fstab, replace the UUID entry with LABEL. The LABEL will look simliar to the following:
LABEL=cloudimg-rootfs / ext4 defaults 1 1
Chroot to /mnt – there may be a need to do a mount -o bind for sys, dev, and proc.
Run “dpkg-reconfigure cloud-init”, and make sure that the EC2 Data Source is selected.
Unmount stackato-rootfs.img (if sys, dev, and proc were mounted, unmount them before unmounting stackato-rootfs.img). After it has been unmounted, run tune2fs to change the label of the image:
tune2fs -L cloudimg-rootfs stackato-rootfs.img
After following these steps, the following should be available:
initrd.img-3.2.0-27-virtual – to be bundled, uploaded and registered as the ERI
vmlinuz-3.2.0-27-virtual – to be bundled, uploaded and registered as the EKI
stackato-rootfs.img – to be bundled, uploaded and registered as the EMI
Go through the steps of bundling, uploading and registering the ERI, EKI, and EMI. For additional information, please refer to the Add an Image section of the Eucalyptus 3.2 User Guide.
Launching the Stackato Image
Now its time to launch the Stackato image on Eucalyptus. Since cloud-init has the enabled EC2 data source now, when the image is launched, the instance will grab ssh keys, and mount the ephemeral storage. Also, additional configuration can be passed using the user-data file option. More information regarding this can be found on Stackato’s documentation in reference to using cloud-init. Key thing to remember here is that the minimum RAM requirement for the Stackato image is 2 gigs. Make sure the VM type used for launching the Stackato image has at least 2 gigs of RAM or more. In this example, the image ID is emi-DAB23A8A. The ramdisk and kernel are registered as eri-9B453C09 and eki-ADF640B0. The VM type c1.xlarge is used, which has 4 CPU, 4096 MB of RAM, and 50 Gigs of disk space.
The key thing for running a Stackato instance is setting up the correct DNS entries. For more information regarding setting up DNS with regards to a Stackato instance, please read the Detail Configuration section on DNS in the Stackato online documentation. For this example, instead of using an external DNS service using a tool like nsupdate, to configure the A record and CNAME records, we will use xip.io. xip.io is a magic domain name that provides wildcard DNS for any IP address. Next, its time to configure the Stackato instance.
Configuration of the Stackato Instance
To configure the Stackato instance, do the following:
Make note of the ip address associated with eth0 and the netmask using ifconfig. Also note the gateway IP by using the route command.
Run “kato op static_ip” to configure the static IP address for eth0. Make sure and add 127.0.0.1 as the first entry as part of the nameservers, and add “containers.” as the first entry under the search domains.
Run “kato rename public DNS name “, where public DNS name includes the public IP of the instance, using xip.io (e.g. 192.168.55.104.xip.io)
Run “kato disable mdns”, then run “sudo reboot” to reboot the instance.
Once the instance has come back up, ssh into the instance, and run the following command “kato setup core api.public DNS name” where public DNS name is the same value used for the “kato rename” step (e.g. 192.168.55.104.xip.io).
Next, edit /etc/resolv.conf and make sure that the value for the search option is “containers.”, and the first entry for the nameservers is 127.0.0.1.
After setting up the admin account, navigate to the “App Store” on the lefthand menu. Once selected, navigate to find the Jenkins application:
After selecting to install Jenkins, select “Yes” to install. After the installation takes place, select “Applications” in the left hand menu. From there, select the Jenkins application, and select “Start” (its the green arrow to the right of the application window). Once it has started, you will see the following:
Now Jenkins is ready to be used.
If anyone wants to test this out on Eucalyptus but doesn’t have access to their own Eucalyptus cloud, fear not, the Eucalyptus Community Cloud has the Stackato image available. After applying to get access to the Community Cloud, follow the steps above. The image for Stackato is as follows:
IMAGE emi-859B3D5C stackato_v2.6.6/stackato-cloudinit.manifest.xml 150820662310 available public x86_64 machine eki-6FBE3D2D eri-67463B77 instance-store
And as always, this image and steps can be used on AWS EC2 as well.🙂
Let me know if there are any questions. Feedback is always welcome. Enjoy!
This post will lead you through the creation of an environment to run automated test plans against a Eucalyptus installation. The tools used were described in my previous post, namely Jenkins (orchestrator), Testlink (planning & metadata), Eutester (functional testing framework). The use case we will be attacking is that of the Developer QA system sandbox.
The only requirements for this setup:
Your machine can run Jenkins
Python 2.6 or greater installed
Python virtualenv is installed (easy_install virtualenv)
Git is installed
Once complete you should be able to run test plans against a running cloud with the click of a button. This has only been tested on my Macbook but should work on any platform that can meet these requirements.
The first step in getting this system up and running is to download and install Jenkins on the desired host machine. When completing this…
Manual testing is a key element to a hardened QA process allowing for the human mind to be used in tasks that lend themselves to critical thinking or are simply not automatable such as:
Exploratory (also called ad-hoc) which allows testers to test strange and unusual codepaths
Use Case which intends to simulate as closely as possible the end to end solution that will be deployed
Usablility which aims to test whether the product meets the timing, performance, and accessibility needs of the end user
The only way to have enough time to do these kinds of tests (my favorite is exploratory) is to automate as much of the functional and regression testing as you can. Once you know a proper and reliable procedure for producing a functional test it is time to stick that in a regression suite so that it no longer needs to be run by…