Red Hat Software Test Suite 2.0

User Guide

for the Red Hat Software Test Suite, and its patch releases

Edition 1

Scott Mumford

Red Hat
Engineering Content Services

Jared Morgan

Red Hat
Engineering Content Services

Legal Notice

This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Abstract

This document is intended for Independent Software Vendors (ISVs) and Red Hat Certified Cloud Providers. It outlines the benefits of participation in the Red Hat Software Test Suite program.

Preface

1. Document Conventions

1.1. Typographic Conventions
1.2. Pull-quote Conventions
1.3. Notes and Warnings

2. Getting Help and Giving Feedback

2.1. Do You Need Help?
2.2. We Need Feedback!

1. Introduction

1.1. Audience
1.2. Rationale

2. Prerequisites

2.1. Bugzilla group membership
2.2. Red Hat subscription
2.3. Red Hat Software Test Suite Server channel
2.4. Hardware certified by Red Hat

3. Obtaining the Software Test Suite

3.1. Downloading from the Red Hat Network Channel
3.2. Installing from the command line
3.3. stsclient plug-ins

4. Running the Test Suite

5. Using plug-ins

5.1. Generic Plugin Actions

5.2. Plugin-Specific Actions

5.2.1. The ELF plug-in
5.2.2. The Cloud plug-in
5.2.3. The FTP plug-in
5.2.4. The packaging plug-in
5.2.5. The filesystem plug-in

6. Raising a Bugzilla Request

6.1. Raising a request using the Bugzilla interface
6.2. Using the Software Test Suite to raise a request

7. Test Results

7.1. Submitting results using the test suite
7.2. Submitting results manually
7.3. Using a proxy server

8. Submitting bug reports

A. User-specific process overviews

A.1. I am an ISV Partner and have my application packaged as an RPM.
A.2. I am an ISV Partner and have my application installed on my system using an RPM package.
A.3. I am an ISV Partner and my application is in a non-RPM format.
A.4. I am a Red Hat Certified Cloud Provider and want to validate my cloud image

B. Revision History

Index

Preface

1. Document Conventions

This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.

In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later include the Liberation Fonts set by default.

1.1. Typographic Conventions

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.

Mono-spaced Bold

Used to highlight system input, including shell commands, file names and paths. Also used to highlight keys and key combinations. For example:

To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.

The above includes a file name, a shell command and a key, all presented in mono-spaced bold and all distinguishable thanks to context.

Key combinations can be distinguished from an individual key by the plus sign that connects each part of a key combination. For example:

Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to a virtual terminal.

The first example highlights a particular key to press. The second example highlights a key combination: a set of three keys pressed simultaneously.

If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:

File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.

Proportional Bold

This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:

Choose System → Preferences → Mouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, select the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
To insert a special character into a gedit file, choose Applications → Accessories → Character Map from the main menu bar. Next, choose Search → Find… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose Edit → Paste from the gedit menu bar.

The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.

Mono-spaced Bold Italic or Proportional Bold Italic

Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:

To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.

Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.

Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:

Publican is a DocBook publishing system.

1.2. Pull-quote Conventions

Terminal output and source code listings are set off visually from the surrounding text.

Output sent to a terminal is set in mono-spaced roman and presented thus:

books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs

Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:

static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
                 struct kvm_assigned_pci_dev *assigned_dev)
{
         int r = 0;
         struct kvm_assigned_dev_kernel *match;

         mutex_lock(&kvm->lock);

         match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
                                       assigned_dev->assigned_dev_id);
         if (!match) {
                 printk(KERN_INFO "%s: device hasn't been assigned before, "
                   "so cannot be deassigned\n", __func__);
                 r = -EINVAL;
                 goto out;
         }

         kvm_deassign_device(kvm, match);

         kvm_free_assigned_device(kvm, match);

out:
         mutex_unlock(&kvm->lock);
         return r;
}

1.3. Notes and Warnings

Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.

Note

Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

Important

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration.

Warning

Warnings should not be ignored. Ignoring warnings will most likely cause data loss.

