Red Hat OpenStack Administration I: Core Operations for Domain Operators
Run the lab command from workstation to prepare your environment before each hands-on exercise, and again to clean up after an exercise.
Each hands-on exercise has a unique name within a course.
The exercise is prepended with lab- as its file name in /usr/local/lib.
For example, the instances-cli exercise has the file name /usr/local/lib/lab-instances-cli.
To list the available exercises, use tab completion in the lab command:
[student@workstation ~]$labTabTabadminister-users deploy-overcloud-lab prep-deploy-ips stacks-autoscale analyze-metrics instances-cli prep-deploy-router stacks-deploy assign-roles manage-interfaces public-instance-deploy verify-overcloud
There are two types of exercises. The first type, a guided exercise, is a practice exercise which follows a course narrative. If a narrative is followed by a quiz, this usually indicates that the topic did not have an achievable practice exercise. The second type, an end-of-chapter lab, is a gradable exercise to help verify your learning. When a course includes a comprehensive review, the review exercises are structured as gradable labs. The syntax for running an exercise script is:
[student@workstation ~]$ lab exercise actionThe action is a choice of start, grade, or finish.
All exercises support start and finish.
Only end-of-chapter labs and comprehensive review labs support grade.
Older courses might still use setup and cleanup instead of the current start and finish actions.
- start
Formerly
setup. A script's start logic verifies the resources required to begin an exercise. This can include configuring settings, creating resources, checking prerequisite services, and verifying necessary outcomes from previous exercises. Exercise start logic allows you to perform any exercise at any time, even if prerequisite exercises have not been performed.- grade
End-of-chapter labs help verify what you have learned, after practicing with earlier guided exercises. The grade action directs the
labcommand to display a list of grading criteria, with aPASSorFAILstatus for each. To achieve aPASSstatus for all criteria, fix the failures and re-run the grade action.- finish
Formerly
cleanup. A script's finish logic deletes exercise resources which are no longer necessary. Cleanup logic allows you to repeatedly perform an exercise, and benefits course performance by ensuring that unneeded objects release their resources.
Exercise scripts do not exist on workstation until each is first run.
When you run the lab command with a valid exercise and action, the script named lab-exercise is downloaded from the classroom server content share to /usr/local/lib on workstation.
The lab command creates two log files in /var/tmp/labs, plus the directory if it does not exist.
One file, named exercise, captures standard output messages which normally display on your terminal.
The other file, named exercise.err, captures error messages.
[student@workstation ~]$ls -l /usr/local/lib-rwxr-xr-x. 1 root root 4131 May 9 23:38 lab-instances-cli -rwxr-xr-x. 1 root root 93461 May 9 23:38 labtool.cl110.shlib -rwxr-xr-x. 1 root root 10372 May 9 23:38 labtool.shlib [student@workstation ~]$ls -l /var/tmp/labs-rw-r--r--. 1 root root 113 May 9 23:38 instances-cli -rw-r--r--. 1 root root 113 May 9 23:38 instances-cli.err
Note
Scripts download from the http://content.example.com/courses/course/release/grading-scripts share, but only if the script does not yet exist on workstation.
When you need to download a script again, such as when a script on the share is modified, manually delete the current exercise script from /usr/local/lib on workstation, then run the lab command for the exercise again.
The newer exercise script then downloads from the grading-scripts share.
To delete all current exercise scripts on workstation, use the lab command's --refresh option.
A refresh deletes all scripts in /usr/local/lib but does not delete the log files.
[student@workstation ~]$lab --refresh[student@workstation ~]$ls -l /usr/local/lib[student@workstation ~]$ls -l /var/tmp/labs-rw-r--r--. 1 root root 113 May 9 23:38 instances-cli -rw-r--r--. 1 root root 113 May 9 23:38 instances-cli.err
Exercise scripts send output to log files, even when the scripts are successful. Step header text is added between steps and additional date and time headers are added at the start of each script run. The exercise log normally contains messages which indicate successful completion of command steps. Therefore, the exercise output log is useful for observing messages that are expected if no problems occur, but offers no additional help when failures occur.
Instead, the exercise error log is more useful for troubleshooting. Even when the scripts succeed, messages are still sent to the exercise error log. For example, a script that verifies that an object already exists before attempting to create it should cause an object not found message when the object does not exist yet. In this scenario, that message is expected and does not indicate a failure. Actual failure messages are typically more verbose, and experienced system administrators should recognize common log message entries.
Although exercise scripts are always run from workstation, they perform tasks on other systems in the course environment.
Many course environments, including OpenStack and OpenShift, use a command-line interface (CLI) invoked from workstation to communicate with server systems using API calls.
Because script actions typically distribute tasks to multiple systems, additional troubleshooting is necessary to determine where a failed task occurred.
Log in to those other systems and use Linux diagnostic skills to read local system log files and determine the root cause of the lab script failure.
