Announcing MAAS 3.1: bare metal cloud gets easier
by Bill Wear on 6 December 2021
We are happy to announce that MAAS 3.1 has been released. Bare metal provisioning just got even easier! MAAS 3.1 brings some of the most frequently-requested features into the product. A lot of this is serendipity — or maybe you could say that it’s about like minds tracking the same problem. Either way, we’re doing our best to provide features that match our users’ needs, as soon as we possibly can.
In any case, the details of these features are a little big for one blog, so we’ll be taking a detailed look at one feature a week over the next seven or eight weeks (not counting the Christmas break). In this introductory blog, we’ll be introducing these requested features and linking you to more information in the product documentation.
Ability to enlist deployed machines
Users can enlist deployed machines, a top feature poll request
MAAS is a great bare metal provisioning system, but what happens when you’ve already provisioned a server, and it’s already running a workload? When adding a machine, MAAS network boots the machine into an ephemeral environment to collect hardware information. This doesn’t work for machines that are already running a workload:
- You might not be able to disrupt the workload in order to network boot it.
- The machine would be marked as Ready, not Deployed, which is incorrect.
With MAAS 3.1, you may specify that the machine is already deployed. It won’t be commissioned, but it will be marked as “Deployed”. In order to gather hardware information, a non-invasive script is provided to run a subset of the commissioning scripts and send the data back to MAAS.
Machine cloning via the UI
Extends machine cloning to the UI, a step toward profile templates
Let’s face it: Bare-metal provisioning can be really boring, at times, especially if you’re using the same storage configuration for machine after machine. MAAS 3.1 provides the ability to quickly clone or copy configuration from one machine to one or more other machines, via the MAAS UI. This provides convenient access to an existing API feature.
Creating a machine profile is a repetitive task. We have observed that many users create multiple machines — with the same configuration — in batches. Some users create a machine profile template and loop them through the API, while others create a script to interface with the CLI. However, there is no easy way to clone configurations in the UI.
MAAS API already has the cloning functionality, but it was never exposed in the UI. Hence, users may not know that this API feature exists. Although the current cloning API feature does not solve all machine profile templating problems, it is a great place for us to start moving in the direction of machine templates.
Static Ubuntu image upload / reuse
Users can upload, deploy and reuse a bootable ubuntu image
MAAS aleady supports deploying custom OS images. Canonical provides both lp:maas-image-builder and gh:canonical/packer-maasto support creating custom images. With 3.1, these custom images can include static Ubuntu images, created with whatever tool you choose, and then easily deployed with MAAS.
Canonical continues to recommend, though, that you customise Ubuntu using cloud-init user_data or Curtin preseed data whenever possible.
Improved image sync performance
After the region downloads images, racks sync them more quickly
Downloading and syncing images is a known delay element in MAAS. While images aren’t small, and do take some time to download, we decided to try to speed up the process as much as possible.
After the region has downloaded new images, the rack controllers are now much quicker at syncing the new images. There is nothing required of our users to experience this improved sync performance, other than upgrading to 3.1.
LXD auth UX improvements
Easier MAAS to LXD certificate management
Not all server provisioning is about bare metal. Many of our users rely on LXD virtual machines to get things done. But VM provisioning with authentication — especially certificates — can be, well, rather convoluted.
MAAS 3.1 provides a smoother experience when connecting an existing LXD server to MAAS, guiding the user through manual steps and providing increased connection security with use of certificates.
Currently, each MAAS region/rack controller has its own certificate. To add a LXD VM host to MAAS, the user needs to either add the certificate for each controller that can reach the LXD server to the trust list in LXD, or use the trust_password (in which case the controller talking to LXD will automatically add its certificate to the trust).
This doesn’t provide a great user experience, as the former process is cumbersome, and the latter is not suggested for production use for security reasons. To improve this, MAAS 3.1 manages per-LXD keys/certificates, and provide a way for users to get the content of certificates, to authorize MAAS in LXD.
Support for LXD clusters
MAAS 3.1 allows you to use LXD clusters with MAAS KVMs
LXD clusters within the context of MAAS are a way of viewing and managing existing VM host clusters and composing VMs within said cluster. MAAS will not create a new cluster, but will discover an existing cluster when you provide the info for adding a single clustered host.
MAAS assumes you have already configured a cluster within the context of LXD. You then need to configure said cluster with a single trust mechaism that MAAS will use to communicate with said cluster. Adding a LXD cluster is similar to adding a single LXD host, in that you provide authentication the same way for a single host within the cluster, and then select a project.
The only difference is this: The name you provide will be used for the cluster instead of the individual host. MAAS will then connect to the provided host and discover the other hosts within the cluster, and rename the initially defined host with the cluster member name configured in LXD.
Installing MAAS 3.1
Via debian packages:
MAAS 3.1 can be installed by adding the `3.1` PPA:
sudo add-apt-repository ppa:maas/3.1
sudo apt update
sudo apt install maas
You can then either install MAAS 3.1 fresh (recommended) with:
sudo apt-get -y install maas
Or, if you prefer to upgrade, you can do so with:
sudo apt upgrade maas
At this point, you may proceed with a normal installation.
MAAS 3.1 can be installed fresh (recommended) with:
sudo snap install maas --channel=3.1/stable maas
At this point, you may proceed with a normal installation.
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 […]
We want to make it possible to deploy MAAS in an existing datacenter, and have it keep track of machines that already have a deployed workload — without disturbing machine or workload. Currently, in order to get a machine into MAAS, with correct hardware information, you have to network boot the machine and let MAAS […]
This blog title should really be, “Why you always, always, always want conflict detection turned on on all the networks MAAS touches,” but that’s really long as a title. But hear me out. As promised, here is another DHCP blog, this time explaining how you can have multiple DHCP servers on the same subnet, serving […]