These notes and scripts help automate some of the steps in Dimiter’s most excellent blog posts that describe how to set up a lab environment to deploy OpenStack using Juju.

This includes my notes for creating a pet MAAS controller that runs on a dedicated Intel NUC5.

Here also is a utility to generate the commands to configure the physical network and storage on the MAAS-provisioned machines before deployment (post-commissioning).

To run the utilities, you’ll need to install boot.

See Dimiter’s blog post, part 2 for discussion of the hardware required, but briefly:

To run the utilities in this repository, you’ll need to install boot on the laptop.

The MAAS controller is an Intel NUC5 with 8G RAM, 250GB disk. It runs Ubuntu 16.04, with LXD installed.

It is on all the time, and runs maas in an LXD container. I also use it to run network infrastructure services like NTP, DNS, and radvd.

The utility generates commands to rename the interfaces to avoid this problem.

If you don’t rename the ethernet interface to have short names, they will fail to come up if the name is longer than 15 characters. Under MAAS, the symptom is that the machine will fail to deploy when VLAN interfaces are defined on it.

This happens because the USB Ethernet NICs often show up as interfaces with very long names. When you create the VLAN child on it, the VLAN tag appended to the name exceeds the 15-character limit.

If you don’t already have another MAAS, install Ubuntu 16 on the NUC hardware however you like.

I happened to have a MAAS controller handy already, so I used it to install the OS onto the NUC. First I used maas-chain.sh to specify the disk paritions I wanted.

Set the new maas NUC to boot from its local disk.

If you don’t already have another MAAS, you can try the script maas-lxd to prepare the NUC for running the MAAS container.

Then follow the instructions at Installing MAAS in LXC instructions.

If that other MAAS controller happens to be an LXD container, you can copy it to the new NUC. I had a MAAS container already on my laptop.

On NUC:

apt install criu
lxc config set core.https_address [::]:8443
lxc config set core.trust_password secret

On laptop:

apt install criu
lxc remote add nuc https://nuc:8443/
lxc profile copy maas nuc:maas

For some reason, I’ve had lxc commands fail when using the implicit local address, so I add the server’s own address as a “remote”. lxc remote add here https://laptop:8443/

Then export the image to nuc:

lxc publish here:maas nuc: --force --alias maas

On nuc, make sure the br-admin bridge is present, because the profile refers to it.

Launch the new image.

lxc launch maas maas -p maas

That brought up a container ok, but the admin interface, while present, didn’t have an IP address. I did ifup admin and then it had IPv4 but not 6.

maas-regiond was running, but maas-rackd wasn’t. I had to start it.

ifup admin
systemctl start maas-rackd

MAAS network architecture changed a lot from 1.9 to 2.0. Dimiter’s blog posts give both the MAAS 1.9 and MAAS 2.0 commands to setup up the VLANs, giving the gateway address, DNS, and reserved IP ranges (both static and dynamic).

A Fabric is a group of VLANs (layer 2).

MAAS sets up a fabric for each physical NIC it finds on the rack controller.

A Space is a group of Subnets (layer 3).

The utility in this repo is what I used to generate MAAS commands. It assumes that you’re following the conventions in Dimiter’s posts.

The utility is very simple-minded. It’s intended to save you some work in looking up the internal maas ids for fabrics, vlans, and interfaces, rather than as a full automation tool.

You invoke it via command-line, and it emits some shell commands that you can run directly or edit if you like. It takes an argument that tells it which “phase” of the installation you need the commands for. Most of the commands are just calls to the MAAS CLI, but some of them copy its JSON output into files so later phases can get them.

It’s usually safe to issue the generated commands even if they’ve already been done before. For instance, if you issue the commands that create objects, you’ll get warnings that the objects already exist, but it won’t hurt anything. (Does that count as idempotency?)

You need to create a file named config-hosts in the top-level of this repo, which contains a map of the hostnames of your payload nodes and an integer that will become the last octet in IP addresses for that node. Don’t include the maas controller or juju controller in this list.

Here’s an example:

{
  "labrat-a" 10
  "labrat-b" 11
  "labrat-c" 12
  "labrat-d" 13
}

boot run -s one