Due to an unfortunate incident involving sleep mode and an overheated backpack I had the “opportunity” to rebuild my laptop. Since this meant reinstalling OpenStack I used this as an excuse to finally move to the ML2 network plugin for Neutron.

I was attempting to add an external network using the normal incantation:

neutron net-create external -- --router:external=true \
    --provider:network_type=flat \
    --provider:physical_network=physnet1

While this command completed successfully, I was left without any connectivity between br-int and br-ex, despite having in my /etc/neutron/plugins/ml2/ml2_conf.ini:

I was the presenter for this morning’s RDO hangout, where I ran through a simple demonstration of setting up a multinode OpenStack deployment using packstack.

The slides are online here.

Here’s the video (also available on the event page):

This is just here as a reminder for me:

An OVS interface has a variety of attributes associated with it, including an external-id field that can be used to associate resources outside of OpenVSwitch with the interface. You can view this field with the following command:

$ ovs-vsctl --columns=name,external-ids list Interface

Which on my system, with a single virtual instance, looks like this:

# ovs-vsctl --columns=name,external-ids list Interface
.
.
.
name                : "qvo519d7cc4-75"
external_ids        : {attached-mac="fa:16:3e:f7:75:b0", iface-id="519d7cc4-7593-4944-af7b-4056436f2d66", iface-status=active, vm-uuid="0330b084-03db-4d42-a231-2cd6ad89515b"}
.
.
.

Note the information contained here:

I work with several different OpenStack installations. I usually work on the command line, sourcing in an appropriate stackrc with credentials as necessary, but occasionally I want to use the dashboard for something.

For all of the deployments with which I work, the keystone endpoint is on the same host as the dashboard. So rather than trying to remember which dashboard url I want for the environment I’m currently using on the command line, I put together this shell script:

When you boot a virtual instance under OpenStack, your instance has access to certain instance metadata via the Nova metadata service, which is canonically available at http://169.254.169.254/.

In an environment running Neutron, a request from your instance must traverse a number of steps:

• From the instance to a router,
• Through a NAT rule in the router namespace,
• To an instance of the neutron-ns-metadata-proxy,
• To the actual Nova metadata service

When there are problem accessing the metadata, it can be helpful to verify that the metadata service itself is configured correctly and returning meaningful information.

This Wednesday, January 15, at 14:00 UTC (that’s 9AM US/Eastern, or date -d "14:00 UTC" in your local timezone) I will be helping out with the RDO bug triage day. We’ll be trying to validate all the untriaged bugs opened against RDO.

Feel free to drop by on #rdo and help out or ask questions.

I’ve put together a few tools to help gather information about your Neutron and network configuration and visualize it in different ways. All of these tools are available as part of my neutron-diag repository on GitHub.

In this post I’m going to look at a tool that will help you visualize the connectivity of network devices on your system.

mk-network-dot

There are a lot of devices involved in your Neutron network configuration. Information originating in one of your instances has two traverse at least seven network devices before seeing the light of day. Understanding how everything connects is critical if you’re trying to debug problems in your envionment.

Heat is a template-based orchestration mechanism for use with OpenStack. With Heat, you can deploy collections of resources – networks, servers, storage, and more – all from a single, parameterized template.

In this article I will introduce Heat templates and the heat command line client.

Writing templates

Because Heat began life as an analog of AWS CloudFormation, it supports the template formats used by the CloudFormation (CFN) tools. It also supports its own native template format, called HOT (“Heat Orchestration Templates”). In this article I will be using the HOT template syntax, which is fully specified on the OpenStack website.

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.

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: