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

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

DockerInc::Docker::Container

Properties

• cmd : List

  Command to run after spawning the container.

  Optional property.

  Example:

    cmd: [ 'thttpd', '-C', '/etc/thttpd.conf', '-D', '-c', '*.cgi']
  

• dns : List

  Set custom DNS servers.

  Example:

    dns:
      - 8.8.8.8
      - 8.8.4.4
  

• docker_endopint : String

  Docker daemon endpoint. By default the local Docker daemon will be used.

  Example:

    docker_endpoint: tcp://192.168.1.100:2375
  

• env : String

I have been looking at both Docker and OpenStack recently. In my last post I talked a little about the Docker driver for Nova; in this post I’ll be taking an in-depth look at the Docker plugin for Heat, which has been available since the Icehouse release but is surprisingly under-documented.

The release announcement on the Docker blog includes an example Heat template, but it is unfortunately grossly inaccurate and has led many people astray. In particular:

This post accompanies my article on the Docker plugin for Heat.

In order for WaitCondition resources to operate correctly in Heat, you will need to make sure that that you have:

• Created the necessary Heat domain and administrative user in Keystone,
• Configured appropriate values in heat.conf for stack_user_domain, stack_domain_admin, and stack_domain_admin_password.
• Configured an appropriate value in heat.conf for heat_waitcondition_server_url. On a single-system install this will often be pointed by default at 127.0.0.1, which, hopefully for obvious reasons, won’t be of any use to your Nova servers.
• Enabled the heat-api-cfn service,
• Configured your firewall to permit access to the CFN service (which runs on port 8000).

Steve Hardy has a blog post on stack domain users that goes into detail on configuring authentication for Heat and Keystone.

I’ve been playing with Docker a bit recently, and decided to take a look at the nova-docker driver for OpenStack.

The nova-docker driver lets Nova, the OpenStack Compute service, spawn Docker containers instead of hypervisor-based servers. For certain workloads, this leads to better resource utilization than you would get with a hypervisor-based solution, while at the same time givin you better support for multi-tenancy and flexible networking than you get with Docker by itself.

Until recently I had a bcache based setup on my laptop, but when forced by circumstance to reinstall everything I spent some time looking for alternatives that were less disruptive to configure on an existing system.

I came across Richard Jones’ article discussing the recent work to integrate dm-cache into LVM. Unlike bcache and unlike using dm-cache directly, the integration with LVM makes it easy to associate devices with an existing logical volume.

I have put together a small tool called lvcache that simplies the process of:

Update (2018-03-22) Since I wrote this document back in 2014, Docker has developed the macvlan network driver. That gives you a supported mechanism for direct connectivity to a local layer 2 network. I’ve written an article about working with the macvlan driver.

This article discusses four ways to make a Docker container appear on a local network. These are not suggested as practical solutions, but are meant to illustrate some of the underlying network technology available in Linux.

For a small project I’m working on I needed to attach a few buttons to a Raspberry Pi and have some code execute in response to the button presses.

Normally I would reach for Python for a simple project like this, but constraints of the project made it necessary to implement something in C with minimal dependencies. I didn’t want to write something that was tied closely to my project…

…so I ended up writing gpio-watch, a simple tool for connecting shell scripts (or any other executable) to GPIO events. There are a few ways to interact with GPIO on the Raspberry Pi. For the fastest possible performance, you will need to interact directly with the underlying hardware using, e.g., something like direct register access. Since I was only responding to button presses I opted to take advantage of the GPIO sysfs interface, which exposes the GPIO pins via the filesystem.

After a recent upgrade of my Fedora 20 system to kernel 3.15.mumble, I started running into a problem (BZ 1121345) with my Docker containers. Operations such as su or runuser would fail with the singularly unhelpful System error message:

$ docker run -ti fedora /bin/bash
bash-4.2# su -c 'uptime'
su: System error

Hooking up something (like, say, socat unix-listen:/dev/log -) to /dev/log revealed that the system was logging:

Jul 19 14:31:18 su: PAM audit_log_acct_message() failed: Operation not permitted

Downgrading the kernel to 3.14 immediately resolved the problem, suggesting that this was at least partly a kernel issue. This seemed like a great opportunity to play with the git bisect command, which uses a binary search to find which commit introduced a particular problem.