Architectures/PowerPC/Fedora 27 PowerPC Cloud

Which tests to run

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 f27 nighly path f27 nighly path	Rawhide nightly path f27 nighly path
Cloud base images	None	f27 Beta-1.3 f27 Beta-1.5 RC-1.6
Atomic images	None	RC-1.6
Docker images	None	f27 Beta-1.3 f27 Beta-1.5 Minimal RC-1.6 Base RC-1.6

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

• F27 PPC Beta

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.

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.

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.

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 robatino	Passed - The test has been run and the tester determine the test met the expected results	{{result|pass|robatino}}
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 jlaska	Failed - Indicates a failed test. A link to a bug must be provided. See Template:Result for details on providing bug information.	{{result|fail|jlaska|XYZ|ZXY}}
warn rhe	Warning - This test completed and met the expected results of the test, but other issues were encountered during testing that warrant attention.	{{result|warn|rhe}} <ref>Brief description about the warning status</ref>
pass hongqing warn kparal	Multiple results - More people can easily provide results to a single test case.	{{result|pass|hongqing}} {{result|warn|kparal}}
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 setting up and running these testcases on a specific provider. More information can be found on the Fedora Cloud page and the Cloud Working Group website.

Amazon EC2 (via management console)

Personal account

1. Obtain an AWS account (the approval process can take several hours).

Fedora group account

Amazon provides us with a community account. This account is currently used by: Fedora Infra, CentOS, Fedora-CI, openQA, logdetective, CoreOS, Cloud, ABRT, and others.

To avoid costs, you can contact the Infrastructure team and request access to Fedora's AWS account for testing purposes, per this SOP.

1. Check your groups at https://accounts.fedoraproject.org/user/<ACCOUNT>.
2. You must be in the aws-* FAS group (or another group with access) to perform this action.
3. To access the AWS Console via Ipsilon authentication, use this SAML link.

Launch an Instance

1. Log in to the AWS Management Console.
2. Navigate to the EC2 console.
3. To select the desired Amazon Machine Image (AMI), you can either:
   • Use the "Direct launch link" (if provided).
   • Search for and select the desired AMI in the IMAGES > AMIs section of the EC2 console.
4. Ensure that your instance's security group is configured to allow SSH access (default TCP port 22).
5. Launch an instance with the AMI.

Amazon EC2 (via Testing Farm)

Testing Farm Access - Testing Farm provides a streamlined way for Fedora and CentOS Stream contributors to access Amazon machines for testing. More information about public ranch users can be found here.

1. Access Method: You can access Amazon images via Testing Farm; see the installation steps.
2. Obtain API Key: Generate your public API key for Testing Farm. Note: The API key is shown only once and is distinct from the API ID. Generate API key.
3. In Terminal: export TESTING_FARM_API_TOKEN=<TOKEN>
4. Search: Find the appropriate nightly build and architecture from the latest datagrepper message (e.g., x86_64 or aarch64).
5. In Terminal (Reserve Machine): Use the following command as an example: testing-farm request --sanity --compose Fedora-Cloud-Base-AmazonEC2.x86_64-Rawhide-20251119.0 --arch x86_64 --reserve

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

Local testing

1. You can deploy the cloud image locally either using the well-known virt-install tool or a Fedora-specific testcloud tool. See Local cloud testing with virt-install or Testcloud quickstart guide, respectively.
2. Once logged in the virtual cloud instance, you can perform the tests below.

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	none	none	warn f27-20171004.n.0 menantea pass RC-1.3 menantea	none	none
Alpha	QA:Testcase_base_system_logging	none	none	none	none	none	pass f27-20171004.n.0 menantea pass RC-1.3 menantea	none	none
Final	QA:Testcase_Services_start	none	none	none	none	none	fail f27-20171004.n.0 menantea fail RC-1.3 menantea	none	none
Final	QA:Testcase_base_selinux	none	none	none	none	none	pass f27-20171004.n.0 menantea pass RC-1.3 menantea	none	none
Final	QA:Testcase_base_service_manipulation	none	none	none	none	none	fail f27-20171004.n.0 menantea pass RC-1.3 menantea	none	none

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	pass f27-20171009.n.0 menantea pass RC-1.3 menantea pass RC-1.2 sinnykumari pass RC-1.6 sinnykumari	none	none
Alpha	QA:Testcase_base_system_logging	none	none	none	none	none	pass f27-20171009.n.0 menantea pass RC-1.3 menantea pass RC-1.2 sinnykumari pass RC-1.6 sinnykumari	none	none
Final	QA:Testcase_Services_start	none	none	none	none	none	pass f27-20171009.n.0 menantea pass RC-1.3 menantea pass RC-1.2 sinnykumari pass RC-1.6 sinnykumari	none	none
Final	QA:Testcase_base_selinux	none	none	none	none	none	pass f27-20171009.n.0 menantea pass RC-1.3 menantea pass RC-1.2 sinnykumari pass RC-1.6 sinnykumari	none	none
Final	QA:Testcase_base_service_manipulation	none	none	none	none	none	pass f27-20171009.n.0 menantea pass RC-1.3 menantea pass RC-1.2 sinnykumari pass RC-1.6 sinnykumari	none	none

Modular

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		pass Fedora-Modular-27-20171031.n.2 sinnykumari pass Modular_Beta-1.5 sinnykumari		pass Beta-1.3 efi fail Modular-20171010.n.0 efi pass Modular-20171102.n.0 menantea

Docker Container Minimal 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		warn f27-Beta-1.3 menantea pass RC-1.3 menantea		pass RC-1.2 sinnykumari pass RC-1.6 sinnykumari		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		warn f27-Beta-1.3 menantea pass RC-1.3 menantea		pass RC-1.2 sinnykumari pass RC-1.6 sinnykumari		none