SUSE Hack Week 15

Back in February the fifteenth SUSE Hack Week took place. As always this was a week of free hacking, to learn, to innovate, to collaborate, and to have a lot of fun. I didn't have the full time, so I worked on a couple of small things and a few projects I maintain. I did want to summarize that, so here you go.

The first project remained unfinished. I wanted to fill out Tim Urban's Life Calendar (you might have seen that on his excellent blog "Wait But Why"), but realized that it's not trivial to map dates to weeks in your life. So I wrote a small tool to calculate that, stopped after I had a failing test and had a rough feeling for how to put the dots on the life calendar.

The second project was something I always wanted to do, implement Conway's Game of Life. I had once started an implementation in 68000 assembler on the Amiga many years ago, but never finished it. Technology has advanced, so I decided to do at as ASCII pixel art. Who needs high resolution? The result turned out to be a bit more generic, as a command line tool to manipulate pixel matrices stored in text files, the Pixelist. While I was at it, I also implemented Langton's Ant and a simulation of diffusion limited aggregation.

GivenFilesystem is a Ruby gem I maintain for writing unit tests dealing with files on disk. It's quite convenient, if you test code, which writes files on disk and you want to have a well-defined environment without side effects for testing this code. There were some open pull requests. I reviewed and merged them and released given_filesystem 0.2.0.

I already wrote about Inqlude, where I used Hack Week to finally publish the new Inqlude web site, which is based on the work Nanduni did during last year's Google Summer of Code. It's a great improvement. I also did some cleanup work, including reviewing the open issues. So we have a nice roadmap now. There is some interesting work to do. People who want to help with that are always welcome.

Trollolo is another side project I work on from time to time. We use it for supporting our Scrum work flows at SUSE in Trello, such as generating burndown charts. I didn't get around to write code, but I consolidated some of the ideas floating around and put them into issues. This also is a nice opportunity, if you want to have some fun with writing a bit of Ruby code for a small project. Issues are up for takers.

Finally I worked a bit on the next iteration of my attempt to make git support multiple authors. This would make life with git in a pair programming situation much nicer. Based on the feedback I got on my first iteration and at the Git Merge conference, I started to work on a version which puts the data into the trailers of the commit messages. This is less intrusive and with a bit of tooling it achieves similar results as the version which worked directly on the commit headers. I have something working, but it needs a rework of the trailer handling code. I'll continue to work on that when I find some more time to do that.

Is my OpenStack ready for Cloud Foundry?

This year's first Cloud Foundry Summit took place in Santa Clara at the end of May. Beyhan Veli from SAP and I gave a presentation about the Cloud Foundry OpenStack Validator, a new tool we developed as one of the results of our collaboration with SAP on the BOSH OpenStack Cloud Provider Interface project.

The validator gives operators of OpenStack systems a simple tool at hand to check if their OpenStack installation is ready to run Cloud Foundry. OpenStack comes with a lot of options and flexibility, and not all configurations are equally suitable to run Cloud Foundry. The requirements are documented and there are instructions how to manually check them, but it requires quite some expert knowledge to get everything right.

The validator is supposed to encapsulate the expert knowledge and instructions. It checks all requirements automatically and gives operators a report with the information if requirements are met or what they need to change. Cloud Foundry makes it simple for developers to deploy their applications. We try to capture the same spirit of simplicity for operators of Cloud Foundry on OpenStack.

We are running a test pipeline for the continuous integration of the BOSH Cloud Provider Interface for OpenStack which is used in Cloud Foundry. This runs on SUSE OpenStack Cloud. It works smoothly now, but while getting there it would have been great to have the validator to have a simple check of the setup without having to go through manual deployment and testing and finding issues with the setup late in the process. We captured some of this experience in code, and it is much easier with the validator now.

The architecture of the validator is quite simple. It uses the same interfaces as BOSH and Cloud Foundry to access the underlying cloud infrastructure, so it closely resembles what is happening in production. Most of this goes through the Cloud Provider Interface. Some lower level checks directly use the OpenStack APIs.

Tests are written in RSpec, which gives a nice concise way to describe and run the checks which are run by the validator. The validator is provided as a standalone tool, which can simply be run on the command line and will print out a report with what checks it has run, if they have succeeded, and what needs to be done if something is missing. In the end it will answer the question, if my OpenStack is ready to run Cloud Foundry, and this hopefully will be a big green yes.

There is ongoing work to improve the validator, to add more checks, and make it more complete in checking the requirements of the full stack, from OpenStack, through the Cloud Provider Interface, to Cloud Foundry. This will be a continuous improvement process with new checks being added as they are found to be relevant when setting up OpenStack based Cloud Foundry installations. To make this easier and also allow to add custom checks, there likely will be some kind of plugin interface to add new checks to the validator.

As it is using the abstract Cloud Provider Interface it might also be interesting to use the validator with other cloud infrastructures, and we need to evaluate how it plays with other approaches of validating cloud infrastructure. The project is open, the code is published as open source, and we are welcoming feedback and discussions about its future direction.

It was the first time I attended a Cloud Foundry Summit, and I really enjoyed the event. It covered a broad range of topics, inspiration, user experience, deep dive into the technical foundation, science fiction, and much more. Good information, great inspiration, and meeting lots of awesome people, it was an excellent event.

The next summit will be in Frankfurt, Germany, in September. I'm looking forward to see you there.

This blog entry was first published on the SUSE blog.