MAASUpdates

Differences between revisions 8 and 9
Revision 8 as of 2018-07-11 21:51:58
Size: 5075
Editor: andreserl
Comment:
Revision 9 as of 2018-07-11 21:54:16
Size: 5087
Editor: andreserl
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
   * New upstream point releases (that contain upstream bug fixes, and Customer or Hardware Enablement bug fixes or feature additions).    * New upstream point releases, which contain upstream bug fixes. (May include Hardware Enablement and/or Customer related fixes or enhacements).

This document describes the policy for updating MAAS in a stable, supported release. MAAS (Metal-as-a-Service) is a Cloud-like deployment tool designed to quickly install Ubuntu in the data center. The following types of changes are allowed as long as the conditions outlined below are met:

  • New upstream point releases, which contain upstream bug fixes. (May include Hardware Enablement and/or Customer related fixes or enhacements).
  • New upstream releases (that contain new features or Hardware Enablement)

MAAS's mission for major releases is to always remain backwards compatible. In the event of any chances that break backwards compatibility, the SRU team approval will need to be obtained.

Requesting the SRU

The SRU should be done with a single process bug, instead of individual bug reports for individual bug fixes. The one bug should have the following:

  • The SRU should be requested per the StableReleaseUpdates documented process

  • The template at the end of this document should be used and all ‘TODO’ filled out
  • Packaging changes (e.g. dependency changes) need to be stated in debian/changelog.
  • If any manual testing occurs it should also be documented.

QA Process

Merges

Updates to upstream MAAS go through the following process:

  • Reviewed and approved by a member of the development team
  • Successful run of unit tests and style tests per landing
  • Daily integration tests post landing

Packaging

For each package generated a successful completion of MAAS’ integration tests, as described below, using the proposed package with no unexplained errors or failures.

Integration Tests

The integration suite validates three major areas:

1. Installation and configuration of MAAS The CI testing of Installation & configuration not only ensures correct operation of MAAS, but also ensures that MAAS provides no regressions with installation and configuration of MAAS.

2. Enlistment, Commissioning, Hardware Testing, Deployment, Rescue Mode, Releasing, etc. These tests ensure that not only MAAS operates correctly through the different stages of the MAAS lifecycle. Deployment tests include Ubuntu, CentOS & Windows.

3. Regression testing against various API endpoints. The CI testing also tests regression testing against non-core API endpoints.

SRU Integration Tests

This runs the same CI test with the exception that I can run against a "proposed" version of Curtin. We do this to ensure that curtin doesn't include regressions in the proposed version.

Hardware deployment

MAAS CI testing ensures that MAAS doesn't regress across the different architectures (amd64, ppc64el, arm64), and tests that the reference hardware can:

  • Power manage the hardware
  • PXE Boot (Legacy / EFI)
  • Deploy the hardware

Since the the successful deployment of a machine via MAAS uses 'curtin' (and cloud-init) (e.g. to configure networking, configure storage, configure EFI, etc), MAAS CI ensure that these tests are successful in the reference hardware.

Any deployment failures that could incur in different hardware are evaluated dependending on the version of curtin/cloud-init, the Ubuntu kernel, others.

Manual tests

Manual tests are also performed to test the following:

  • Fresh installation.
  • Upgrade from the previous release in Ubuntu archives (on region & rack running on the same machine).

  • Upgrade the Region Controller first from the previous release on a split Region / Rack.

SRU Template

== Begin SRU Template ==
[Impact]
This is a new upstream release [that addresses various issues | introduces various new features]:

MAAS [<version>] introduces the following features:

 * <feature>
 * <feature>

MAAS [<version>]

[Test Case]
MAAS testing has been done in various cases. 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. MAAS releases are also now vetted by the Solutions QA team.

[Regression Potential]
Minimal (For MAAS). MAAS is fully backwards compatible (the CI ensures that's the case) and handles upgrades from previous releases which result in the continuous operation of MAAS.

Medium (For not tested set of hardware) - A new version of Curtin has been SRU'd, and as such, this could impact the deployment of non-tested Hardware paths.

== End SRU Template ==

<TODO: Paste in change log entry>

MAASUpdates (last edited 2018-07-11 21:54:16 by andreserl)