MAAS 3.0 released

by Bill Wear on 6 July 2021

We are happy to announce the release of MAAS 3.0. This release provides some new features and bug fixes. Here’s the tl;dr summary:

• PCI and USB devices are now modelled in MAAS
• PCI and USB device tabs are now available in machine details
• IBM Z DPM partitions are supported for MAAS and virtual machines
• Proxmox is now supported
• LXD projects are now supported
• Workload annotations have been added for run-time machine tagging
• You can now register a machine as a VM host during deployment
• You can now disable boot methods
• There’s a detailed set of instructions for filing bugs, now
• Some fixes and improvements were made to the MAAS CLI help, the status bar, and the presentation of logs and events
• RSD pod support has been removed

Let’s take a close look at some of these changes, in no particular order.

API changes

With the advent of MAAS 3.0, we are removing support for RSD pods. Registered pods and their machines will be removed by MAAS upon upgrading to MAAS 3.0. Since we support semantic versioning for MAAS, this change prompted us to move to MAAS 3.0 (rather than issuing a 2.10 release, e.g.).

Consolidation of logs and events

The logs and events tabs have combined and now live under “Logs”. In addition to a number of small improvements, navigating and displaying events has been made easier.

Downloading logs

A helpful new feature is the ability to download the machine and installation output. If a machine has failed deployment, you can now download a full tar of the curtain logs.

This change should make it easier to report bugs, as well, using the new bug reporting process defined during the 3.0 development cycle.

New bug reporting instructions

MAAS bugs are still reported via Launchpad, as always. Filing a good bug report, thought, makes all the difference in how quickly we can triage and address your problem. The new how-to guide will walk you through the key steps of filing a usable bug:

• Prepare a concise summary
• Identify your version and build first
• Explain whether you’re using the UI, CLI, or API
• Explain what happens
• Explain how to reproduce your issue
• Take screenshots, if relevant
• Locate and capture logfiles, if at all possible

We encourage you to follow these guidelines, as much as it makes sense, so that we can more quickly address your issues.

Disabling boot methods

Individual boot methods may now be disabled. When a boot method is disabled, MAAS will configure MAAS controlled isc-dhcpd to not respond to the associated boot architecture code. Note that external DHCP servers must be configured manually.

To allow different boot methods to be in different states on separate physical networks — using the same VLAN ID configuration — you must make the changes on the subnet in the UI or API. When using the API, boot methods to be disabled may be specified using the MAAS internal name or boot architecture code in octet or hex form. For example, the following command will disable i386/AMD64 PXE, AMD64 UEFI TFTP, and AMD64 UEFI HTTP:

maas $PROFILE subnet update $SUBNET disabled_boot_architectures="0x00 uefi_amd64_tftp 00:10"

Improvements to MAAS CLI help UX

The MAAS CLI will now give you help in more places, supporting a more exploration-based interaction. Specifically, we now show help for cases where the required arguments are not met.

Say you’re trying to find out how to list the details of a machine in MAAS e.g.

$ PROFILE=foo
$ maas login $PROFILE http://$MY_MAAS:5240/MAAS/ $APIKEY
$ maas $PROFILE
usage: maas $PROFILE [-h] COMMAND ...

Issue commands to the MAAS region controller at http://$MY_MAAS:5240/MAAS/api/2.0/.

optional arguments:
 -h, --help            show this help message and exit

drill down:
 COMMAND
   account             Manage the current logged-in user.
   bcache-cache-set    Manage bcache cache set on a machine.
   bcache-cache-sets   Manage bcache cache sets on a machine.

✂️--cut for brevity--✂️
   machine             Manage an individual machine.
   machines            Manage the collection of all the machines in the MAAS.
   node                Manage an individual Node.
   nodes               Manage the collection of all the nodes in the MAAS.
✂️--cut for brevity--✂️

too few arguments
$ maas $PROFILE node 
usage: maas $PROFILE node [-h] COMMAND ...

Manage an individual Node.

optional arguments:
 -h, --help        show this help message and exit

