From Fedora Project Wiki
(Docker Minimal)
(Docker Base)
Line 291: Line 291:
 
| {{result|none}}
 
| {{result|none}}
 
| style="background:lightgrey;"|
 
| style="background:lightgrey;"|
| {{result|none}} {{result|warn|Beta-1.4 ppc64le openQA}} <ref>1440875 selinux on host must be set to permissive</ref> <ref>1: Docker installation on the Fedora 26 VM (packages docker and systemd-container which is required by systemd). 2: loading of the Docker image. 3: Creation of a Docker container based on the image previously loaded. 4: Check a CLI (i.e bash) can be accessed into the container. 5: Check network access by executing a "dnf repolist".</ref>  
+
| {{result|none}} {{result|warn|Beta-1.4 ppc64le openQA|1440875}} </ref> {{result|warn|RC-1.4 menantea|1440875}} <ref>with selinux on host set to permissive 1: Docker installation on the Fedora 26 VM (packages docker and systemd-container which is required by systemd). 2: loading of the Docker image. 3: Creation of a Docker container based on the image previously loaded. 4: Check a CLI (i.e bash) can be accessed into the container. 5: Check network access by executing a "dnf repolist".</ref>  
 
| {{result|none}}
 
| {{result|none}}
 
| {{result|warn|Beta-1.4 ppc64le sinnykumari |1440875}}
 
| {{result|warn|Beta-1.4 ppc64le sinnykumari |1440875}}

Revision as of 09:28, 6 July 2017

Which tests to run

Note.png
Test coverage page
This page provides information about test coverage for the tests on this page across all the composes for the current release: it can help you see which test cases most need to be run.

Tests with a Milestone of Alpha, Beta or Final are the most important. Optional tests are less so, but still useful to run. The milestone indicates that for that milestone release or a later one to be approved for release, the test must have been run against the release candidate build (so at Beta, all Alpha and Beta tests must have been run, for instance). However, it is important to run the tests for all milestones as early and often as possible. Please refer to the test coverage page linked above and try to find and run tests which have not been run at all, or not run recently, for the current release.

How to test

1. Download one or more media for testing:

Image ppc64 ppc64le
nightly compose path Rawhide nightly path f26 nighly path Rawhide nightly path f26 nighly path
cloud image RC-1.4 ppc64 images RC-1.4 ppc64le images
docker image RC-1.4 ppc64le images

2. Perform one or more of the test cases and add your results to the table below

  • You can submit results by editing the page directly for reporting test results.

3. If a test fails, file a bug report. You may propose the bug as a release blocker or freeze exception bug for the appropriate release - see blocker bug process and freeze exception bug process.

Tracker bugs

Some tests must be run against particular Products or images - for example, the #Default boot and install tests. If no particular product or image is specified either in this page or the test case page, you can use any appropriate image. For example, you can run most of the #General Tests with the Server install images.

For nightly compose testing, use the network install images linked above for Server tests. Cloud and non-Product live and disk images should be available from Koji via the searches linked above.|Delta_ISOs for Server offline installer images are available here. If you have the Server offline install image for the previous TC/RC (or in the case of Alpha TC1, the previous stable release), you can generate the current install image with greatly reduced download size.}}

If you notice a problem during a test which does not constitute a complete failure of the test, you should still file a bug report, but it may not be appropriate to propose it as a release blocker bug. Use your judgment in deciding this, with reference to the Fedora_Release_Criteria, which these tests are intended to verify. If you are unsure, err on the side of proposing the bug as a blocker.

Important.png
Don't install updates
Don't install updates before performing any of the tests, as when you are testing pre-releases, available updates are not part of the proposed released package set.
Note.png
Virtual machine testing
In most cases, testing in a virtual machine is OK.

Key

See the table below for a sample format for test results. All test results are posted using the result template.


Test Result Explanation Code Entered
none
Untested - This test has not been run, and is available for anyone to contribute feedback. {{result|none}}
Pass pass robatino
Passed - The test has been run and the tester determine the test met the expected results {{result|pass|robatino}}
Inprogress inprogress adamwill
Inprogress - An inprogress result is often used for tests that take a long time to execute. Inprogress results should be temporary and change to pass, fail or warn. {{result|inprogress|adamwill}}
Fail fail jlaska [1] [2]
Failed - Indicates a failed test. A link to a bug must be provided. See Template:Result for details on providing bug information.
  1. RHBZ #XYZ
  2. RHBZ #ZXY
{{result|fail|jlaska|XYZ|ZXY}}
Warning warn rhe
[1]
Warning - This test completed and met the expected results of the test, but other issues were encountered during testing that warrant attention.
  1. Brief description about the warning status
{{result|warn|rhe}} <ref>Brief description about the warning status</ref>
Pass pass hongqing
Warning warn kparal
Multiple results - More people can easily provide results to a single test case. {{result|pass|hongqing}} {{result|warn|kparal}}
Pass pass previous <build> run
Result from previous test run - This test result is directly moved from the test run of previous <build>. {{result|pass|previous <build> run}}
Unsupported - An unsupported test or configuration. No testing is required.

Test Matrix

Cloud Provider Setup

Expand one of the sections below for instructions on getting set up to run these testcases on a specific provider. More information can be found in the Fedora Cloud guide.

Amazon EC2

  1. Get an AWS account (the approval process can take hours)
  2. Make sure that your security group allows for SSH (default tcp port 22)
  3. Log in to the AWS Management Console
  4. Obtain the AMI id of the image you want to test. For officially released images, check http://cloud.fedoraproject.org/. If you're doing validation testing, there should be some tables of AMI IDs above; if not, try looking through the messages published by the AMI publisher
  5. Search for and select the desired AMI on the IMAGES/AMIs section of the EC2 console
  6. Launch an instance with the AMI under test

Amazon provided this information on various instance types that may be useful to test, in August 2019. Note that you can use 750 hours per month on a t2.micro instance (which is Xen-based) for free for the first year; other instance types, and t2.micro after the first year, cost money. To avoid costs, you can contact the the Infrastructure team and request access to Fedora's AWS account for testing purposes, per this SOP.

x86 platforms

  • Xen domU with only PV interfaces (e.g., M3 instances)
  • Xen domU with Intel 82599 virtual functions for Enhanced Networking (e.g., C3 instances running in a VPC)
  • Xen domU with Enhanced Networking Adapter (e.g., R4 instances)
  • Xen domU with NVMe local instance storage (e.g., virtualized I3 instances)
  • Xen domU with more than 32 vCPUs (e.g., c4.8xlarge)
  • Xen domU with four NUMA nodes (e.g., x1.32xlarge)
  • Xen domU with maximum RAM available in EC2 (x1e.32xlarge)
  • KVM guest with consistent performance (e.g., c5.large)
  • KVM guest with burstable performance (e.g., t3.large)
  • KVM guest with local NVMe storage (e.g., c5d.large)
  • KVM guest with 100 Gbps networking and Elastic Fabric Adapter (c5n.18xlarge)
  • KVM guest on AMD processors (e.g., m5a.large)
  • KVM guest on AMD processors with maximum NUMA nodes (e.g., m5a.24xlarge)
  • Bare metal Broadwell (i3.metal)
  • Bare metal Skylake (m5.metal)
  • Bare metal Cascade Lake (c5.metal)

Arm platforms

  • KVM guest on Arm with 1 CPU cluster (a1.xlarge)
  • KVM guest on Arm with 2 CPU clusters (a1.2xlarge)
  • KVM guest on Arm with 4 CPU clusters (a1.4xlarge)