2. Getting Help and Giving Feedback

2.1. Do You Need Help?

If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal at http://access.redhat.com. Through the customer portal, you can:

search or browse through a knowledgebase of technical support articles about Red Hat products.
submit a support case to Red Hat Global Support Services (GSS).
access other product documentation.

Red Hat also hosts a large number of electronic mailing lists for discussion of Red Hat software and technology. You can find a list of publicly available mailing lists at https://www.redhat.com/mailman/listinfo. Click on the name of any mailing list to subscribe to that list or to access the list archives.

2.2. We Need Feedback!

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/ against the product Red Hat Software Test Suite.

When submitting a bug report, be sure to mention the manual's identifier: User_Guide

If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

Chapter 1. Introduction

1.1. Audience
1.2. Rationale

Welcome to the Red Hat Software Test Suite User Guide. This guide explains the rationale of the software testing program, how to obtain and install the Software Test Suite and the testing process itself.

1.1. Audience

The Red Hat Software Test Suite User Guide is intended for use by Independent Software Vendors (ISVs) or Red Hat Certified Cloud Providers interested in quantifying the binary compatibility of their applications with specific Red Hat Enterprise Linux releases or verifying cloud application images.

A strong working knowledge of Red Hat Enterprise Linux is assumed.

1.2. Rationale

The Red Hat Software Testing Suite is intended as a tool to ascertain the compatibility of third-party software products with the Red Hat Enterprise Linux operating system.

The current release of the Suite gathers information about the Application Binary Interface (ABI) symbols and dependencies of local applications and can also be used to verify cloud application images. This information can assist software vendors collect the dependencies of their applications on Red Hat Enterprise Linux system libraries.

The tools also allow users to send their data to Red Hat for validation against the most current compatibility guarantees. Red Hat remains committed to supporting applications across multiple versions of the platform and this data will allow Red Hat to pro-actively validate and update its binary compatibility policy based on vendor feedback.

Chapter 2. Prerequisites

2.1. Bugzilla group membership
2.2. Red Hat subscription
2.3. Red Hat Software Test Suite Server channel
2.4. Hardware certified by Red Hat

You will need to fulfill various prerequisites to use the Red Hat Software Test Suite. Please read the following list carefully to ensure you have everything you will need to complete the process:

An RPM of the software package to be tested.
While a valid RPM is the preferred testing subject, this is not a prohibitive requirement of the Test Suite (later sections of this document will discuss alternative testing subjects).
A Bugzilla registration with appropriate group permissions. See Section 2.1, “ Bugzilla group membership ”
A valid and active subscription for Red Hat Enterprise Linux 5 or Red Hat Enterprise Linux 6. See Section 2.2, “ Red Hat subscription ”
A subscription to the Red Hat Software Test Suite channel on the Customer Support Portal. see Section 2.3, “ Red Hat Software Test Suite Server channel”
Hardware certified by Red Hat. See Section 2.4, “ Hardware certified by Red Hat ”

2.1. Bugzilla group membership

Software developers participating in the Red Hat software testing process will interact with Red Hat through the Red Hat Bugzilla interface. In this stage of the program vendors have been nominated and the appropriate Bugzilla permissions have been granted to their Bugzilla registrations.

New testing requests are lodged via the "My Requests" page at http://bugzilla.redhat.com. These requests are used to nominate the binary package that the Test Suite is to be run against. The Bugzilla page is also used to raise a bug against the client/vendor side component of the Software Test Suite. Instructions on how to use the Bugzilla interface are included in Chapter 6, Raising a Bugzilla Request

2.2. Red Hat subscription

To access the Software Test Suite you will need an active Red Hat Enterprise Linux subscription. This subscription will grant you access to the Customer Support Portal, and the required packages. The Customer Support Portal allows you to easily manage all aspects of a Red Hat Enterprise Linux system. Access to the Customer Support Portal is included with all Red Hat Enterprise Linux subscriptions. For more information about the Customer Support Portal, go to https://access.redhat.com.

Buy a subscription on-line: https://www.redhat.com/wapps/store/catalog.html.
Information about developer subscriptions can be found here: https://access.redhat.com/support/offerings/developer/.
Contact our Sales team for help: https://engage.redhat.com/forms/contact-sales
Or renew an existing subscription: https://access.redhat.com/wapps/support/protected/renewals.html

2.3. Red Hat Software Test Suite Server channel

Within the Customer Support Portal access granted with your Red Hat Enterprise Linux subscription, you must be specifically subscribed to the Red Hat Software Test Suite channel relevant to your operating system, as this is where the Software Test Suite packages are located.

Instruction for confirming or creating this subscription are included in Section 3.1, “Downloading from the Red Hat Network Channel”

2.4. Hardware certified by Red Hat

Ensure that the Software Test Suite is installed and run on hardware that is certified by Red Hat. More details about certified hardware can be found at http://hardware.redhat.com.

Chapter 3. Obtaining the Software Test Suite

3.1. Downloading from the Red Hat Network Channel
3.2. Installing from the command line
3.3. stsclient plug-ins

The Software Test Suite can be downloaded from the Software Test Suite Server channel on the Customer Support Portal, or by using the command line command from a system that is subscribed to this channel.

3.1. Downloading from the Red Hat Network Channel

Log in to the Customer Support Portal: https://access.redhat.com
Click on the Downloads tab, and select Channels under the Red Hat Enterprise Linux column within the menu.
The Full Software Chanel List view displays.
In the drop down box Filter by Product Channel: select Red Hat Software Test Suite.
In the drop down box Latest Version select All Versions from the list and then click the Filter button.
Important
Under Channel Name, click the plus (+) sign next to Red Hat Enterprise Linux Server product relevant to your installed operating system.
If you do not expand the Red Hat Enterprise Linux Server channel to reveal the Red Hat Software Test Suite channel, you may inadvertently download unnecessary packages.
Select the appropriate architecture from the options listed beside Red Hat Software Test Suite.
Ensure the system you wish to install the Software Test Suite on is subscribed to this channel by clicking on Subscribed Systems in the tab bar below the channel name at the top of the page. If your intended system does not appear on this page proceed to the next step. If it does, proceed to step 8.
Click on the Target Systems link in the tab bar below the channel title. Then select your system by checking the box beside it and click the Subscribe button. Click Confirm when prompted.
Click on Packages in the tab bar toward the top of the page.
Select the latest packages for download, then click the Download Packages button.

3.2. Installing from the command line

To install the Software Test Suite from the command line enter the command:

yum install stsclient stsclient-<type>-plugin

(Where <type> is one of the available stsclient plug-ins. See the next section for information about plug-ins.)

3.3. stsclient plug-ins

As of version 2.0, the Red Hat Software Test Suite client is plug-in-based. Users will need to install the appropriate plug-ins for their needs before running the client.

At the time of writing, there are five (5) plug-ins available to ISVs:

stsclient-cloud-plugin
stsclient-elf-plugin
stsclient-ftp-plugin
stsclient-packaging-plugin
stsclient-filesystem-plugin

Plug-ins are installed by using the standard yum command syntax (see Section 3.2, “Installing from the command line” for details).

Once installed, each plug-in will store a configuration file in the /etc/stsclient/pluginconf.d/ directory.

plug-ins can be enabled or disabled by toggling the enabled switch in the configuration file to on (1) or off (0):

[main]
enabled=1

Chapter 4. Running the Test Suite

The Software Test Suite is invoked using the stsclient command. Various options will control how the Software Test Suite performs.

Although all the information required by the stsclient can be provided on the command line, it is recommended that a plug-in configuration file be completed. This will simplify the commands that need to be passed to stsclient.

The following sections contain more details about the information stored in the configuration file used by the plug-ins.

Chapter 5. Using plug-ins

5.1. Generic Plugin Actions

5.2. Plugin-Specific Actions

5.2.1. The ELF plug-in
5.2.2. The Cloud plug-in
5.2.3. The FTP plug-in
5.2.4. The packaging plug-in
5.2.5. The filesystem plug-in

5.1. Generic Plugin Actions

While each plug-in differs slightly in its actions and requirements, there are some actions that are common to all plug-ins:

The ability to add logs to existing Bugzilla tickets with the --bug-id=<BUG_ID> switch. As well as the Bugzilla ID of the bug, this option also requires a set of valid Bugzilla credentials to be passed to the client. These credentials can be entered manually (--username=<USERNAME> --password=<PASSWORD>) or stored in the configuration file.
The ability to create a new Bugzilla ticket and attach logs to it automatically with the --new-bug switch. Again, this action requires valid Bugzilla credentials. It also requires the --arch=<ARCH> and --rel-version=<REL_VERSION> parameters to be set, either manually or in the configuration file.
The ability to provide an http proxy if the client is being run behind a proxy server using the either the -y <HTTP_PROXY> or --http-proxy=<HTTP_PROXY> option.

A full print-out of these options is included below:

options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -y HTTP_PROXY, --http-proxy=HTTP_PROXY
                        http proxy

  Attach logs to bug id:
    --bug-id=BUG_ID     Bugzilla id

  Attach logs to new bug:
    --new-bug           Create new bug
    --arch=ARCH         Architecture ("i386" or "x86_64" or "i686")
    --rel-version=REL_VERSION
                        Release version

  Bugzilla information:
    --username=USERNAME
                        Bugzilla username
    --password=PASSWORD
                        Bugzilla password
    --bugzilla-url=BZ_URL
                        Bugzilla URL, default is https://bugzilla.redhat.com/

5.2. Plugin-Specific Actions

5.2.1. The ELF plug-in

The ELF plug-in is used to extract information from applications built as Executable and Linkable Format files. It can be run against applications created by Independent Software Vendor (ISV) as well as internal Red Hat Enterprise Linux applications or libraries.

This plug-in, once installed, provides the following actions:

ELF plug-in options:
--appdir=APPDIR     folder containing application files
--installed-package=PACKAGE
                    package installed in system via rpm
--rpmdir=RPMDIR     folder containing rpms (for an application)
--rpmfile=RPMFILE   single rpm file

The options that are passed to the client when using the ELF plug-in will depend on the type of application being tested.

ELF plug-in options

--appdir: This option should be used to refer to a directory containing the application's files. Application files can include all files which are present when application gets installed/deployed.
When using this option it is recommended that all compressed files be extracted into corresponding directories.
--installed-package: This option should be used to identify the package, if it is already installed on the host machine.
--rpmdir: This option should be used to point to a directory containing the application's RPM files.
--rpmfile: This option should be used to point to a single RPM file.

Any logs created using the ELF plug-in should be attached to Bugzilla tickets logged under the Red Hat Software Certification product and the certification-rhel component. Refer to Section 7.1, “Submitting results using the test suite” for detailed information about this task.

5.2.2. The Cloud plug-in

The Cloud plug-in is used by Cloud ISVs to provide host information for image validation.

This plug-in does not add any new options to stsclient.

5.2.3. The FTP plug-in

The FTP plug-in should be installed if you intend to upload logs via secure FTP to FTP servers.

Once installed, the plug-in provides the following actions:

 ftp plug-in options:
    --ftp-url=FTP_URL   ftp url
    --ftp-username=FTP_USERNAME
                        username for ftp authentication
    --ftp-password=FTP_PASSWORD
                        password for ftp authentication

FTP plug-in options

--ftp-url: This option is used to provide the ftp server URL.
--ftp-username: This option is used to provide the ftp server user name.
--ftp-password: This option is used to provide the ftp server password.

The upload method used in the FTP plug-in will depend on whether the ELF plug-in or cloud plug-in is installed. Use the upload method appropriate to the plug-in installed.

If both the ELF and cloud plug-ins are installed, the log is attached as per the ELF plug-in settings.

5.2.4. The packaging plug-in

The packaging plug-in is used to collect packaging related information for an RPM, an SRPM, a specfile, or a directory containing a mix of these file types. The plug-in can also be run on an installed package.

 packaging plug-in options:
    --target <target>   what files or directories to analyze

