Learning Lessons

I’ve learned one of the most valuables lesson of my internship this week, and it’s definitely the most counter-intuitive one so far. It was also the most vexing.

The most annoying lessons that we learn in our life are never new pieces of knowledge, gifted to us by beautiful books or articulate articles. Nor are they the cascading of connections and clicks as assorted bits of information leap together and join up. No, these lessons are ones which take a long time to learn and make us feel very embarrassed for a good while afterwards. They are not the creation of new knowledge, instead they are the destruction of misconceptions. This week my misconception was the necessity of updates.

It doesn’t exist. Updates are a swindle and a lie. If a system is working, don’t change it. Don’t, for example, command all your nodes to update their most vital piece of software when there is absolutely no need for it. I really recommend that if you think that your machines do need some shiny new software, please find a good reason for updating it, and then make sure you test it. Please note that neither shiny or new are good reasons for updating software.

I updated docker to 1:1.7.0-1. This docker version doesn’t allow you to run containers on arm architectures. It’s a pretty big set back. After I realised that the guys at Arch Linux don’t archive previous software versions, and then taking a few moments to deal with this, I spent a decent portion of Monday becoming familiar with the PKGBUILD process and achieving a working docker v1.6.

A fixed docker 1.7.1 was released the day after.

The rest of this week ended up being devoted to creating the first (a scoop! The first!) ARM docker Hadoop image and dockerfile, after I first picked up some knowledge on hadoop, and spent Wednesday at Jeremy’s memory management conference. There were lots of very smart people there, but I missed some of the more interesting talks I’d hoped to make. The speakers will hopefully upload their notes soon enough though. I’ve sometimes noticed that Lecturer’s seem to be disappointed by the depth they have to limit themselves to when teaching, but that upper limit didn’t exist here. I imagine that as a researcher it can sometimes feel like there are very few people who understand or appreciate what you are doing, and the gathering of like minds must be a breath of fresh air.

I’m not sure I’ll have such a luxury when I hope to present the Pi 2 cloud at Glasgow’s Explorathon in September. Nothing has been confirmed yet, but we hope to have a stand there.

I’ll leave you now with this preview of next week’s blog post.

A tale of two towers

Behold! Our new testing tower for the Pi Cloud:

I’ve moved the Pis back to a lego rack of my own design. This was sadly necessary, as while Posco‘s 3d printed design looks great, and allows for much more airflow, its compact nature made hot swapping the Pis fiddly. The Lego design also allows easy access to a Pi’s HDMI port, making network trouble shooting just that little bit quicker. I’m sure I used to perform function over form when it came to Lego construction. I would ask myself, “does this spaceship have enough lasers?” The answer was usually no. However, I found the colour mixing on the right tower extremely vexing, and a shopping trip to a Lego shop might be in order. All very professional of course.

Building this Lego tower got me thinking about other designs, and now that the Pi 2 Cloud has its first show booked here at Glasgow University’s SOCS intern-fest, perhaps it’s time to start planning a remodel with something flashier. It’s also worth noting that we’re hoping to take the Pi 2 Cloud on a tour, so if you’ve any expos or shows coming up then please get in touch with us. In general I think we made good progress this week, but I this may only be in comparison to last week.

Kubernetes turned out to be something of a rabbit hole, as I’m not sure anyone has managed to follow the docker multi-node set up through on a Raspberry Pi 2 yet. We’re waiting for Google to get back to us with some help on this, but in the mean time falling back to Saltstack isn’t an awful compromise. I also had some difficulty with the Linux dd utility, which would work, but not quite, creating the correct partition tables on a blank SD card, filling them with the correct files, yet doing it in such a way that prevented booting. I worked around this by copying and pasting working boot files, but am no closer to figuring out what went wrong. Something somewhere corrupted, and as interested as I am in investigating this, I’m starting to gain a greater appreciation for what’s worth my time and what’s not (a dd operation taking 2 hours is not. Always remember to set block size!). Still, we have 14 Raspberry Pis in our cloud now, and next week I’m deploying a very cool distributed chess application to them and doing some benchmarking. I just hope numbering the Pis from 0 to 13 doesn’t prove unlucky!

Names and their meanings

“A rose by any other name would smell as sweet”. This is said by Juliet in Shakespeare’s most famous play, and she is perhaps half right. A rose does not smell like a rose only because it is called a rose. However, if a flower is named as a rose it is expected to behave like a rose, and smell as sweet. When an object is named we bestow upon it certain ideas and expectations, and this is all the more true for things which have been recently named. In this blog post I’ll be investigating why the components of our stack have the names they do.

Raspberry Pi

The reasoning of the naming of the Pi wasn’t very hard to dig up. It seems the dev team were nostalgic about old Home Micro PCs, and indeed wanted to build a successor to these, envisioning a platform which “like those old home computers, could boot into a programming environment”. A lot of these Home Micros had fruit based names, like Apricot, Tangerine and even Apple. The Raspberry part of this name seats the device comfortably into the computing tradition. The Pi part is perhaps less inspired, it comes from the simple fact that Python was the main language that people are expected to use and to learn on the Raspberry Pi. It’s a good name overall though, and makes clear where the Raspberry Pi comes from, and where it’s going.

Docker

To the best of my knowledge, this name comes from extending the metaphor of containers. In a particular “intro to docker” video I once watched, the speaker described the gap which docker fills with a shipping container metaphor. The speaker argues that before shipping containers were made, transporting goods was hard, as there was no standard around which shipping infrastructure could be built. In this context, the goods to be shipped is software, and the shipping containers become Linux Containers. Docker, like a dock, allows locals to easily deal with foreign products, by packaging these foreign products (or code) into a container where it is much easier to deal with.

Kubernetes

Originally a greek word, Kubernetes means ship’s helmsman, the last actor in navigating a ship. This is an interesting name as Plato used a ship of state in the republic, as a metaphor for the governance of a city-state. This classical allusion would make a software company any smaller seem pompous, but as it’s google we’ll have to let it slide. The name Kubernetes reflects the nature of the software as an orchestration tool, although it is much longer and rarer a name than is often encountered in software.

Saltstack

It seems that Salt is so named as an extension of it’s design philosophy, of being highly modular and extremely lightweight. Saltstack continues this theme with grains and pillars, and although it would be very interesting if Saltstack was in some way named for the biblical story of Lot’s wife turning into a pillar of salt, I think it is unlikely.

 

I can’t leave you without a progress update, so here is a picture of a 3d printed tower we’re testing for our friend Posco at the University of Liverpool