Blog
Tom Haddon

Tom Haddon

9 posts

Engineering Manager

Tom Haddon is a squad lead within Canonical's IS department. He manages a globally distributed team of senior systems administrators rotating between three functions: Projects, Operations and Webops (devops). He has a strong focus on cloud technologies including OpenStack, Juju and MAAS.

Tom Haddon
15 November 2017

Codetree Collect Info

Cloud and server Article

We recently landed a feature in Codetree that I’m pretty excited about. Codetree is a tool for collecting code from various locations and assembling it in a specific directory structure. It can be used in a standalone fashion, but is also tightly integrated with Mojo, which we use to deploy and manage Juju models. To ...

Tom Haddon
6 June 2016

Scaling out ubuntu.com for 16.04 release

Ubuntu Article

On release day for Ubuntu, the amount of traffic to ubuntu.com increases significantly. Comparing the amount of hits the website received on release day for 16.04 in comparison to the same day the previous week, we saw the number of requests grow by 209% over the 24 hour period. Looking at a particular hour around ...

Tom Haddon
12 January 2016

Mojo Updates

Cloud and server Article

It’s been a while since we’ve talked about Mojo, and since then, there have been quite a few changes. I wanted to take the opportunity to highlight some of the recent updates to Mojo and then talk about our plans for future improvements. Mojo what? So what is Mojo anyway? It’s a tool for deploying, ...

Tom Haddon
10 December 2015

Using bcache for performance gains on the Launchpad Database Servers

Cloud and server Article

Launchpad is the code hosting, bug tracking and build system for the Ubuntu distribution itself, and is used by many other software projects, including OpenStack, Inkscape & MySQL. There are two main data stores in Launchpad. The first is the Librarian, which is a 22TB object store using OpenStack’s Swift as its backend. The second ...

Tom Haddon
21 April 2015

Giving developers production access without revealing secrets

Cloud and server Article

It’s a classic trade off in the devops world: On the one hand you want to give developers access to production systems so that they can see how their services are running and help debug problems that only occur in production. On the other hand, these are production services. As such they necessarily have access ...

Tom Haddon
3 February 2015

Mojo: Juju Service Orchestration distilled part 3

Cloud and server Article

This is the third in a series of three articles about Mojo. In the first article we introduced Mojo, and in the second article we took a closer look at specifications and manifests. Today we’re going to walk through an example service deployment so you can see Mojo in action. The only things you’ll need ...

Tom Haddon
20 January 2015

Mojo: Juju Service Orchestration distilled part 2

Cloud and server Article

In the previous post we introduced Mojo. Today we’re going to take a closer look at how it all fits together. mojo run is the most often used command. As a refresher, here’s the diagram explaining how Mojo’s manifest can be used in different environments: Mojo looks for a manifest file that defines the steps ...

Tom Haddon
13 January 2015

Mojo: Juju Service Orchestration distilled

Cloud and server Article

In Canonical’s IS Department we use Juju for service orchestration. It’s a great tool for quickly spinning up complex services, tying them together and scaling them out or in as needed. We use it for everything from the ubuntu.com website itself to click-packages, the system that underpins the Ubuntu phone. We even use it to ...

Tom Haddon
30 October 2014

ScalingStack: 2x performance in Launchpad’s build farm with OpenStack

Cloud and server Article

Launchpad is an open source suite of tools that help people and teams to work together on software projects, and it includes a build service with over 11,000 Personal Package Archives (PPAs). We’ve recently made some major changes to the underlying infrastructure of this system by migrating it to an OpenStack instance that we call ...