Linux deployment tools: MAAS 3.1 for hot metal

by Bill Wear on 13 December 2021

Back a few months ago, we did a feature poll on our MAAS forum, and the most-requested new feature turned out to be “Recommission/rescan a machine after it has been deployed“. With the release of MAAS 3.1, we’ve added that feature, making MAAS an even better choice for linux deployment tools. Here’s a sample of how it works.

Start with any old machine

In the Developer Advocate‘s lab, we have a stack of NUCs and a bunch of different laptops. For this exercise, we chose a gaming laptop because:

  1. it’s fully loaded: Ryzen 7, 16GB RAM, a couple TB of space, etc., hooked up via Ethernet to a 1GB+ internet connection.
  2. it’s likely to be something a lot of developers would probably have nearby, making it easier to duplicate this experiment in odd moments.

We freshly installed and initialized MAAS 3.1 and LXD, just following the instructions — except that we didn’t disable DHCP/DNS on LXD, and we didn’t enable DHCP on MAAS. This configuration shows that MAAS doesn’t have to have DHCP enabled to manage machines that are already running — especially since it’s likely that a running machine already has a DHCP-assigned IP address, that it got from somewhere else.

Create and verify a LXD container

Using the command below we can deploy Ubuntu Linux:

lxc launch ubuntu:20.04 u1

When the container is running, we can check it with:

A connected, running, independent LXD container

To demonstrate that the workload doesn’t get disturbed, we’ll do this:

A “top” session started just before enlisting this running machine

Capturing the hot metal with the best of linux provisioning tools

Using the “deployed=true” flag, we’ll enlist this machine into MAAS with the following command sequence:

stormrider@cloudburst:~$ maas admin machines create deployed=true hostname=u1 architecture=amd64 mac_addresses=00:16:3e:fc:71:98 power_type=manual 
Success.
Machine-readable output follows:
{
    "pool": {
        "name": "default",
        "description": "Default pool",
        "id": 0,
        "resource_uri": "/MAAS/api/2.0/resourcepool/0/"
    },
    "node_type": 0,
    "cache_sets": [],
    "volume_groups": [],
    "description": "",
    "status_action": null,
    "disable_ipv4": false,
    "other_test_status_name": "Unknown",
    "fqdn": "u1.maas",
    "boot_disk": null,
    "numanode_set": [
        {
            "index": 0,
            "memory": 0,
            "cores": [],
            "hugepages_set": []
....

Part of the (rather long) JSON response is shown to highlight the fact MAAS has accepted the machine as deployed, but currently knows nothing about it. We can confirm this by looking at the machine list:

The LXD container has been enlisted by MAAS as a deployed machine

We can further confirm the lack of commissioning data by zooming in on the newly-enlisted machine:

Note the number of “Unknown” values for the newly-enlisted machine

Did we disturb the machine?

We can check the running “top” command on the newly-enlisted machine to make sure nothing’s been disturbed:

The “top” command is still running, completely oblivious to machine enlistment by MAAS

Indeed, the machine doesn’t even seem to notice that it’s been enlisted by MAAS — at least, not in terms of impact on the workload.

Updating hardware information

Of course, just knowing the machine is connected to MAAS doesn’t do much for us. What we really need is to update the hardware information — but we want to do that without disturbing the workload significantly.

To accomplish this, we’ll log onto the machine with in a different window and download the “maas-run-scripts” to the machine:

Downloading and setting run permissions for the maas-run-scripts

Here, we’ve not only downloaded the scripts, we’ve actually set permissions so the scripts can run. To run the script to gather hardware information, though, we’ll need some authentication information, from MAAS, about the machine. Back on the MAAS host, we’ll run this command:

MAAS authenication information for the newly-enlisted MAAS machine

We’ll create a credentials file called “u1-creds.yaml” that looks like this:

root@u1:~# cat u1-creds.yaml
reporting:
        maas:
                consumer_key: UUy9RkZt5gLcC7db6S
                endpoint: http://192.168.1.107:5240/MAAS/metadata/status/8gf6sb
                token_key: 44mZe589X3kzew4qrr
                token_secret: 5yKB33R99NYpQ2ZZEJrXZQGFjhe4aPQz

Before we run the command to collect hardware information, let’s check our “top” process to make sure it’s still running properly:

The “top” session is still running undisturbed

With these creds in place, we can run the following (just-downloaded) command to update MAAS about this machine’s hardware info:

Using maas-run-scripts to gather hardware info and send it to MAAS

Let’s check on that “top” process one more time:

The load average rose from 0.53 to 0.62 during the scan, which is miniscule

Good. The machine hasn’t been disturbed much, if at all. Now, let’s see if MAAS knows more about this machine:

A perfect result for the ultimate linux deployment tool: MAAS

You can see from this that MAAS has learned, as of MAAS 3.1, to enlist running machines, that is, to deploy hot metal, without disturbing its workload.

MAAS is always evolving and is one of the best linux deployment tools.

Further reading for linux deployment tools: MAAS

Canonical has released an extensive whitepaper for bare metal Kubernetes – going in depth into many of the different aspects involved and heavily featuring the usage of MAAS.

Also, don’t forget to check out our previous blogs about MAAS, for example the 3.1 release blog.

Learn more about MAAS at our Metal As A Service webpage. If you like the nuts and bolts (more puns for the people), you can get into more detail at our About MAAS page, and we’ve also published an ebook.

There are also plenty of great resources about linux deployment tools and MAAS on the new MAAS resources page, and don’t forget to visit our tutorials page.

Related posts

MAAS Outside the Lines

Far from the humdrum of server setups, this is about unusual deployments – Raspberry Pis, loose laptops, cheap NUCs, home appliances, and more. What the heck is stormrider deploying this week? […]

Data Centre AI evolution: combining MAAS and NVIDIA smart NICs

It has been several years since Canonical committed to implementing support for NVIDIA smart NICs in our products. Among them, Canonical’s metal-as-a-service (MAAS) enables the management and control of smart NICs on top of bare-metal servers. NVIDIA BlueField smart NICs are very high data rate network interface cards providing advanced s […]

A call for community

Introduction Open source projects are a testament to the possibilities of collective action. From small libraries to large-scale systems, these projects rely on the volunteer efforts of communities to evolve, improve, and sustain. The principles behind successful open source projects resonate deeply with the divide-and-conquer strategy, a […]