Linux deployment tools: MAAS 3.1 for hot metal

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:

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

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:

We can further confirm the lack of commissioning data by zooming in on 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:

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:

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:

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:

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

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

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

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.