What's new in MAAS (2.8)

Docs
1
2.7 2.8 2.9
Snap CLI ~ UI CLI ~ UI CLI ~ UI
Packages CLI ~ UI CLI ~ UI CLI ~ UI

MAAS 2.8 release notes

MAAS 2.8.4 released

MAAS 2.8.4 has been released, replacing the 2.8/stable channel in snap and the ppa:maas/2.8 . You can update your 2.8 release to 2.8.4 with the command:

snap refresh --channel=2.8/stable

or by using the aforementioned PPA. 2.8.4 has a single bug fix - LP:1917372 in it. No other changes have been made to MAAS with this release.

MAAS 2.8.3 released

MAAS 2.8.3 has been released, replacing the 2.8/stable channel in snap and the ppa:maas/2.8. You can update your 2.8 release to 2.8.3 with the command:

snap refresh --channel=2.8/stable

or by using the aforementioned PPA. The focus for this release has been bugfixing and more bugfixing. No other changes have been made to MAAS with this release.

Here’s a summary of the bugs that were fixed in 2.8.3:

    $ sudo -u postgres psql $MAAS_DB -c "UPDATE maasserver_staticipaddress SET alloc_type=5 WHERE ip = '$IP_ADDRESS' AND alloc_type=6;"
    $ maas $PROFILE ipaddresses release ip='$IP_ADDRESS' force=true
  • MAAS is unable to handle duplicate UUIDs: The firmware for Dell servers (and possibly others) has a bug whereby they use the service number for the UUID, which is not guaranteed to be unique. This caused MAAS commissioning to fail. The code was modified in 2.8.3 to detect and remove duplicate UUIDs, allowing MAAS to fall back to the MAC address. There is also a database workaround for those who cannot upgrade to 2.8.3 right away:
     $ sudo -u postgres psql $MAAS_DB -c "UPDATE maasserver_node SET hardware_uuid=NULL where hardware_uuid='$DUPLICATE_UUID'";

Note that there is a workaround for those not ready to upgrade to 2.8.3, specifically, using the CLI to commission machines without testing them:

maas $PROFILE machine commission $SYSTEM_ID testing_scripts=none

MAAS 2.8.2 released

On 1 September 2020, MAAS 2.8.2 was released, replacing the 2.8/stable channel in snap and the ppa:maas/2.8. You can update your 2.8 release to 2.8.2 with the command:

snap refresh --channel=2.8/stable

or by using the aforementioned PPA. The focus for this release has been bugfixing – there were no changes to MAAS since RC1.

Thanks to everyone who reported the issues with previous 2.7 releases and helped us with the logs.

MAAS 2.8 released

Following on from MAAS 2.7, we are happy to announce that MAAS 2.8 is now available. This release features some critical bug fixes, along with some exciting new features.

Six questions you may have:

  1. What are the new features & fixes for 2.8?
  2. What known issues should I be aware of?
  3. How do I install MAAS 2.8 as a snap?
  4. How do I upgrade my MAAS 2.7 snap to a MAAS 2.8 snap?
  5. How do I install MAAS 2.8 from packages?
  6. What bugs were fixed in this release?

LXD-based VM host support (Beta)

MAAS 2.8 adds the beta capability to use LXD-based VM hosts and virtual machines (VMs), in addition to the libvirt-based VM hosts/VMs already available. These new LXD VM hosts use the same underlying technology as libvirt (QEMU). Unlike libvirt KVMs, though, LXD VMs can be managed without requiring SSH access to the VM host. LXD are remotely accessed via secure HTTP transport, which provides better security for LXD-based VMs. In addition, LXD has a better API, and is part of a much larger constellation of enterprise software, offering a wider range of future features and use cases.

UI performance improvements for the machine listing page

Within MAAS 2.8, we have made a number of performance improvements to everything related to the machine listing. Some of the most visible changes involve the way that long lists are presented within categories (see the example below), but there are a number of other changes that make the list easier and more efficient to use.

Among those other changes are persisting UI state for grouping, new grouping options, bookmark-able URLs with filter and search parameters, and many other performance improvements. If you’re interested in more details, see this blog post.

Support for using an external/remote PostgreSQL MAAS database with the snap version of MAAS

In order to make MAAS more scalable, we have separated the MAAS database from the MAAS snap, so that the DB can be situated separately. MAAS 2.8 now allows the MAAS DB to be located outside the snap on localhost, or on a separate, external or remote server. We complement this capability with extensive instructions for setting up and managing this configuration. To support those who are testing MAAS, we’ve also provided a test DB configuration that embeds the database in a separate snap that can easily be connected to MAAS.

Bug fixes

We’ve also fixed number of bugs (see the list in Launchpad). Notable among these are the following:

Known issues

  • Browser caching issue: There is a known issue with browser caching on some MAAS pages. If you initially encounter a page which does not appear to be correctly formatted, please manually clear your browser cache (not Ctrl-F5) and it should restore the page to normal. You manually clear your browser cache, for example, in the “History” section of the menu on a Chrome browser.

  • Extra power types when adding chassis: (see bug report) When adding a chassis, the “Power type” drop-down will show power types not supported by a chassis. Selecting one of the non-supported power types will result in the UI blocking the action. Here is a list of power types supported for chassis creation:

    • mscm - Moonshot Chassis Manager
    • msftocs - Microsoft OCS Chassis Manager
    • powerkvm - Virtual Machines on Power KVM, managed by Virsh
    • recs_box - Christmann RECS|Box servers
    • sm15k - SeaMicro 1500 Chassis
    • ucsm - Cisco UCS Manager
    • virsh - virtual machines managed by Virsh
    • vmware - virtual machines managed by VMware

  • MAAS keys count in user list is bogus: (see bug report) The count of keys shown in the User list in the UI is wrong.

  • Leftover lock files may be present under some conditions: Even if you purge an old MAAS Debian package, it can leave lock files in /run/lock/maas*. This can cause issues if you later reinstall MAAS, and the previous MAAS user UID has been reassigned. At that point, MAAS can’t remove those files and create new ones. If this occurs, it is easily fixed by removing those files manually before reinstalling.