Shadow of a Dark Queen


I read this book before LCA 2012, but never had a chance to mention it here. It was the first return to Midkemia for me since I read the Krondor’s Sons books. This book is set a lot later, and there is very little reuse of characters between The Riftwar Saga or even Krondor’s Sons. The only real overlap is the presence of Pug briefly. This book over does its “dirty dozen” aspects, with much of the book focusing on the military training of criminals. The rest of the book feels like a rushed military adventure in a far land, and could have done with some more attention. However, the book isn’t terrible, and I thought it was ok overall.

[isbn: 9780006480266;0006480268]


Are you in a LUG? Do you want some promotional materials for LCA 2013?


Canberra was announced as the host for LCA 2013 at the close of LCA 2012. As part of that closing, we handed out postcards and laptop stickers to delegates. However, we deliberately had extra printed on the theory that groups like LUGs, university computer societies and so forth would be interested in having promotional materials for their groups. For those of you not lucky enough to attend the excellent LCA2012, the stickers looked like this:

And the postcards look like this:

All credit for the excellent art should go to the very capable Jenny Cox. So, if you’re interested in having some stuff to hand out at your next LUG or computer society meeting, please drop us a line at Don’t forget to include the name of the group and a mailing address.

Share Returns to Canberra in 2013


I am incredibly pleased to announce that 2013 will be hosted by Canberra, Australia between 28 January 2013 to 2 February 2013. As the director for 2013 I have been blessed with a simply incredible team who has done fantastic work during the bid process, and I am confident that we will pull off a fantastic event. 2013 is Canberra’s centenary year, so I think its appropriate to have a conference with a bit of a party atmosphere. We’re working hard already on making 2013 a conference to remember.

For those who were unable to see the announcement at the conference, you might find the following interesting: is one of the foremost open source conferences in the world, and is considered the most prestigious in the southern hemisphere. Many of the team that brought you 2005 are coming back to help with the 2013 effort, and we’re cognizant of the extremely high standard left by previous conferences, especially the astounding job that Josh’s 2012 team did.

The web site for the conference is already live, and we’ll be keeping it up to date as details are locked in.


Its a good sign that they’re already making fun of me, right?


So, today on IRC…

    16:07 <mikal> So, breakfast catering at the student accommodation... Will there be bacon?
    16:07 <ctudball> mikal: You have my permission to riot if there is no bacon.
    16:07 <mikal> Yay!
    16:07 <mikal> Real coffee?
    16:08 <ctudball> mikal: No.
    16:08 <mikal> !
    16:10 <mikal> I can still add breakfast to my rego, right?
    16:10 <mikal> I'll just fill a sock with $18 worth of bacon each morning
    16:11 <ctudball> mikal: You can!
    16:11 <mikal> Ok, that's official authorization for Operation Bacon Sock
    16:11 <mikal> If anyone complains, I am showing them a lightly edited version of this IRC log

Which somehow became this.


Further adventures with base images in OpenStack


I was bored over the New Years weekend, so I figured I’d have a go at implementing image cache management as discussed previously. I actually have an implementation of about 75% of that blueprint now, but its not ready for prime time yet. The point of this post is more to document some stuff I learnt about VM startup along the way so I don’t forget it later.

So, you want to start a VM on a compute node. Once the scheduler has selected a node to run the VM on, the next step is the compute instance on that machine starting the VM up. First the specified disk image is fetched from your image service (in my case glance), and placed in a temporary location on disk. If the image is already a raw image, it is then renamed to the correct name in the instances/_base directory. If it isn’t a raw image then it is converted to raw format, and that converted file is put in the right place. Optionally, the image can be extended to a specified size as part of this process.

Then, depending on if you have copy on write (COW) images turned on or not, either a COW version of the file is created inside the instances/$instance/ directory, or the file from _base is copied to instances/$instance.

This has a side effect that had me confused for a bunch of time yesterday — the checksums, and even file sizes, stored in glance are not reliable indicators of base image corruption. Most of my confusion was because image files in glance are immutable, so how come they differed from what’s on disk? The other problem was that the images I was using on my development machine were raw images, and checksums did work. It was only when I moved to a slightly more complicated environment that I had enough data to work out what was happening.

We therefore have a problem for that blueprint. We can’t use the checksums from glance as a reliable indicator of if something has gone wrong with the base image. I need to come up with something nicer. What this probably means for the first cut of the code is that checksums will only be verified for raw images which weren’t extended, but I haven’t written that code yet.

So, there we go.