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.

This article expands on my answer to Add multiple specific IPs to instance, a question posted to ask.openstack.org.

In order to serve out SSL services from an OpenStack instance, you will generally want one local ip address for each SSL virtual host you support. It is possible to create an instance with multiple fixed addresses, but there are a few complications to watch out for.

Assumptions

This article assumes that the following resources exist:

In the old days (so, like, last year), Neutron supported a single external network per L3 agent. You would run something like this…

$ neutron net-create external --router:external=true

…and neutron would map this to the bridge defined in external_network_bridge in /etc/neutron/l3_agent.ini. If you wanted to support more than a single external network, you would need to run multiple L3 agents, each with a unique value for external_network_bridge.

There is now a better option available.

I’ve just put a video on Youtube that looks at the steps required to set up the external bridge (br-ex) on a single-interface system:

Normally I like to post solutions, but today’s post is about a vexing problem to which I have not been able to find a solution.

This started as a simple attempt to set up external connectivity on an all-in-one Icehouse install deployed on an OpenStack instance. I wanted to add eth0 to br-ex in order to model a typical method for providing external connectivity, but I ran into a very odd problem: the system would boot and work fine for a few seconds, but would then promptly lose network connectivity.

In my previous post I discussed a problem I was having setting a persistent MAC address on an OVS bridge device. It looks like the short answer is, “don’t use ip link set ...” for this purpose.

You can set the bridge MAC address via ovs-vsctl like this:

ovs-vsctl set bridge br-ex other-config:hwaddr=$MACADDR

So I’ve updated my ifconfig-br-ex to look like this:

DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
ONBOOT=yes
OVSBOOTPROTO=dhcp
OVSDHCPINTERFACES=eth0
MACADDR=fa:16:3e:ef:91:ec
OVS_EXTRA="set bridge br-ex other-config:hwaddr=$MACADDR"

The OVS_EXTRA parameter gets passed to the add-br call like this:

I run OpenStack on my laptop, and I’ve been chasing down a pernicious problem with OVS bridge interfaces under both F19 and F20. My OpenStack environment relies on an OVS bridge device named br-ex for external connectivity and for making services available to OpenStack instances, but after rebooting, br-ex was consistently unconfigured, which caused a variety of problems.

This is the network configuration file for br-ex on my system:

DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROT=static
IPADDR=192.168.200.1
NETMASK=255.255.255.0
ONBOOT=yes
NM_CONTROLLED=no
ZONE=openstack

Running ifup br-ex would also fail to configure the interface, but running ifdown br-ex; ifup br-ex would configure things appropriately.

These are my notes on making OpenStack play well with firewalld and NetworkManager.

NetworkManager

By default, NetworkManager attempts to start a DHCP client on every new available interface. Since booting a single instance in OpenStack can result in the creation of several virtual interfaces, this results in a lot of:

May 19 11:58:24 pk115wp-lkellogg NetworkManager[1357]: <info>
  Activation (qvb512640bd-ee) starting connection 'Wired connection 2'

You can disable this behavior by adding the following to /etc/NetworkManager/NetworkManager.conf: