ServerImageValidationAndQA

Differences between revisions 3 and 9 (spanning 6 versions)
Revision 3 as of 2011-05-24 22:33:34
Size: 2812
Editor: 076-076-148-180
Comment:
Revision 9 as of 2011-06-01 22:11:47
Size: 4750
Editor: 076-076-148-180
Comment:
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
 * Alpha wishes to build a cluster of ARM servers, and wants software that is known to work for all her usecase
 * Bet
a is migrating from Ubuntu i386 -> armel on new hardware, and wants the same level of functionality they have come to expect on i386
 * Delta is a system manufacturer creating ARM servers, and wishes to ship a well-tested product with their hardware
 * Alpha is migrating from Ubuntu i386 -> armel on new hardware, and wants the same level of functionality they have come to expect on i386
 * Beta is a system manufacturer creating ARM servers, and wishes to ship a well-tested product with their hardware
Line 25: Line 24:
 * jenkins-slave can run on ARM
 * LXC can be used in place of virtualization
 * Hardware can be made available for automated QA testing, and benchmarking
Line 28: Line 30:
=== Automated QA Testing ===
As part of QA efforts on x86, there is an extensive battery of automated tests that run to make sure basic functionality in the server image is present and accounted for. These tests are based around using a virtualized environment to install the image via preseeding, then running automated tests against said image. The test suite will have to be modified in such a way that we can handle bare-metal installs via netboot images, as well as changing any necessary console input.
=== QA Testing ===
As part of QA efforts on x86, there is an extensive battery of automated tests that run to make sure basic functionality in the server image is present and accounted for. These tests are based around using a virtualized environment to install the image via preseeding, then running automated tests against said image. Ideally, the test suite will have to be modified in such a way that it could be handled by LXC in place of a virtualized environment.
Line 33: Line 35:
TBD As part of our QA efforts, an ongoing attempt to track speed and performance on ARM servers is required. Specifically, being able to test the result of the hardware itself with a stock Ubuntu load would be extremely useful. The Phoronix Test Suite for i386/amd64 already includes a comprehensive set of tests and benchmarking tools to this end, and would be a good place to start with on-device benchmarking. Server load-testing itself is out of scope for this spec and is covered in UbuntuSpec:server-o-load-testing

=== Image Validation ===
In addition to automated QA, several areas that are not directly tested for as part of automated testing. As identified during the Server on ARM session, there are several key areas we need to validate and make sure that are functional even though we do not use them as part of an out of the box install. Specifically, this covers IPv6, iSCSI booting/installation, RAID support, ruby-on-rails, IPsec, ensemble and orchestra, Landscape, LXC, and OpenStack.
Line 37: Line 42:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: === QA Testing ===
Although debian-installer doesn't support installing into an LXC container, we can still get the automated test coverage by debootstrapping the base system, then installing the minimal, standard, and server tasks, in addition to the specific task we wish to test. Although this prevents us from automatically testing the installer, it will insure the actual packages are installable and functional. Image ISO testing will continue as normal at each milestone release.
Line 39: Line 45:
=== Code Changes === === Entropy Validation ===
As part of ensuring good support for SSL and other server crypto needs, we need to validate the entropy source in the kernel on arml. The Ubuntu QA tools have scripts that will check the entropy output to determine its quality.
Line 41: Line 48:
Code changes should include an overview of what needs to change, and in some cases even the specific details. === Benchmarking ===
The Phoronix test suite provides a well rounded set of best mark tests to help gauge an individual SoCs performance. Combined with a minimal load of Ubuntu, and a pre-selected set of benchmarks to run will provide a solid basis for gauging individual board performance. In addition, load testing results as part of UbuntuSpec:server-o-load-testing will help compliment these numbers closer towards real-life performance.
Line 55: Line 64:
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected.

Summary

Release Note

For the 11.10 cycle, Ubuntu will support ARM server images for all available platforms.

Rationale

As per server-o-arm-image, we'll be implementing server images on ARM for the 11.10 cycle. As ARM has never been target of a server image before, extensive QA and validation efforts will be required.

User stories

  • Alpha is migrating from Ubuntu i386 -> armel on new hardware, and wants the same level of functionality they have come to expect on i386

  • Beta is a system manufacturer creating ARM servers, and wishes to ship a well-tested product with their hardware

Assumptions

  • jenkins-slave can run on ARM
  • LXC can be used in place of virtualization
  • Hardware can be made available for automated QA testing, and benchmarking

Design

QA Testing

As part of QA efforts on x86, there is an extensive battery of automated tests that run to make sure basic functionality in the server image is present and accounted for. These tests are based around using a virtualized environment to install the image via preseeding, then running automated tests against said image. Ideally, the test suite will have to be modified in such a way that it could be handled by LXC in place of a virtualized environment.

Benchmarking

As part of our QA efforts, an ongoing attempt to track speed and performance on ARM servers is required. Specifically, being able to test the result of the hardware itself with a stock Ubuntu load would be extremely useful. The Phoronix Test Suite for i386/amd64 already includes a comprehensive set of tests and benchmarking tools to this end, and would be a good place to start with on-device benchmarking. Server load-testing itself is out of scope for this spec and is covered in server-o-load-testing

Image Validation

In addition to automated QA, several areas that are not directly tested for as part of automated testing. As identified during the Server on ARM session, there are several key areas we need to validate and make sure that are functional even though we do not use them as part of an out of the box install. Specifically, this covers IPv6, iSCSI booting/installation, RAID support, ruby-on-rails, IPsec, ensemble and orchestra, Landscape, LXC, and OpenStack.

Implementation

QA Testing

Although debian-installer doesn't support installing into an LXC container, we can still get the automated test coverage by debootstrapping the base system, then installing the minimal, standard, and server tasks, in addition to the specific task we wish to test. Although this prevents us from automatically testing the installer, it will insure the actual packages are installable and functional. Image ISO testing will continue as normal at each milestone release.

Entropy Validation

As part of ensuring good support for SSL and other server crypto needs, we need to validate the entropy source in the kernel on arml. The Ubuntu QA tools have scripts that will check the entropy output to determine its quality.

Benchmarking

The Phoronix test suite provides a well rounded set of best mark tests to help gauge an individual SoCs performance. Combined with a minimal load of Ubuntu, and a pre-selected set of benchmarks to run will provide a solid basis for gauging individual board performance. In addition, load testing results as part of server-o-load-testing will help compliment these numbers closer towards real-life performance.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected.


CategorySpec

Specs/ARM/ServerImageValidationAndQA (last edited 2011-06-01 22:11:47 by 076-076-148-180)