--target: Specifies one of the following file types: RPM, SRPM, or specfile.
Specifies a directory containing one or more of the supported file types.
In both cases, the status of these files can be either installed on the system, or not yet installed.

Any logs created using the Packaging plug-in should be attached to Bugzilla tickets logged under the Red Hat Software Certification product and the certification-rhel component. Refer to Section 7.1, “Submitting results using the test suite” for detailed information about this task.

5.2.5. The filesystem plug-in

The filesystem plug-in is used to collect file system sanity-related information.

The plug-in does not provide any options, and runs file system checks if enabled.

Any logs created using the file system plug-in should be attached to Bugzilla tickets logged under the Red Hat Software Certification product and the certification-rhel component. Refer to Section 7.1, “Submitting results using the test suite” for detailed information about this task.

Chapter 6. Raising a Bugzilla Request

6.1. Raising a request using the Bugzilla interface
6.2. Using the Software Test Suite to raise a request

6.1. Raising a request using the Bugzilla interface

Log in to the Red Hat Bugzilla page. The following link will take you to a partially pre-filled Red Hat Software Certification bug form: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Software%20Certification. You may be required to log in with the credentials provided by your Partner Management Contact.
Ensure the new bug is filed against the Red Hat Software Certification product and the appropriate component:
- certification-cloud
- certification-rhel
Select other details in the form as appropriate.
Complete the 'Summary' and 'Description' fields with relevant details regarding the request. Ensure you include the application name and release version, your application's website, details of any package dependencies, the results of an rpm -qpi command and whether or not you are using SELinux policies.
Use the 'Attachment' button to add any relevant attachments.
Submit the completed report to obtain a request number.

6.2. Using the Software Test Suite to raise a request

The Software Test Suite client has the ability to raise a new Bugzilla request from the command line.

The command for this functionality requires four options to be included:

The trigger for a new Bugzilla creation: --new-bug.
The architecture that the binary is run on: --arch=<ARCH>. Replace <ARCH> with "i386", "x86_64" or "i686", whichever is appropriate.
The release of the application: --rel-version=<REL_VERSION>.

The complete command would be:

stsclient <PLUGIN_OPTS> --new-bug --arch <i386|x86_64|i686> --rel-version <REL_VERSION>

Chapter 7. Test Results

7.1. Submitting results using the test suite
7.2. Submitting results manually
7.3. Using a proxy server

Results collected by the Red Hat Software Test Suite are automatically packaged into the /tmp directory.

The results will be packaged as an rpm named sts-log-<IDSTRING>.noarch.rpm.

If you choose to submit results to Red Hat you can have the Test Suite upload them at the time of execution or you can submit them manually through Red Hat's Bugzilla account.

7.1. Submitting results using the test suite

To have the Software Test Suite transmit the results rpm to Red Hat when it is created, add the following options to the stsclient command:

stsclient <options> --username=<username> --password=<password> --bug-id=<#request_number>

Disclaimer

When you initiate an instance of the Software Test Suite in this manner you will be presented with the following disclaimer:

By using stsclient to upload your data to Red Hat, you consent to Red Hat's receipt, use and analysis of this data.

Type 'Y' to continue, 'N' to cancel.

Selecting 'N' at this point will exit the program.

If you do not have the Bugzilla details at the time you run the test process, ensure you rename the generic sts-log-<IDSTRING>.rpm file to match the following format:

<bugzilla-id>-<date>.noarch.rpm

Date Format

The date used in the file name must be in the YYYYMMDDHHMM format, which can be obtained in Linux systems with the command: date "+%Y%m%d%k%M"

If your Bugzilla username and password are stored in either the stsclient plug-in configuration file or the /etc/bugzilla.conf file the --username and --password options are not required in the above command. Refer to Section 3.3, “stsclient plug-ins” for information about creating or populating the configuration file.

File Size

