Recently, I’ve been playing around with Fedora Atomic and Kubernetes. I ran into a frustrating problem in which I would attempt to start a service from within a script launched by cloud-init, only to have have systemctl block indefinitely because the service I was attempting to start was dependent on cloud-init finishing first.

It turns out that systemctl has a flag meant exactly for this situation:

   --no-block
       Do not synchronously wait for the requested operation to finish. If
       this is not specified, the job will be verified, enqueued and
       systemctl will wait until it is completed. By passing this
       argument, it is only verified and enqueued.

Replacing systemctl start <service> with systemctl start --no-block <service> has solved that particular problem.

While experimenting with Fedora Atomic, I was looking for an elegant way to automatically deploy Atomic into an OpenStack environment and then automatically schedule some Docker containers on the Atomic host. This post describes my solution.

Like many other cloud-targeted distributions, Fedora Atomic runs cloud-init when the system boots. We can take advantage of this to configure the system at first boot by providing a user-data blob to Nova when we boot the instance. A user-data blob can be as simple as a shell script, and while we could arguably mash everything into a single script it wouldn’t be particularly maintainable or flexible in the face of different pod/service/etc descriptions.

If you want to build a Windows image for use in your OpenStack environment, you can follow the example in the official documentation, or you can grab a Windows 2012r2 evaluation pre-built image from the nice folks at CloudBase.

The CloudBase-provided image is built using a set of scripts and configuration files that CloudBase has made available on GitHub.

The CloudBase repository is an excellent source of information, but I wanted to understand the process myself. This post describes the process I went through to establish an automated process for generating a Windows image suitable for use with OpenStack.

I like Docker, but I’m not a huge fan of using shell scripts for complex system configuration…and Dockerfiles are basically giant shell scripts.

I was curious whether or not it would be possible to use Puppet during the docker build process. As a test case, I used the ssh module included in the openstack-puppet-modules package.

I started with a manifest like this (in puppet/node.pp):

class { 'ssh': }

And a Dockerfile like this:

The current version of Docker has a very limited set of networking options:

• bridge – connect a container to the Docker bridge
• host – run the container in the global network namespace
• container:xxx – connect a container to the network namespace of another container
• none – do not configure any networking

If you need something more than that, you can use a tool like pipework to provision additional network interfaces inside the container, but this leads to a synchronization problem: pipework can only be used after your container is running. This means that when starting your container, you must have logic that will wait until the necessary networking is available before starting your service.

Would you like to run some custom Python code when Nova creates and destroys virtual instances on your compute hosts? This is possible using Nova’s support for hooks, but the existing documentation is somewhat short on examples, so I’ve spent some time trying to get things working.

The demo_nova_hooks repository contains a working example of the techniques discussed in this article.

What’s a hook?

A Nova “hook” is a mechanism that allows you to attach a class of your own design to a particular function or method call in Nova. Your class should define a pre method (that will be called before the method is called) and post function (that will be called after the method is called):

Sometimes you want to quickly share a screenshot with someone. Here’s my favorite mechanism, which assumes you have installed both curl and the ImageMagick suite.

$ import png:- | curl -T- -s chunk.io
http://chunk.io/f/76ea98ea081748e19de4507fde3c2c65  

When you run this command, you cursor will change into crosshairs. Click on a window, and this will grab a png image of that window and send it to chunk.io using curl.

You’ll get back a URL that you can use to share the image with people.

I ran a Google Hangout this morning on Deploying with Heat. You can find the slides for the presentation on line here, and the Heat templates (as well as slide sources) are available on github.

If you have any questions about the presentation, please feel free to ping me on irc (larsks).

I spent some time today learning about Heat autoscaling groups, which are incredibly nifty but a little opaque from the Heat command line, since commands such as heat resource-list don’t recurse into nested stacks. It is possible to introspect these resources (you can pass the physical resource id of a nested stack to heat resource-list, for example)…

…but I really like visualizing things, so I wrote a quick hack called dotstack that will generate dot language output from a Heat stack. You can process this with Graphviz to produce output like this, in which graph nodes are automatically colorized by resource type:

This is a companion to my article on the Docker plugin for Heat.

While writing that article, I encountered a number of bugs in the Docker plugin and elsewhere. I’ve submitted patches for most of the issues I encountered:

Bugs in the Heat plugin

• https://bugs.launchpad.net/heat/+bug/1364017

  docker plugin fails to delete a container resource in CREATE_FAILED state.

• https://bugs.launchpad.net/heat/+bug/1364041

  docker plugin volumes_from parameter should be a list.

• https://bugs.launchpad.net/heat/+bug/1364039

  docker plugin volumes_from parameter results in an error