Open Cloud Adventures: MAAS Nodes

Once we’ve installed MAAS as a Cloud Provider, its time to give it nodes to manage so that it can provide them to a Cloud Deployer in the future. Join us as we learn to Enlist and Commision MAAS Nodes.

Published in

Linnovate

5 min readOct 2, 2017

This is the third part of our Open Cloud Adventures Series. You can view the previous part ‘Open Cloud Adventures: Getting MAAS’ to learn how to install and configure the MAAS Cloud Provider.

MAAS Components

Before we begin, it is worth gaining a basic understanding of how MAAS works.

To quote our previous article: ‘Open Cloud Adventures: Getting MAAS’

…MAAS is comprised of two essential components: MAAS region controller and MAAS rack controller.
Some of the main jobs of a MAAS region controller are to provide DNS and to serve the web interface of MAAS to users and the web API of MAAS to Cloud Deployers such as Juju.
MAAS rack controllers … are responsible for detecting new nodes … within a Layer 2 network … and providing … images … through the commissioning process.

Based on this, we know that:

The MAAS Region Controller must be able to contact the MAAS Rack controller through Layer 3 in order to provide DNS and other services.
For MAAS to register new nodes, the nodes must be connected to a network that our MAAS Rack Controller has Layer 2 access to.

Since, we have installed our MAAS Rack Controller and our MAAS Region Controller on the same node which is in the same Layer 2 network as our other physical nodes, we are ready to get started.

Enabling PXE Boot

The first thing we need to do to is enable PXE boot on the physical nodes that we want MAAS to recognize. This just means we want our machines to send out a request in the network whenever they start asking: “can anyone in this network give us an ip and some image to boot from”, before attempting to boot normally from a disk.

As you might expect this is done via the BIOS settings. In our case, we had to start up our physical nodes and access the BIOS settings by powering off our machine and then pressing and holding the [ F2 ] key while it booted up.

After we entered Bios, we disabled UEFI booting, since there is no PXE boot (boot from network) option for UEFI on our machine.

Then we changed the boot order for Legacy booting, so that PXE (LAN) boot happens first. The reason we choose this order is so that we always ask the Rack Controller during Network Boot what it wants to do with the machine and if the Rack Controller has nothing scheduled for the machine, then it boots normally from disk.

Lastly, we disabled the “Boot Network Devices Last” Option, and made sure that “Network Boot” was set to “Legacy PXE”

With this, we were ready to have some fun.

Enlisting Nodes

We pushed the power button and let the magic happen:

In this screen we see that when the node first PXE boots it sent out a network request asking everyone on the network if they can provide DHCP/BOOTP. Since our MAAS Rack controller has a reserved DHCP range configured on it, the MAAS server responds to the request, giving the new node an address out of it’s reserved range which will be used during the enlisting process.

In the next step we see that the node is assigned a gateway which is the IP of our MAAS server 10.222.0.1, since that’s how we configured the 10.222.0.0/24 subnet in MAAS.

Our new node then proceeds to PXE boot the image it is provided via TFTP from 10.222.0.1 and during PXE boot contacts the MAAS Region and Rack Controller, both of which are located at 10.222.0.1 in this case.

Earlier, we noticed a strange IP during this process and it turned out that our MAAS was incorrectly configured. So we ran dpkg-reconfigure maas-rack-controller and dpkg-reconfigure maas-region-controller to set the configuration to the right IP.

Once our new node has been successfully enlisted it will appear under the ‘New’ category in our MAAS Region Controller web UI : http://maas/MAAS/#/nodes

Commissioning Nodes

The first thing we did is click on our node name in the list and rename our node’s FQDN so that we could identify it before enlisting the next node:

Then we clicked on our node name and set the Power type, since MAAS was not able to detect it during the enlisting process. In our case we use the ‘Manual’ power type, but we would fill this in differently when using VM (virsh) nodes with automatic power management.

Finally, we chose the “Commision” action from the dropdown menu in the upper right-hand corner.

We confirm the process without checking any additional boxes.

And we’re off!

Now, since we set the “Manual” power type we need to manually turn our machine on so that it can boot once again from the network and begin the commissioning process. If we had set an automatic power method, we could have skipped this step of turning the machine on.

Once the machine powered on we were able to monitor the commissioning process via the Region Controller UI.

Once Commissioning is complete, the status changes to Ready.

Our node is now available for Juju — our Cloud Deployer — to request when deploying new applications.