MAAS release notes

Here you will find release notes for:

MAAS 3.4 Beta1 has been released

We are happy to announce that MAAS 3.4 Beta1 has been released, with new features and many bug fixes. MAAS 3.3 is a concerted effort to improve MAAS on multiple fronts, including a large number of bug fixes.

MAAS 3.4 Beta 1 features

The following visible new features are a part of MAAS 3.4 Beta 1:

  • Redesigned UI: Navigation is moved from the top of the screen to the left side, and made more comprehensive, while at the same time being more compact. Navigation within panels is handled by discreet, pop-up boxes to avoid disoriented the user.

  • Configurable session timeout: Users are able to fully configure their session timeouts.

  • Ansible HA PostgreSQL playbook enhancements: PostgreSQL HA setup is now fully possible with Ansible.

  • Ansible observability playbook: Users can now configure O11y with Ansible.

  • Allow sorting images by last deployed: Users can now sort out which images they most recently used.

  • Packer MAAS - SLES: We’ve added support for SLES to our Packer repertoire, and done some touch-ups on RHEL.

How to install MAAS 3.4 Beta1

MAAS will run on just about any modern hardware configuration, even a development laptop. If you’re not sure whether your target server will handle MAAS, you can always double-check.

NOTE Support for PostgreSQL 12 has been discontinued in MAAS 3.4. Postgres 14 does not run on Focal 20.04 LTS.

How to do a fresh snap install of MAAS 3.4 Beta1

To install MAAS 3.4 Beta1 from a snap, simply enter the following:

$ sudo snap install --channel=latest/edge maas

After entering your password, the snap will download and install from the 3.4 Beta channel.

How to upgrade from an earlier snap version to MAAS 3.3

Maybe instead of a fresh install, you want to upgrade from a earlier snap version to the 3.4 Beta1 snap, and you are using a region+rack configuration, use this command:

$ sudo snap refresh --channel=latest/edge maas

After entering your password, the snap will refresh from the 3.4 Beta1 candidate channel. You will not need to re-initialise MAAS.

If you are using a multi-node maas deployment with separate regions and racks, you should first run the upgrade command above for rack nodes, then for region nodes.

How to initialise MAAS 3.4 snap for a test or POC environment

You can initialise MAAS as a compact version for testing. To achieve this, we provide a separate snap, called maas-test-db, which contains a PostgreSQL database for use in testing and evaluating MAAS. The following instructions will help you take advantage of this test configuration.

Once MAAS is installed, you can use the --help flag with maas init to get relevant instructions:

$ sudo maas init --help
usage: maas init [-h] {region+rack,region,rack} . . .

Initialise MAAS in the specified run mode.

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

run modes:
  {region+rack,region,rack}
    region+rack         Both region and rack controllers
    region              Region controller only
    rack                Rack controller only

When installing region or rack+region modes, MAAS needs a
PostgreSQL database to connect to.

If you want to set up PostgreSQL for a non-production deployment on
this machine, and configure it for use with MAAS, you can install
the maas-test-db snap before running 'maas init':
    sudo snap install maas-test-db
    sudo maas init region+rack --database-uri maas-test-db:///

We’ll quickly walk through these instructions to confirm your understanding. First, install the maas-test-db snap:

sudo snap install maas-test-db

Note that this step installs a a running PostgreSQL and a MAAS-ready database instantiation. When it’s done, you can double check with a built-in PostgreSQL shell:

$ sudo maas-test-db.psql
psql (12.4)
Type "help" for help.

postgres=# \l

This will produce a list of databases, one of which will be maasdb, owned by maas. Note that this database is still empty because MAAS is not yet initialised and, hence, is not yet using the database. Once this is done, you can run the maas init command:

sudo maas init region+rack --database-uri maas-test-db:///

After running for a moment, the command will prompt you for a MAAS URL; typically, you can use the default:

