Environments, automation, continuous integration

This script will search through all the network adaptors in your organisation and find the one with the correct IP address assigned to it. From there, you can work out which VM/vApp has that IP.

Unfortunately this method is quite slow, due to the fact that the Get-CINetworkAdapter command takes quite a while to respond. If I come up with a way to achieve this via the REST api, I’ll post it here.

The bulk of my experience in VMWare PowerCLI since I started a year ago has been spent creating scripts that work with a local vSphere installation. I’ve been looking into the API that VMware provides for vCloud Director 5.1, which I find to be quite a different kettle of fish.

One difference I’ve found is the way in which guest customisation scripts are handled. In vSphere PowerCLI, you create customisation profiles in the GUI, then pass the profile name as a parameter to the VM;

In vCloud’s flavour of PowerCLI though, there is no concept of a guest customisation profile – customisation scripts need to be added to each VM in a vApp, either as part of a template specification, or after it’s been deployed. What I needed was a way of changing the value of the “Customization script” property in each VM in a vApp, but there appeared at first to be no support for this via the default vCloud PowerCLI cmdlets.

As luck would have it though, VMware have provided us with a way to directly access the vCloud API via the ExtensionData property of the VM object; Read more

This guide is useful if you have created a linux VApp from a public catalog, but have no idea what the login details are.

1. Press ESC when the GRUB bootloader list loads (hold down shift if it doesn’t show up).
2. Press “e” to enter edit mode.
3. Highlight the line that starts with “kernel” and press the e key again.
4. Append the following to the end of the line: rw init=/bin/bash
5. Press Enter and then press b.
6. You should now be in a bash environment logged in as root.
7. Type in “passwd” to reset your password.
8. Reboot the system and log in!

In many automated builds that I’ve worked on screenshots are taken when a build fails. These screenshots are then accessible via the CI server. This is often too little too late, by the time the screenshot is taken the test has usually moved on. A screenshot lacks the context that caused the error in the first place.

To collect information, developers often request remote access to the virtual machines so that they can watch the test as it happens. Experience has taught me that the build environments should only be accessed by the CI server and whoever set up the environment in the first place, I don’t like the idea of developers getting their hands on the build environments. People tend to leave a mess when it’s not their responsibility to keep the environments clean. This can cause unstable builds, if a particular build machine has a different configuration from the rest due to unchecked meddling.

My solution is to record a video of the tests from start to finish, so that the developers can peruse the results without interfering with the machine that the tests run on. I have made this possible via the maven failsafe plugin and VLC 2.0.3 portable.

Read more

In GNU/Linux or OSX, you’d simply use the killall command to kill a process by its name, unfortunately the core Solaris utilities are about 10 years behind the competition in terms of functionality.

The solution is to use this script.

ps -ef gets the list of currently running processes

grep <process name> filters the list to only include entries that includes the process name

awk ‘{print $2}’ prints out the 2nd column of every entry in the list

xargs kill -9 takes all the items in the list to use as an argument and kills each process ID that it reads