Results files can only be uploaded to Bugzilla if they are less than 20Mb. For files larger than this limit, you might consider using the FTP transfer protocol to submit results. See Section 5.2.3, “The FTP plug-in” for more information about using FTP with stsclient.

7.2. Submitting results manually

The method outlined in Section 7.1, “Submitting results using the test suite” is the preferred way to upload results to Bugzilla.

The result log RPM can also be uploaded to Bugzilla manually after opening a request. Details on how to do this are in Section 6.1, “Raising a request using the Bugzilla interface”.

7.3. Using a proxy server

If you wish to use a proxy server in your submissions to Red Hat, you can supply the required details to the Software Test Suite by adding the --http-proxy option to the stsclient command:

The proxy details can also be saved in either the ELF or cloud plug-in configuration file to simplify the execute command. Refer to Section 3.3, “stsclient plug-ins” for information about creating or populating the configuration file.

Chapter 8. Submitting bug reports

Problems with the Software Test Suite client should also be submitted through Red Hat's Bugzilla account. Vendors reporting a bug should nominate the 'STSclient' component and complete the Bugzilla form as appropriate.

Important

If you are submitting a bug report rather than raising a request for testing, please perform a search to ensure your bug has not already been reported.

User-specific process overviews

Red Hat Software Test Suite users can refer to the processes below for a high-level overview of the steps required to utilize the Suite in their specific circumstances.

Find the section that most closely reflects your situation and review the steps within that section:

Section A.1, “I am an ISV Partner and have my application packaged as an RPM.”
Section A.2, “I am an ISV Partner and have my application installed on my system using an RPM package.”
Section A.3, “I am an ISV Partner and my application is in a non-RPM format.”
Section A.4, “I am a Red Hat Certified Cloud Provider and want to validate my cloud image”

A.1. I am an ISV Partner and have my application packaged as an RPM.

Check that your Bugzilla credentials allow for filing bugs against the Red Hat Software Certification Product and appropriate component.
Download stsclient-elf-plug-in and corresponding dependencies from the Customer Support Portal. If you intend to transfer test results to Red Hat using the secure FTP protocol, you should download the stsclient-ftp-plug-in as well.
Note that registering to the Customer Support Portal and using yum to install stsclient-elf-plug-in and/or stsclient-ftp-plug-in will automatically install all dependencies.
The following information will be required by the stsclient application;
- The path to application rpm file or to the directory that contains the application, if it is packaged in multiple rpm files (--rpmfile or --rpmdir).
- Your Bugzilla account information (--username and --password).
- If you have a Bugzilla ticket open for this testing event; the Bugzilla ID number of the ticket (--bug_id).
  If you have not yet raised a Bugzilla ticket for this event; the architecture your application runs on (--arch) and the release version of Red Hat Enterprise Linux it was built for (--rel_version). These two pieces of information along with --new-bug option will create a request for you.
- If you use a proxy server; the proxy server address (--HTTP_PROXY).
- If you intend to use FTP to transfer your results to Red Hat; you will need the FTP configuration details (--ftp-url, --ftp-username and ftp-password).
Run the tool against the rpm package(s) using the appropriate combination of options from those listed above.

A.2. I am an ISV Partner and have my application installed on my system using an RPM package.

Check that your Bugzilla credentials allow for filing bugs against the Red Hat Software Certification Product and appropriate component.
Download stsclient-elf-plug-in and corresponding dependencies from the Customer Support Portal. If you intend to transfer test results to Red Hat using the secure FTP protocol, you should download the stsclient-ftp-plug-in as well.
Note that registering to the Customer Support Portal and using yum to install stsclient-elf-plug-in and/or stsclient-ftp-plug-in will automatically install all dependencies.
The following information will be required by the stsclient application;
- The package name (--installed-package).
- Your Bugzilla account information (--username and --password).
- If you have a Bugzilla ticket open for this testing event; the Bugzilla ID number of the ticket (--bug_id).
  If you have not yet raised a Bugzilla ticket for this event; the architecture your application runs on (--arch) and the release version of Red Hat Enterprise Linux it was built for (--rel_version). These two pieces of information along with --new-bug option will create a request for you.
- If you use a proxy server; the proxy server address (--HTTP_PROXY).
- If you intend to use FTP to transfer your results to Red Hat; you will need the FTP configuration details (--ftp-url, --ftp-username and ftp-password).
Run the tool against the application using the appropriate combination of options from those listed above.

A.3. I am an ISV Partner and my application is in a non-RPM format.

Check that your Bugzilla credentials allow for filing bugs against the Red Hat Software Certification Product and appropriate component.
Download stsclient-elf-plug-in and corresponding dependencies from the Customer Support Portal. If you intend to transfer test results to Red Hat using the secure FTP protocol, you should download the stsclient-ftp-plug-in as well.
Note that registering to the Customer Support Portal and using yum to install stsclient-elf-plug-in and/or stsclient-ftp-plug-in will automatically install all dependencies.
The following information will be required by the stsclient application;
- The directory of the application files (--appdir).
- Your Bugzilla account information (--username and --password).
- If you have a Bugzilla ticket open for this testing event; the Bugzilla ID number of the ticket (--bug_id).
  If you have not yet raised a Bugzilla ticket for this event; the architecture your application runs on (--arch) and the release version of Red Hat Enterprise Linux it was built for (--rel_version). These two pieces of information along with --new-bug option will create a request for you.
- If you use a proxy server; the proxy server address (--HTTP_PROXY).
- If you intend to use FTP to transfer your results to Red Hat; you will need the FTP configuration details (--ftp-url, --ftp-username and ftp-password).
Run the tool against the application using the appropriate combination of options from those listed above.

A.4. I am a Red Hat Certified Cloud Provider and want to validate my cloud image

Check that your Bugzilla credentials allow for filing bugs against the Red Hat Software Certification Product and appropriate component.
Download stsclient-cloud-plug-in and corresponding dependencies from the Customer Support Portal. If you intend to transfer test results to Red Hat using the secure FTP protocol, you should download the stsclient-ftp-plug-in as well.
Note that registering to the Customer Support Portal and using yum to install stsclient-cloud-plug-in and/or stsclient-ftp-plug-in will automatically install all dependencies.
The following information will be required by the stsclient application;
- Your Bugzilla account information (--username and --password).
- If you have a Bugzilla ticket open for this testing event; the Bugzilla ID number of the ticket (--bug_id).
  If you have not yet raised a Bugzilla ticket for this event; the architecture your application runs on (--arch) and the release version of Red Hat Enterprise Linux it was built for (--rel_version). These two pieces of information along with --new-bug option will create a request for you.
- If you use a proxy server; the proxy server address (--HTTP_PROXY).
- If you intend to use FTP to transfer your results to Red Hat; you will need the FTP configuration details (--ftp-url, --ftp-username and ftp-password).
Run the tool against the image using the appropriate combination of options from those listed above.

Revision History

Revision History

Revision 2.0-3.400

2013-10-31

Rüdiger Landmann

Rebuild with publican 4.0.0

Revision 2.0-3

Thu Sep 06 2012

Jared Morgan

Removed RHN references throughout the guide, and replaced with Customer Support Portal references.

Revision 2.0-1

Thu Sep 06 2012

Jared Morgan

Added information about two plug-ins: stsclient-packaging-plugin and stsclient-filesystem-plugin.

Revision 1-0.6

Wed Aug 24 2011

Scott Mumford

Incorporated further SME feedback.

Corrected xi:include order error.

Revision 1-0.4

Mon Aug 22 2011

Scott Mumford

Updated with SME feedback.

Revision 1-0.3

Tue Aug 16 2011

Scott Mumford

Slight restructure.

General edit.

Revision 1-0.2

Mon Aug 15 2011

Scott Mumford

Restructured book to replace old CLI options with new plug-in options.

General upgrade/update of content.

Revision 1-0.1

Mon Aug 8 2011

Scott Mumford

Initial creation of book by publican

Index

F

feedback

contact information for this manual, We Need Feedback!

H

help

getting help, Do You Need Help?