drill down:
 COMMAND
   details         Get system details
   power-parameters
                   Get power parameters
   read            Read a node
   delete          Delete a node

The Node is identified by its system_id.

too few arguments

$ maas $PROFILE node read
usage: maas $PROFILE node read [--help] [-d] [-k] system_id [data [data ...]]

Read a node

positional arguments:
 system_id
 data

optional arguments:
 --help, -h      Show this help message and exit.
 -d, --debug     Display more information about API responses.
 -k, --insecure  Disable SSL certificate check

Reads a node with the given system_id.

the following arguments are required: system_id, data
$ maas $PROFILE node read $SYSTEM_ID
{
   "system_id": "$SYSTEM_ID",
   "domain": {
       "authoritative": true,
       "ttl": null,
       "is_default": true,
       "id": 0,
       "name": "maas",
       "resource_record_count": 200,
       "resource_uri": "/MAAS/api/2.0/domains/0/"
✂️--cut for brevity--✂️

We can see at each stage help which gives us clues as to what the next step is, finally arriving at a complete CLI command.

Registering a machine as a VM host during deployment

When deploying a machine through the API, it’s now possible to specify:

register_vmhost=True 

to have LXD configured on the machine and registered as a VM host in MAAS, similar to what happens with virsh if “install_kvm=True” is provided.

PCI and USB devices are now modelled in MAAS

MAAS 3.0 models all PCI and USB devices detected during commissioning:

• Existing machines will have to be recommissioned to have PCI and USB devices modelled
• PCI and USB devices are shown in the UI and on the API using the node-devices endpoint
• Node devices may be deleted on the API only

On the API using the allocate operation on the machines endpoint a machine may allocated by a device vendor_id, product_id, vendor_name, product_name, or commissioning_driver.

IBM Z DPM partition support

Partitions hosted on IBM Z14 GA2 (LinuxONE II) and newer in DPM mode are now supported by MAAS 3.0. Note that partitions (LPARs) must be pre-configured, must use qeth based network devices (like Hipersockets or OSA adapters) and must have properly-defined (FCP) storage groups. IBM Z DPM partitions can be added as a chassis, which allows you to add multiple partitions at once

Proxmox support

MAAS 3.0 supports Proxmox as a power driver:

• Only Proxmox VMs are supported
• You may authenticate with Proxmox using a username and password or a username and API token
• If an API token is used, it must be given permission to query, start and stop VMs.
• Proxmox VMs can be added as a chassis; this allows you to add all VMs in Proxmox at once.

Note that proxmox support has also been back-ported to MAAS 2.9

LXD projects support

MAAS 3.0 supports the use of LXD projects:

• LXD VM hosts registered in MAAS are now tied to a specific LXD project which MAAS uses to manage VMs
• MAAS doesn’t create or manage machines for VMs in other projects
• MAAS creates the specified project when the VM host is registered, if it doesn’t exist
• All existing VMs in the specified project are commissioned on registration
• Resource usage is reported at both project and global levels

PCI and USB device tabs in UI machine details

Tables for detected PCI and USB devices have been added to the machine details page for MAAS 3.0:

These tables include a new skeleton loading state while node devices are being fetched:

The user is prompted to commission the machine if no devices are detected

Workload annotations

Workload annotations have been added to the machine summary page in MAAS 3.0. These allow you to apply owner_data to a machine and make it visible while the machine is in allocated or deployed state:

This data is cleared once the machine state changes to something other than “allocated” or “deployed.” The machine list can be filtered by these workload annotations. MAAS will warn you on the release page to remind you that workload annotations will be cleared upon releasing the machine

Fixed status bar

In MAAS 3.0, a fixed status bar has been added to the bottom of the screen, which will always display the MAAS name and version on the left. The right side of the status bar is intended to show contextual data, depending on the UI panel currently displayed. For now, the only data shown is a “last commissioned” timestamp when the user is on a machine details page:

Bug fixes and more

MAAS 3.0 incorporates a large number of bug fixes, along with some additional minor features. See the Release notes for the full list, as well as installation instructions.