[SRU] MAAS 2.3.4

Bug #1772010 reported by Andres Rodriguez on 2018-05-18
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
maas (Ubuntu)
Undecided
Unassigned
Xenial
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://launchpad.net/maas/+milestone/2.3.1
https://launchpad.net/maas/+milestone/2.3.2
https://launchpad.net/maas/+milestone/2.3.3
https://launchpad.net/maas/+milestone/2.3.4

This point release includes fixes/enhancements for hardware enablement and to address customer related issues that are worth noting:

Enhancements/Hardware Enablement
--------------------------------

* 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/preferred to be set to fast, and the use of slow is discouraged.

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.

[Test Case]

MAAS Testing
------------
MAAS testing has been done in various cases, partially documented https://wiki.ubuntu.com/MAASUpdates. This include:

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.

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.

Robie Basak (racb) wrote :

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.

Download full text (6.0 KiB)

Hi Robbie,

I'll address your concerns inline to remain in context:

>
> 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]
>

Before Bionic, *new* MAAS 2.3 installs would select Xenial as the default
OS. One bionic was release, and due to the bug above, new installs started
selecting Bionic as the default OS. Given that MAAS is installed in Xenial,
it is our intention to select Xenial as the default OS, which this bug
fixes. That said, since this is only used for Commissioning, Bionic is
fully supported for commissioning as well, and given that's a process
that's only to gather information of the machine, its not considered a
breakage of backwards compatibility.

Bug 1742703 "Virsh pod: autostart for created virtual machines is not
> enabled"
>

This is a bugfix that resolves an issue where VM's are not auto-started
once the host (a MAAS KVM Pod) is restarted. The expectation of all of our
pod users was that their VM's inside a Pod were restarted once the host was
restarted. This is not considered a break in backwards compatibility
provided that this only applies to newly created VM's, and addresses the 1.
the proper design of the feature and what the intention was. 2. the user
expectations that were causing incorrect behavior in production services
and impacting users.

Bug 1741165 "Deleting a machine from a KVM pod doesn't delete its disk
> image"
>
>
Users & MAAS expect that when a VM create by MAAS is deleted (by MAAS), the
virtual disk is to be deleted to free up the resources used. The bug is the
contrary to that as it would cause the system to run out of resources
because MAAS deleted VM disks were not being cleaned up. As such, the
change doesn't break backwards compatibility. Rather, it fixes behavior
that was breaking user's expectations and was causing unintentional
resource exhaustion (and in effect, making the feature unusable).

> General Feature additions:
>
> Bug 1730751 "LACP rate fast by default"
>

Addresses customer issues.

>
> Bug 1704501 "Can't change which fabric a vlan belongs to"
>

This is not a feature, this is a bug fix that prevented changing the fabric
that a VLAN belonged to.

>
> Bug 1738127 "[enhancement] MAAS doesn't have a favicon"
>

This is not a feature, it fixes an issue where MAAS was pointing to the
incorrect icon to use as the favicon (e.g. only changes which icon is being
used).

>
> Bug 1739761 [adds support to deploy Precise on MAAS 2.3]
>

Addresses customer issues.

>
> Please provide justifications for each of the changes (listed above, and
> any others that ...

Read more...

description: updated
description: updated

Update: I discussed this with Andres out of band on 13 July, and he will provide a replacement upload and update the bug description further.

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
Robie Basak (racb) wrote :

Hi Andres,

Thank you for the bug description updates. I like the headings you have now, assuming "Bug fixes that introduce" is supposed to be "Bug fixes that introduce behaviour changes". These are useful and is exactly the information I needed in the SRU information to be able to review this. Can I suggest that this be put into the MAAS SRU policy draft to speed the process up for next time?

Are all the features added to 2.3.4 already present in the version of MAAS in Bionic? I believe this is an SRU policy requirement for new features. For example, I'm not sure about bug 1778710. This new feature went in to both 2.3.4 and the 2.4 series, but it looks like this landed in 2.4 in July yet xenial-proposed is based on an upstream tarball first uploaded in June. Would someone using Xenial after this SRU lands and benefiting from this feature face a regression in upgrading to Bionic? If so, the feature needs to land in Bionic first, but I don't see maas in the Bionic SRU queue.

I don't see any reason to block this from entering xenial-proposed based on this so I'll keep reviewing, but if this is the case (and I've not misunderstood your release workflow) then I think it would block a release to xenial-updates until the corresponding update to 2.4.x hits bionic-updates.

Robie Basak (racb) wrote :

> ...but it looks like this landed in 2.4 in July yet xenial-proposed is based on an upstream tarball first uploaded in June.

I meant _bionic-proposed_ is based on an upstream tarball first uploaded in June.

Robie Basak (racb) on 2018-08-10
description: updated
Robie Basak (racb) wrote :

I've reviewed the changes from 2.3.3 to 2.3.4 and I'm satisfied with all of those.

On 2.3.0 to 2.3.3:

Xenial vs. Bionic for commissioning only changes new installs. Existing installs are unaffected, so this is OK now that we have that detail documented.

"LACP rate fast by default" does change existing behaviour, but based on Andres' description out of band I'm satisfied that in practice there should be no users for whom this regresses anything.

Changed in maas (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed verification-needed-xenial

Hello Andres, or anyone else affected,

Accepted maas into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/maas/2.3.4-6508-g4f77e30-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Robie Basak (racb) wrote :

Please note that this is blocked from being published to xenial-updates until the features being added in this SRU land in bionic-updates. To avoid mistakes, please do not tag verification-xenial-done or verification-done until that SRU is also ready to release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers