launchpadblog

Recently the Launchpad Red Squad and Product Team started working on a new cloud project. As part of that project we’ll be using Juju, a tool that helps you easily deploy services on the cloud.

As an opportunity to learn more about how Juju works, I wrote a charm to deploy oops-tools, an open source Django application that helps visualize and aggregate error reports from Launchpad, on Amazon’s EC2 and Canonical’s private Openstack cloud.

You might be asking, what’s a charm? Charms are basically instructions on how to deploy services, that can be shared and re-used.

Assuming you already have a bootstrapped juju environment, deploying oops-tools using this charm is as easy as:

$ juju deploy --repository=. local:oops-tools
$ juju deploy --repository=. local:postgresql
$ juju add-relation postgresql:db oops-tools
$ juju expose oops-tools


That’s it! With just a few commands, I have an instance of oops-tools up and running in a few minutes.

Under the hood, the oops-tools charm:

• starts two Ubuntu instances in the chosen cloud provider, one for the webserver and another for the database server
• downloads the latest trunk version of oops-tools and its dependencies from Launchpad
• configures oops-tools to run under Apache’s mod_wsgi
• configures oops-tools to use the database server

There’s still work to do, like add support for RabbitMQ (oops-tools uses rabbit to provide real-time error reports), but this initial iteration proved useful to learn about Juju and how to write a charm. As it is, it can be used by developers who want to hack on oops-tools and can be easily changed to deploy oops-tools in a production environment.

If you’d like to give it a try, you can get the charm here: https://code.launchpad.net/~charmers/charms/oneiric/oops-tools/trunk

Enjoy!

Recently, Ursula and I have been improving the way that we test new Launchpad features.

Already, Launchpad has an extensive test suite but there are some things that automated tests can’t look out for. Rather than just testing the quality of our code, we also want to test the quality of the experience.

To do that, we’ve been doing more exploratory testing. Now, when a feature is getting close to deployment we will try out every part of the feature and make notes of anything in the experience that needs to be fixed before we release it. In particular, we’re interested in the feature’s:

• ease of use and discoverability
• completeness
• quality of implementation
• suitability to the problem it is solving
• conformity to Launchpad’s principles and UI guidelines.

We’re also aiming to timebox the testing; something that takes too long to explore is likely too complex. For now, we’re using a 25 minute limit, as borrowed from The Pomodoro Technique, as it seems like a good starting point.

If you’re interested in what we’re doing, you can follow our progress both on the launchpad-dev mailing list and on the Launchpad dev wiki. Also, I’m hoping that we can get your help in testing beta features. I’ll write more about that soon.

We previously announced a maintenance window for the Launchpad 2.2.3 release
for one hour.

Due to some issues found during our pre-release quality assurance, we need to increase the maintenance window to three hours.

The new maintenance window is:

Going offline: 22.00 UTC 1st April
Expected back: 01.00 UTC 2nd April

We know downtime really sucks. But while you wait just imagine all the fantastic stuff that you will get with our best release ever, version 2.2.3!

Hang in there while we make the final adjustments in delivering it to you.