MAAS URL [default=http://10.45.222.159:5240/MAAS]:

When you’ve entered a suitable URL, or accepted the default, the following prompt will appear:

MAAS has been set up.

If you want to configure external authentication or use
MAAS with Canonical RBAC, please run

  sudo maas configauth

To create admins when not using external authentication, run

  sudo maas createadmin

Let’s assume you just want a local testing user named admin:

$ sudo maas createadmin
Username: admin
Password: ******
Again: ******
Email: admin@example.com
Import SSH keys [] (lp:user-id or gh:user-id): gh:yourusername

At this point, MAAS is basically set up and running. You can confirm this with sudo maas status. If you need an API key, you can obtain this with sudo maas apikey --username yourusername. Now you will be able to test and evaluate MAAS by going to the URL you entered or accepted above and entering your admin username and password.

Initialise MAAS for a production configuration

To install MAAS in a production configuration, you need to setup PostgreSQL, as described below.

Setting up PostgreSQL from scratch

To set up PostgreSQL, even if it’s running on a different machine, you can use the following procedure:

  1. You will need to install PostgreSQL on the machine where you want to keep the database. This can be the same machine as the MAAS region/rack controllers or a totally separate machine. If PostgreSQL (version 14) is already running on your target machine, you can skip this step. To install PostgreSQL, run these commands:

     sudo apt update
 sudo apt install -y postgresql

  2. You want to make sure you have a suitable PostgreSQL user, which can be accomplished with the following command, where $MAAS_DBUSER is your desired database username, and $MAAS_DBPASS is the intended password for that username. Note that if you’re executing this step in a LXD container (as root, which is the default), you may get a minor error, but the operation will still complete correctly.

     sudo -u postgres psql -c "CREATE USER \"$MAAS_DBUSER\" WITH ENCRYPTED PASSWORD '$MAAS_DBPASS'"

  3. Create the MAAS database with the following command, where $MAAS_DBNAME is your desired name for the MAAS database (typically known as maas). Again, if you’re executing this step in a LXD container as root, you can ignore the minor error that results.

     sudo -u postgres createdb -O "$MAAS_DBUSER" "$MAAS_DBNAME"

  4. Edit /etc/postgresql/14/main/pg_hba.conf and add a line for the newly created database, replacing the variables with actual names. You can limit access to a specific network by using a different CIDR than 0/0.

     host    $MAAS_DBNAME    $MAAS_DBUSER    0/0     md5

  5. You can then initialise MAAS via the following command:

     sudo maas init region+rack --database-uri "postgres://$MAAS_DBUSER:$MAAS_DBPASS@$HOSTNAME/$MAAS_DBNAME"

You should use localhost for $HOSTNAME if you’re running PostgreSQL on the same box as MAAS.

Don’t worry; if you leave out any of the database parameters, you’ll be prompted for those details.

How to do a fresh install of MAAS 3.3 from packages

MAAS 3.3 from packages runs on 22.04 LTS only. The recommended way to set up an initial MAAS environment is to put everything on one machine:

sudo add-apt-repository ppa:maas/3.4-next
sudo apt update
sudo apt-get -y install maas

Executing this command leads you to a list of dependent packages to be installed, and a summary prompt that lets you choose whether to continue with the install. Choosing “Y” proceeds with a standard apt package install.

Distributed environment

For a more distributed environment, you can place the region controller on one machine:

sudo apt install maas-region-controller

and the rack controller on another:

sudo apt install maas-rack-controller
sudo maas-rack register

These two steps will lead you through two similar apt install sequences.

MAAS 3.4 Beta1 bug list

1999160↗: Region controller fails to run commissioning scripts in proxied environment
1999191↗: bad interaction between Colorama and the CLI
1999557↗: MAAS fails to startup when installed from deb package and vault is enabled
2002109↗: Migration of BMC power credentials fails with manual driver
2002111↗: Connection to local Vault fails if proxy is configured
2003888↗: Grouped machine list view: Inconsistent display when machine state changes
1743648↗: Image import fails
1811799↗: Normal users can read machine details of owned machines
1812377↗: An admin is allowed to create raids for an Allocated node in the UI, but not the API
1958451↗: power_driver parameter is not preserved
1990172↗: “20-maas-03-machine-resources” commissioning script improperly reports a Pass when the test fails
1995084↗: MAAS TLS sets HSTS forcibly and with too short value
1999147↗: [3.3.0-candidate] failure when arch is requested as a filter
1999368↗: [3.3.0 RC] wrong DNS records
1999579↗: MAAS OpenAPI docs are not available in air-gapped mode
2001546↗: Server reboot will make subnet entries disappear from zone.maas-internal
2003310↗: Refresh scripts are not re-run if they pass, but fail to report the results to the region
2003940↗: MAAS 3.3 RC shows incorrect storage amount
2008275↗: Intel AMT support is broken in MAAS 3.3.0
2009137↗: MAAS OpenApi Schema missing parameters
2009186↗: CLI results in connection timed out when behind haproxy and 5240 is blocked
2009805↗: machine deploy install_kvm=True fails
2011274↗: MAAS 3.4: Deployment fails on LXD VMs
2011822↗: Reverse DNS resolution fails for some machines
2012139↗: maas commands occasionally fail with NO_CERTIFICATE_OR_CRL_FOUND when TLS is enabled
2017504↗: Cannot deploy from the cli when “Allow DNS resolution” is set on minimal subnet
1696108↗: Interface model validates the MAC address twice
1773150↗: smartctl verify fails due to Unicode in Disk Vendor Name
1773671↗: MAC address column should use mono font
1959648↗: Websocket vlan handler should include associated subnet ids
1979403↗: commission failed with MAAS 3.1 when BMC has multiple channels but the first channel is disabled
1986590↗: maas-cli from PPA errors out with traceback - ModuleNotFoundError: No module named ‘provisioningserver’
1990416↗: MAAS reports invalid command to run when maas-url is incorrect
1993618↗: Web UI redirection policy can invalidate HAProxy and/or TLS setup
1994945↗: Failure to create ephemeral VM when no architectures are found on the VM host
1996997↗: LXD resources fails on a Raspberry Pi with no Ethernet
1999064↗: maas_run_scripts.py does not clean up temporary directory
2002550↗: Controller type displays as “Undefined”
2007297↗: LXD REST API connection goes via proxy
2009045↗: WebSocket API to report reasons for failure for machine bulk actions
2009140↗: MAAS OpenApi Schema cutoff variable names
2012054↗: RPC logging when debug is too verbose

Release notes for other MAAS versions

Here are release notes for other relatively recent MAAS versions:

Last updated 16 days ago.

Help improve this document in the forum.