In this article, a followup to my previous post regarding long-poll servers and Python, we investigate the code changes that were necessary to make the code work when deployed on OpenShift.

In the previous post, we implemented IO polling to watch for client disconnects at the same time we were waiting for messages on a message bus:

poll = zmq.Poller()
poll.register(subsock, zmq.POLLIN)
poll.register(rfile, zmq.POLLIN)

events = dict(poll.poll())

.
.
.

If you were to try this at home, you would find that everything worked as described…but if you were to deploy the same code to OpenShift, you would find that the problem we were trying to solve (the server holding file descriptors open after a client disconnected) would still exist.

The python-openstackclient project, by Dean Troyer and others, is a new command line tool to replace the existing command line clients (including commands such as nova, keystone, cinder, etc).

This tool solves two problems I’ve encountered in the past:

• Command line options between different command line clients are sometimes inconsistent.

• The output from the legacy command line tools is not designed to be machine parse-able (and yet people do it anyway).

The new openstack CLI framework is implement using the cliff module for Python, which will help enforce a consistent interface to the various subcommands (because common options can be shared, and just having everything in the same codebase will help tremendously). Cliff also provides flexible table formatters. It includes a number of useful formatters out of the box, and can be extended via setuptools entry points.

I recently added some scripts to automatically generate tag feeds for my blog when pushing new content. I’m using GitHub Pages to publish everything, so it seemed easiest to make tag generation part of a pre-push hook (new in Git 1.8.2). This hook is run automatically as part of the git push operation, so it’s the perfect place to insert generated content that must be kept in sync with posts on the blog.

I’ve enabled blog comments using Disqus. This is something of an experiment, since (a) I’m not really happy with how Disqus is handling user registration these days and (b) I don’t know that I have the time to moderate anything. But we’ll see.

Interacting with JSON-based APIs from the command line can be difficult, and OpenStack is filled with REST APIs that consume or produce JSON. I’ve just put pair of tools for generating and filtering JSON on the command line, called collectively json-tools.

Both make use of the Python dpath module to populate or filter JSON objects.

The jsong command generates JSON on stdout. You provide /-delimited paths on the command line to represent the JSON structure. For example, if you run:

I originally posted this article on the RDO website.

The players

This document describes the architecture that results from a particular OpenStack configuration, specifically:

• Quantum networking using GRE tunnels;
• A dedicated network controller;
• A single instance running on a compute host

Much of the document will be relevant to other configurations, but details will vary based on your choice of layer 2 connectivity, number of running instances, and so forth.

The examples in this document were generated on a system with Quantum networking but will generally match what you see under Neutron as well, if you replace quantum by neutron in names. The OVS flow rules under Neutron are somewhat more complex and I will cover those in another post.

This blog has been hosted on scriptogram for the past year or so. Unfortunately, while I like the publish-via-Dropbox mechanism, there have been enough problems recently that I’ve finally switched over to using GitHub Pages for hosting. I’ve been thinking about doing this for a while, but the things that finally pushed me to make the change were:

• Sync problems that would prevent new posts from appearing (and that at least once caused posts to disappear).
• Lack of any response to bug reports by the site maintainers.

A benefit of the publish-via-Dropbox mechanism is, of course, that I already had all the data and didn’t need to go through any sort of export process.

I’ve been working with OpenStack a lot recently, and I’ve ended up with a small collection of utilities that make my life easier. On the odd chance that they’ll make your life easier, too, I thought I’d hilight them here.

Crux

Crux is a tool for provisioning tenants, users, and roles in keystone. Instead of a sequence of keystone command, you can provision new tenants, users, and roles with a single comand.

The documentation for configuring Neutron recommends that a network controller has three physical interfaces:

Before you start, set up a machine to be a dedicated network node. Dedicated network nodes should have the following NICs: the management NIC (called MGMT_INTERFACE), the data NIC (called DATA_INTERFACE), and the external NIC (called EXTERNAL_INTERFACE).

People occasionally ask, “why three interfaces? What if I only have two?”, so I wanted to provide an extended answer that might help people understand what the interfaces are for and what trade-offs are involved in using fewer interfaces.

Have you ever wished that you could use libvirt domain names as hostnames? So that you could do something like this:

$ virt-install -n anewhost ...
$ ssh clouduser@anewhost

Since this is something that would certainly make my life convenient, I put together a small script called virt-hosts that makes this possible. You can find virt-hosts in my virt-utils GitHub repository:

• https://raw.github.com/larsks/virt-utils/master/virt-hosts

Run by itself, with no options, virt-hosts will scan through your running domains for interfaces on the libvirt default network, look up those MAC addresses up in the corresponding default.leases file, and then generate a hosts file on stdout like this: