If you're already using MAAS, this is probably how you get to a new version
Errors or typos? Topics missing? Hard to read? Let us know!
Upgrade your MAAS setup using this guide. Don't forget to consult the installation notes at the end.
If your MAAS environment includes multiple machines with identical IPMI BMC IP addresses and usernames but different passwords, please review this potential migration issue when upgrading your MAAS instance.
Upgrade to MAAS 3.4: A Snap Tutorial with PostgreSQL Considerations
Switching to MAAS 3.4? Here's a quick rundown on how to upgrade your snap installation. Before diving in, note that PostgreSQL 12 support is ending with MAAS 3.4 and won't be available in 3.5. We suggest upgrading to PostgreSQL 14 first.
For a region+rack setup, run this command:
sudo snap refresh maas
Be sure to input your password. Your snap will update to the 3.4 channel, no MAAS re-initialization required.
For separate regions and racks, update the rack nodes first with the above command, followed by the region nodes.
When installing MAAS on Ubuntu, there can be conflicts between the existing NTP client, systemd-timesyncd, and the NTP client/server provided by MAAS, chrony. This can lead to time synchronization issues, especially if MAAS is configured with different upstream NTP servers than the ones used by systemd-timesyncd. To avoid conflicts, users can manually disable and stop systemd-timesyncd using the following command:
sudo systemctl disable --now systemd-timesyncd
Also note that support for PostgreSQL 12 has been deprecated in MAAS 3.3 and will be discontinued in MAAS 3.5.
Upgrading MAAS when using duplicate IPMI BMC credentials
This note is especially important for upgrading to MAAS 3.3, but may affect other upgrade paths as well.
If your MAAS environment includes multiple machines with identical IPMI BMC IP addresses and usernames but different passwords, please be aware of a potential migration issue when upgrading your MAAS instance.
Background:
In MAAS 3.3, a migration script (0290_migrate_node_power_parameters) moves the BMC password from power_parameters to a secure store. A unique database constraint (power_type, md5(power_parameters::text)) that previously allowed for identical BMC IPs and usernames with different passwords now fails because the power_pass field is removed during the migration, causing an upgrade failure.
Steps to prevent upgrade failure:
Pre-upgrade check: Before upgrading, ensure that each BMC IP address and username combination is unique. This is essential as the migration script enforces a unique constraint that may not align with your current setup.
Identify affected machines: Use the MAAS CLI to list all machines and their power parameters. Look for any entries with duplicate BMC IP and username combinations.
Update machine configurations: For any duplicates found, update the BMC details to have unique combinations. This may involve reconfiguring or decommissioning machines as needed.
Proceed with upgrade: Once all BMC details are unique, proceed with the upgrade to MAAS 3.3. Monitor the upgrade process for any errors related to power parameters.
Understanding the unique constraint: The unique constraint was designed to prevent duplicate IPMI IP/Username/Password combinations. However, in practice, this constraint might not cover all scenarios, especially where configurations are automatically generated and share many common values.
Future considerations: The development team is aware of this issue and is considering changes to improve the upgrade process, such as adjusting the unique constraint and improving API/UI level checks. Further updates will be provided in subsequent releases.