MAAS 2.5.0 (alpha1)
Important announcements
MAAS architectural and high availability changes
MAAS 2.5 is introducing several improvements that change the interaction between controllers and machines. More specifically:
- Communication will now be proxied through the rack controllers. Machines will no longer communicate with the region controller directly.
- Rack-to-region configuration no longer needs VIPs for HA environments.
For more details, please read the following section.
New features & improvements
Proxying communication through the rack controller
Improvements were made in the way machines communicate with MAAS. In previous versions, machines communicated directly with the region controller to access HTTP (for the metadata), DNS, syslog and proxy.
Starting from MAAS 2.5, this behavior will change. HTTP, DNS, squid and syslog will now be proxied through rack controllers. The goal is to improve the use of MAAS in environments where communication between machines and the region is restricted. In MAAS 2.5alpha1, both metadata access (over HTTP) and DNS are being proxied through the rack controller. In subsequent alpha/beta releases, the rest of the services will be proxied.
-
For DNS, the rack controller now installs and configures bind as a forwarder, allowing machines to query the rack controller directly. Zones management and maintenance are still kept in the region controller.
-
For HTTP, the rack controller now installs nginx, intended to serve both as a proxy and as an HTTP server binding port 5248. This means that machines will no longer contact the metadata server directly in the region controller and will instead contact the rack controller (the one the machine is PXE-booting from).
-
For single-region/rack clusters, this change will not apply, as the region controller will continue to manage DNS and proxy.
Rack-to-Region configuration no longer needs VIP for HA environments
In previous versions of MAAS HA, the rack controller was always configured against a single region controller endpoint. While the rack controller would automatically discover all other region controller endpoints, in the event of a failure of the configured region controller endpoint, the rack was unable to communicate with the region(s). This typically required users to configure (at least) a Virtual IP (VIP) and some type of failover/load-balancing mechanism to ensure that the rack was always able to communicate with the region endpoint. This required the configuration of technologies such as corosync/pacemaker or keepalived to maintain this VIP (and/or HAProxy) on all region controllers.
Starting from 2.5, however, this behavior will change. The rack now allows users to specify multiple region controller endpoints for a single rack controller, thus removing the need for complex dependencies.
While the rack controller will now allow administrators to specify multiple endpoints, subsequent alpha/beta releases will add the ability for MAAS to automatically discover and track all region controllers in a single cluster, as well as automatically attempt to connect to them in the event the one configured is inaccessible.
KVM
MAAS 2.5 introduces further improvements to the KVM pods feature. This includes:
-
Tracking of libvirt storage pools. This allow MAAS to track the usage of the storage pools via libvirt. Currently, this feature is available only in the API. In subsequent 2.5 releases, the UI will be updated to use this feature.
-
MAAS now supports KVM pods in the ARM64 and ppc64el architectures. KVM pod hypervisors for these architectures must be running on Ubuntu 18.04 (bionic) or greater.
Adding machines with IPMI credentials
In previous versions of MAAS, users were required to provide the MAC address of the PXE interface when adding new machines to MAAS. This allowed MAAS to correctly identify the booting machine to provide the correct configuration.
Starting from 2.5, this behavior has slightly changed. Now, users only need to specify IPMI credentials, or a non-PXE MAC address for non-IPMI machines. By doing so, MAAS now automatically discovers the machine and runs the enlistment configuration by either matching the BMC address (on IPMI machines) or by matching the non-PXE MAC address.
Commissioning scripts during enlistment
In older versions, the MAAS enlistment process only gathered very basic information about a machine (more precisely, its architecture and network interface information). As of 2.5, this behavior has changed. MAAS now runs all provided commissioning scripts and gathers all the minimum required information about the machine during the enlistment process.
Note that after the enlistment process, the machine will be placed in the ‘New’ state, as before. In subsequent releases, administrators will be able to make the machine ‘Ready’ simply by running hardware tests. In the meantime, administrators will need to ‘Commission’ the machine.
Resource Pools
MAAS 2.5 officially introduces resource pools. Administrators can organize resources (machines) into pools. In the near future, administrators will be able to restrict access to pools to specific users.
Note that this feature is now backported to 2.4 and will be available in 2.4.1.
Known issues & work arounds
LP: #781662 - Install/upgrade fails is a service is binding port 80.
Since the Rack Controller now depends on Nginx, an installation/upgrade may fail if there is another service binding port 80. We are working alongside the Nginx maintainer to ensure that this is no longer an issue.
To work-around the issue, simply stop any service binding in port 80 before the install or upgrade.