Comment 2 for bug 1772010

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

Addresses issues of several customers.

>
> Bug 1758760 "[enhancement] Support Lenovo’s new password policy (Lenovo
> SR550)"
>
>
Addresses issues of several customers.

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

I've updated the wikipage. Point releases may contain HWE/Customer related
enhancements/features that follow the same premises as bugfix only point
releases, as defined by the organizational goals and/or support of our
customers.

Let me know if you have any other concerns.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1772010
>
> Title:
> [SRU] MAAS 2.3.3
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1772010/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=maas; component=main;
> status=New; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=xenial;
> sourcepackage=maas; component=main; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=artful;
> sourcepackage=maas; component=main; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl racb
> Launchpad-Bug-Reporter: Andres Rodriguez (andreserl)
> Launchpad-Bug-Modifier: Robie Basak (racb)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: andreserl
>

--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer