When we think of technology, we think of progress, we think of new possibilities, we think of simplifying life – all with the help of technology. Red Hat Ansible automation platform is front and center – it’s an industry-standard automation technology that eliminates boilerplate tasks for IT administrators in a straightforward manner. For IBM Power users, updating a Virtual I/O Server (VIOS) is a tedious task when done manually. It is a multi-step process to search for fixes, download them, and eventually use them to update the VIOS.
To address this challenge, we came up with an idea of automating the entire process of downloading fixes and updating a VIOS machine using Red Hat Ansible. This article breaks down the intricacies of the process and provides insights on how to leverage it for streamlining your data center operational procedures. Happy automating!
Prerequisites
To make the most out of this tutorial, it is beneficial for users to possess basic proficiency in Ansible and it's working.
System requirements:
- Python: Version 3.0.0 or later.
- VIOS: Version 2.2.5.0 or later.
- Ensure cURL is installed on the system.
- Ensure sufficient disk space in the provided directory, for downloading the fix pack.
Estimated time to complete:
It takes around 40 minutes to read and automate VIOS fix.
Fix Central and Electronic Fix Delivery
Fix Central serves as a platform providing fixes and updates for system software, hardware, and operating systems. Notably, it also features APIs that facilitate the automated downloading of fixes for various IBM products. The cloud application efficiently handles 'events' transmitted from the client machine and triggers calls to Electronic Fix Delivery (EFD) to request the necessary fixes. Any fixes stored in EFD become accessible through the cloud API. Requests are posted to the cloud as asynchronous (non-blocking) events in JSON format. Within each event, the caller identifies unique information that represents the 'asset' sending the request. This 'asset' can take the form of a hardware instance (machine type, serial number, etc.) or a software asset (PID, unique ID, etc.). Importantly, events and responses transmitted from an asset are exclusively visible to that particular asset.
How does it work?
Given the extensive exchange of information required, events are sent to the cloud using the HTTP POST method with distinct JSON payloads corresponding to the respective stage in the process.
There are three stages (or events):
- Software update.
- Last contact.
- Confirm response.
Software update
In this stage, requirements are communicated to EFD (Either list of fixes available for the machine, or URLs of fixes that we intend to download). A JSON Payload is sent in the body of an HTTP POST request, containing all the essential information for EFD to process the request. This sets the stage for EFD to provide the needed information in the subsequent phase of the process.
Payload preview:
The ‘request_type’ field within the payload's event body assumes different values (e.g., specific_fix, all_fixes, preview_specific_fix, preview_all_fixes), depending on our objectives.
Our module makes use of the following request types:
- preview_all_fixes: Used to list available fix packs, to be installed on a machine. In this case, only metadata is returned for each of the fix that is available, no file link is returned.
- specific_fix: Used when ordering a specific fix pack. In this case, ‘updateIds’ also needs to be specified for identification. File links are returned, and the ‘expand_groups’ field needs to be set true for group fixes.
Note: When entitled fixes are requested from EFD, credentials are required. EFD supports three types of credentials 1. IBM id, 2. Machine type serial number (MTSN) 3. Key.
Our module uses MTSN for authentication.
Last contact
Following up on the last request (order_software) that was sent, another payload is sent at this stage to get the required information. If the information is ready, a response containing the required details is received. Sometimes, the requested fix pack might contain numerous files, in such cases, EFD may require more time to process the request and produce the required response. To handle this situation, the last_contact request is sent at 10 second intervals, eleven times, totalling about 120 seconds. If the response is still unavailable, then it is assumed that the response is not available, and the request is timed out.
How will the server identify which request is being followed upon?
A unique field in the event body called ‘enable_response_detailed_filter’ contains event id of the previous request (order_software) so that the identification becomes possible. The payload also contains a field ‘enable_response_detail’, which is set to true, signifying the need for a filtered response i.e. Following up on an already sent request.
Payload preview:
Response:
In response to the above payload, EFD returns the list of available fixes for the system from which the request was sent, based on the system’s current version.
In our instance, the system operated on OS version "3.1.4.0," and Fix Central listed these three available fixes at the time of composing this article.
Confirm response
Now, that we have obtained the information (List of available fixes, or URL), a third payload is sent to acknowledge EFD portal, that the information has been received, and the connection is no longer required. With this, the connection is closed.
Payload preview:
The following diagram depicts how each component seamlessly comes together to complete the entire process.
The whole process: Summed up
How to use the module and playbook to automate the process of downloading fixes and updating for your VIOS machine.
Use fix_download module, to automate the following tasks:
- List fixes: Obtain a list of fix packs available for your machine (based on the system’s current version)
- Download a fix: Download a specific fix or fix pack available on Fix Central.
Before moving to either of the following tasks, you need to have Ansible properly set up on your environment and have the latest version of VIOS collection (power_vios 1.4.0 in this case).
Listing fixes for your system
Use the following playbook to list all the available fixes for your machine.
Playbook:
---
- name: "Demo for listing fixes available for the system"
hosts: "{{ hosts_val }}"
gather_facts: no
vars:
hosts_val: all # Provide the hosts present in the inventory file for which you want to list the available fixes.
tasks:
- name: List fixes for the system # This task will list all the fixes that are available for a particular machine
fix_download:
action: "list"
register: result
- debug: var=result.List_of_Fixes
Downloading a particular fix
Efficiently download a specific fix or fix pack from Fix Central. To achieve this, you'll need the ID of the desired fix pack (e.g., VIOS_FP_3.1.4.10) and specify an empty directory for downloading. The ‘clean_directory’ attribute, when set to true, will conveniently empty the directory through Ansible.
Playbook:
---
- name: "Demo for downloading fixes for the system"
hosts: "{{ hosts_val }}"
gather_facts: no
vars:
hosts_val: all # Provide the hosts present in the inventory file for which you want to download the fix.
dir: "/home/padmin/update/VIOS_FP_3.1.4.10" # Location at which the fix would be downloaded (This directory needs to be empty)
fix_id_val: "VIOS_FP_3.1.4.10" # Id of the fix that you want to download
tasks:
- name: Download a fix/file # This task will be performing the task of downloading the fix from EFD
fix_download:
action: "download"
fix_id: "{{ fix_id_val }}"
directory: "{{ dir }}"
clean_directory: True # If set true, the provided directory will be emptied before downloading the fixes
End-to-end updation: Download and update
Now that the fix has been downloaded, leverage the updateios module (also available in our power_vios collection) to automate the system update process. Thus, enabling automating the whole process of downloading the fix from Fix Central and updating the system.
Playbook:
---
- name: "Demo for end-to-end updation: download and update"
hosts: "{{ hosts_val }}"
gather_facts: no
vars:
hosts_val: all # Provide the hosts present in the inventory file for which you want to download the fix and perform update.
dir: "/home/padmin/update/VIOS_FP_3.1.4.10" # Location at which the fix would be downloaded and used from during update (This directory needs to be empty)
fix_id_val: "VIOS_FP_3.1.4.10" # Id of the fix that you want to download.
tasks:
- name: List fixes for the system # This task will list all the fixes that are available for a particular machine
fix_download:
action: "list"
register: result
- debug: var=result.List_of_Fixes
- name: Download a fix/file # This task will be performing the task of downloading the fix from EFD
fix_download:
action: "download"
fix_id: "{{ fix_id_val }}"
directory: "{{ dir }}"
clean_directory: True # If the provided directory is not empty, it will be emptied before downloading the fixes
- name: Update the VIOS to the latest level, where the updates are present at a particular location. # Task for updation of the machine
updateios:
action: update
device: "{{ dir }}"
Future scope and conclusion
The module is designed with generality in mind, making it easily adaptable for use by other IBM Power collections with minimal adjustments.
Automation presents numerous opportunities to simplify day-to-day tasks and enhance productivity.
Exciting capabilities are planned for the future, so stay tuned for updates in this space! Your suggestions and feedback are valuable to us, and you can provide them in our GitHub repository or in the following space.
Refer to the following links to avail our collection.