[SRU] MAAS 2.3.5
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
maas (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
This is a new upstream release that addresses various issues present in 2.3.0.
MAAS 2.3.4 fixes various issues that were present on MAAS 2.3.0.
https:/
https:/
https:/
https:/
https:/
This point release includes fixes/enhancements for hardware enablement and to address customer related issues that are worth noting:
Enhancements/
-------
* Bug 1750622 "[feature] Add ability to select the BIOS boot method for IPMI - To address issues with newer firmware"
This adds a new option to power manage machines, that are oriented at addressing changes in upstream hardware firmware's (that have broken compatibility with older versions). Causes no behavior changes for MAAS as it continues to do the same.
Regression potential: None. MAAS will continue to behave the same way it did before in new installs and upgrades, and this change only takes effect by a user driven action.
Bug 1758760 "[enhancement] Support Lenovo’s new password policy (Lenovo SR550)"
Fixes the password generation process for IPMI discovery to consider new password policies that are being added to newer hardware or firmware versions.
Regression potential: None. MAAS will continue to behave the same way it did before in new installs and upgrades, by testing the old password policy. If it doesn't work it will use the new password policy.
LP: #1779712 [enhancement] maas-proxy port should be configurable
Adds the ability to change the proxy port for the proxy that MAAS uses. If users upgrade, the configuration rendered will continue to use the default port. This will only take effect for users who change the port.
Regression potential: None. MAAS will continue to behave the same way it did before in new installs and upgrades, by using the default port. This change only takes effect by a user driven action.
LP: #1778710 [2.3] Allow telling MAAS image import to not use proxy.
Allow's users to tell MAAS to import images without using the configured proxy, in cases that MAAS is directly connected to the internet but machines are not.
Regression potential: None. MAAS will continue to behave the same way it did before in new installs and upgrades, this would only take effect by a user driven action.
Bug fixes that change existing behaviour
-------
Bug 1739761 [adds support to deploy Precise on MAAS 2.3]
Re-adds the ability to deploy precise, which was dropped on MAAS 2.3 initially.
Bug 1730751 "LACP rate fast by default"
Changes the default LACP rate to fast, which addresses issues in that our IS department was facing. Note that this only changes how often the control packets are set and it is recommended/
Bug 1767137 "Default install is now importing bionic by default instead of xenial"
This is an issue that MAAS automatically started selection Bionic for commissioning instead of Xenial as it was intended. This ensure that Xenial is selected by default. Note that in case of upgrades, if Bionic is already selected, MAAS won't change this to Xenial. It will *only* affect to new installs.
Other
LP: #1787381 - WebUI overrides proxy values that have not changed
The WebUI was overriding values that had not been changed in the WebUI. This bugs addresses this issue to ensure it only does it if something changes.
[Test Case]
MAAS Testing
------------
MAAS testing has been done in various cases, partially documented https:/
1. Manual Fresh installation of MAAS
2. Manual upgrade from the previous Ubuntu Release.
3. Automated (CI) testing of MAAS install and operation as per the MAAS' CI.
4. Automated (CI) testing of MAAS install and operation against other Canonical's product (juju, Canonical OpenStack & Kubernetes) provided by the Canonical Solutions QA Team.
5. Manual split region/rack test are performed. This is to ensure that if we upgrade a MAAS Region to a newer version, the MAAS rack of the older version remains connected and operational.
All of this includes verifying normal operation, issues fixed, and ensuring that Canonical Cloud solutions can inter-operate.
LP: #1787381 Testing
-------
This fix requires manual testing. To test:
1. Install MAAS
2. Update maas_proxy_port over the API (e.g. maas <user> maas set-config name=maas_
3. Go to the Web UI and change the proxy method from internal to 'Peer Proxy'
4. Ensure that maas_proxy_port has not changed: (w.g. maas <user> maas get-config name=maas_
Solutions QA
------------
MAAS releases are also now vetted by the Solutions QA team. The test they run ensure there are no regression for their use cases. This release has been accepted / vetted by them.
[Regression Potential]
Minimal (For MAAS itself).
MAAS is fully backwards compatible and handles upgrades from previous releases which result in the continuous operation of MAAS. Users will continue to use this new version of MAAS as they used it before.
Minimal (for deployments).
LP: #1730751 is fixed in this release, which changes the default LACP rate to fast. This doesn't provide any regression for MAAS itself, machines deployed with bonds will have the LACP rate to fast, which will yield discovery of errors much faster.
Since this is a point release, this has been tested thoroughly to confirm that no regressions have been introduced.
description: | updated |
description: | updated |
summary: |
- [SRU] MAAS 2.3.3 + [SRU] MAAS 2.3.4 |
description: | updated |
description: | updated |
no longer affects: | maas (Ubuntu Artful) |
description: | updated |
description: | updated |
description: | updated |
tags: |
added: verification-failed removed: verification-needed |
description: | updated |
Changed in maas (Ubuntu): | |
status: | New → Fix Released |
SRU review:
Potentially breaking changes should be brought to the attention of the SRU team. Based on a detailed review of the proposed changes, this does not currently seem to be happening. I've (non-exhaustively) detailed the proposed changes that bring me concern below.
This also seems to mismatch the definition of a MAAS point release in the draft (currently on version 7) of https:/ /wiki.ubuntu. com/MAASUpdates
List of changes in behaviour to existing users that suggest to me a backwards compatibility break:
Bug 1767137 "Default install is now importing bionic by default instead of xenial" [this "fix" will change the current default behaviour in stable Ubuntu releases]
Bug 1742703 "Virsh pod: autostart for created virtual machines is not enabled"
Bug 1741165 "Deleting a machine from a KVM pod doesn't delete its disk image"
General Feature additions:
Bug 1730751 "LACP rate fast by default"
Bug 1704501 "Can't change which fabric a vlan belongs to"
Bug 1738127 "[enhancement] MAAS doesn't have a favicon"
Bug 1739761 [adds support to deploy Precise on MAAS 2.3]
Please provide justifications for each of the changes (listed above, and any others that I missed) that are going into this potential update to MAAS that have the potential to break backward compatibility. Also please itemize new features, as is written in the MAASUpdates wiki page.
The following I note because I was expecting that this point release contained bugfixes only (based on the definition of a point release on your proposed SRU policy page), but also found unexpected feature additions. I understand there is a current exception request in process, and feature updates are expected in some cases, but those feature and backward compatibility changes should be called out as such directly in the SRU bug.
These Hardware enablement related feature additions also took me by surprise since they don’t fit into the “point release” definition in the MAASUpdates wiki page. Shouldn’t this then be a “2.4” release (“new upstream releases” in the document)?
Bug 1750622 "[feature] Add ability to select the BIOS boot method for IPMI - To address issues with newer firmware"
Bug 1758760 "[enhancement] Support Lenovo’s new password policy (Lenovo SR550)"
To move forward, please itemize the potential backward compatibility breaking changes in this proposed SRU, and clear up the confusion on hardware enablement changes coming in via a “new upstream point release” as defined in MAASUpdates.