Openstack

  1. Use your own OpenStack deployment
  2. Provide or create an SSH keypair
  3. Make sure that your security group allows for SSH (default tcp port 22)
  4. Log in to the Horizon dashboard
  5. Find the image URL at http://cloud.fedoraproject.org/ or as provided in release candidate documents.
  6. Add the image to OpenStack, either using the OpenStack web dashboard (see step 4 here) or with glance image-create --name "Fedora version" --disk-format qcow2 --container-format bare --is-public true --copy-from url
  7. Launch the instance (in the dashboard, under the "Images" heading, click the "Launch" button for the appropriate image

Testcloud Local

  1. See Local Test Cloud Installation Guide for instructions on installing and running a testcloud virtual instance.
  2. Once SSH'ed into the virtual cloud instance, you can perform the tests below. NOTE: testcloud will work with both Fedora Cloud and Atomic images.

Openstack Cloud base

Milestone Test Case Bare Metal PKVM BE PKVM LE PVM
BE LE Guest BE Guest LE Guest BE Guest LE LPAR BE LPAR LE
Alpha QA:Testcase_base_startup
none
none
none
Pass pass Beta-1.4 menantea
Pass pass 20170605.n.0 openqa
Pass pass 20170605.n.0 openqa
none
none
Alpha QA:Testcase_base_system_logging
none
none
none
Pass pass Beta-1.4 menantea
[1]
Pass pass 20170605.n.0 openqa
Pass pass 20170605.n.0 openqa
none
none
Final QA:Testcase_Services_start
none
none
none
Pass pass Beta-1.4 menantea
[2]
Pass pass 20170605.n.0 openqa
Pass pass 20170605.n.0 openqa
none
none
Final QA:Testcase_base_selinux
none
none
none
Pass pass Beta-1.4 menantea
Pass pass 20170605.n.0 openqa
Pass pass 20170605.n.0 openqa
none
none
Final QA:Testcase_base_service_manipulation
none
none
none
none
Pass pass 20170605.n.0 openqa
[3]
Pass pass 20170605.n.0 openqa
[4]
none
none
  1. no /var/log/secure
  2. I guess it's normal as network access is ok but anyway: network.service loaded failed
  3. tried login access, not ssh yet
  4. tried login access, not ssh yet

Atomic

Milestone Test Case Bare Metal PKVM BE PKVM LE PVM
BE LE Guest BE Guest LE Guest BE Guest LE LPAR BE LPAR LE
Alpha QA:Testcase_base_startup
none
none
none
none
none
none
none
none
Alpha QA:Testcase_base_system_logging
none
none
none
none
none
none
none
none
Final QA:Testcase_Services_start
none
none
none
none
none
none
none
none
Final QA:Testcase_base_selinux
none
none
none
none
none
none
none
none
Final QA:Testcase_base_service_manipulation
none
none
none
none
none
none
none
none


Docker Minimal

Milestone Test Case Bare Metal PKVM BE PKVM LE PVM
BE LE Guest BE Guest LE Guest BE Guest LE LPAR BE LPAR LE
Optional QA:Testcase_base_startup
none
none
Warning warn RC-1.4 menantea [1]
[2][3]
none
none
none

Docker Base

Milestone Test Case Bare Metal PKVM BE PKVM LE PVM
BE LE Guest BE Guest LE Guest BE Guest LE LPAR BE LPAR LE
Optional QA:Testcase_base_startup
none
none
none
Warning warn Beta-1.4 ppc64le openQA [1]
</ref>
Warning warn RC-1.4 menantea [1]
[4]
none
Warning warn Beta-1.4 ppc64le sinnykumari [1]
none
  1. 1.0 1.1 1.2 1.3 RHBZ #1440875
  2. with selinux on host set to permissive 1: Docker installation on the Fedora 26 VM (packages docker and systemd-container which is required by systemd). 2: loading of the Docker image. 3: Creation of a Docker container based on the image previously loaded. 4: Check a CLI (i.e bash) can be accessed into the container.
  3. 5: Unable to check network !
  4. with selinux on host set to permissive 1: Docker installation on the Fedora 26 VM (packages docker and systemd-container which is required by systemd). 2: loading of the Docker image. 3: Creation of a Docker container based on the image previously loaded. 4: Check a CLI (i.e bash) can be accessed into the container. 5: Check network access by executing a "dnf repolist".