diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md index 2b4720ec4..0adaa4528 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md @@ -11,7 +11,7 @@ - [Step 2 - Access the Visual Studio Code Web UI](#step-2---access-the-visual-studio-code-web-ui) - [Step 3 - Open a Terminal Session](#step-3---open-a-terminal-session) - [Step 4 - Access the Satellite Web UI](#step-4---access-the-satellite-web-ui) - - [Step 5 - Access the RHEL Web Console](#step-5---access-the-centos-web-console) + - [Step 5 - Access the Web Console](#step-5---access-the-web-console) - [Step 6 - Challenge Labs](#step-6---challenge-labs) - [Conclusion](#conclusion) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/README.md index 3e6bca4a4..0fa8f219e 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/README.md @@ -10,7 +10,7 @@ - [Step 1 - Set Instance Tags](#step-1---set-instance-tags) - [Step 2 - Update Ansible Inventory](#step-2---update-ansible-inventory) - [Step 3 - Install Three Tier Application](#step-3---install-three-tier-application) - - [Step 4 - Smoke Test Three Tier Application](#step-4---open-a-terminal-session) + - [Step 4 - Smoke Test Three Tier Application](#step-4---smoke-test-three-tier-application) - [Conclusion](#conclusion) ## Objectives @@ -21,7 +21,7 @@ ### Three Tier App -This use-case will focus on conversion from CentOS (though this could be another RHEL derivitive) to RHEL while maintaining a 3 tier application stack (do no harm). We will utilize an additional project in Ansible Automation Platform, "Three Tier App / Prod", which will allow us to install a three tier application stack, consisting of HAProxy, Tomcat, and PostgreSQL, across the three CentOS nodes. Additionally, the project also provides a means to test/verify functionality of the application components, which we will perform before and after CentOS to RHEL conversions. +This use-case will focus on conversion from CentOS (though this could be another RHEL derivative) to RHEL while maintaining a 3 tier application stack (do no harm). We will utilize an additional project in Ansible Automation Platform, "Three Tier App / Prod", which will allow us to install a three tier application stack, consisting of HAProxy, Tomcat, and PostgreSQL, across the three CentOS nodes. Additionally, the project also provides a means to test/verify functionality of the application components, which we will perform before and after CentOS to RHEL conversions. | Role | Inventory name | | ------------------------------------------| ---------------| @@ -58,11 +58,11 @@ This use-case will focus on conversion from CentOS (though this could be another ![Expanded job template variables](images/set_instance_tags_04.png) -- Note the **group_tag_map**...each node is being mapped to a group name which corresponds to the particular application tier role that the node is to serve. Looking at the Ansible playbook that corresonds to this job template: +- Note the **group_tag_map**...each node is being mapped to a group name which corresponds to the particular application tier role that the node is to serve. Looking at the Ansible playbook that corresponds to this job template: ![Ansible playbook for group tags](images/set_instance_tags_06.png) -- We can see that the **group_tag_map** dictionary is looped through, selecting a particular instace via the *resource: "{{ host_ec2_instance_id[item.key] }}"* filter and then setting the "AnsibleGroup" tag via *AnsibleGroup: "{{ item.value }}"* +- We can see that the **group_tag_map** dictionary is looped through, selecting a particular instance via the *resource: "{{ host_ec2_instance_id[item.key] }}"* filter and then setting the "AnsibleGroup" tag via *AnsibleGroup: "{{ item.value }}"* - Additionally, the **app_stack_name** tag is set to designate that each node is a member of the same application stack. @@ -94,13 +94,13 @@ This use-case will focus on conversion from CentOS (though this could be another ![Controller inventories keyed_groups](images/update_controller_inventory_inventory_filter.png) -- Looking at the Source variables, first let's look at `filters` and `hostnames`. The `filters` section will allow definining which instances should be selected for inclusion within the given inventory. In this case, the tags `ContentView`, `Environment`, `Student`, and `guid` will be utilized...all instances with tags matching the current values defined for each tag, will be selected. The `hostnames` sections allows defining how names of filtered resources will be defined in the inventory. In this case, the value currently defined with tag `NodeName` will be utilized for the name populated within the `CentOS7 Development` inventory. +- Looking at the Source variables, first let's look at `filters` and `hostnames`. The `filters` section will allow defining which instances should be selected for inclusion within the given inventory. In this case, the tags `ContentView`, `Environment`, `Student`, and `guid` will be utilized...all instances with tags matching the current values defined for each tag, will be selected. The `hostnames` sections allows defining how names of filtered resources will be defined in the inventory. In this case, the value currently defined with tag `NodeName` will be utilized for the name populated within the `CentOS7 Development` inventory. ![Controller inventories keyed_groups](images/update_controller_inventory_05.png) - Scroll down the source variables section until you see "keyed_groups". [Keyed groups](https://docs.ansible.com/ansible/latest/plugins/inventory.html#:~:text=with%20the%20constructed-,keyed_groups,-option.%20The%20option) are where you can define dynamic inventory groups based on instance tags. In this case, given the instances that are selected via the filters in the previous section, if any of these instances are currently tagged with "app_stack_name" and "AnsibleGroup" tags, then it will create an inventory group with the name beginning with the value assigned to the "app_stack_name" tag, an "_" (underscore) and then the value assigned to the "AnsibleGroup" tag...so in this case, if the "app_stack_name" tag is currently set to `stack02` and the "AnsibleGroup" tag is set to `appdbs`, then the inventory group `stack02_appdbs` will be created (or confirmed if already existing) and that instance will be assigned to the `stack02_appdbs` inventory group. -- Click on "Done" in the Source variables exapanded view. +- Click on "Done" in the Source variables expanded view. ![Controller inventories group](images/update_controller_inventory_sync.png) @@ -149,33 +149,6 @@ This use-case will focus on conversion from CentOS (though this could be another ### Step 3 - Install Three Tier Application -- In the AAP Web UI, navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts. - - ![Job templates on AAP Web UI with EC2 filter](images/aap_templates_ec2_filter.png) - -- In the filter box, enter `EC2` and then click the magnifying glass. This will bring up a list of job templates specific to AWS/EC2 automation: - - ![EC2 Job templates Instance Action](images/aap_templates_ec2_instance_action.png) - -- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **EC2 / Instance action**: - - ![EC2 Instance Action Other](images/ec2_instance_action_other.png) - -- For the `Launch | EC2 / Instance action - Other prompts` dialog, click **Next**. - - ![EC2 Instance Action Survey](images/ec2_instance_action_survey.png) - -- On the `Launch | EC2 / Instance action - Survey` dialog: - - For `Select EC2 instance action` select "start". - - For `Select OS target` select "CentOS7". - - For `Select Environment stage` select "Dev". - - Then, click **Next**. - - ![EC2 Instance Action Launch](images/ec2_instance_action_launch.png) - -- On the `Launch | EC2 / Instance action - Preview` dialog, review and then click **Launch**. Once the `EC2 / Instance action` job has completed, our CentOS7 instances will be started (or confirmed as started if they are already up and running) and available for installing the three tier application stack. - - In the AAP Web UI, navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates. ![Job templates on AAP Web UI with EC2 filter](images/aap_templates.png) @@ -240,7 +213,7 @@ This should take ~15 seconds to complete. In this exercise, we learned about how to set instance tags to assist with identifying instances. We then turned to looking into how Ansible Automation Platform dynamic inventory sources can be utilized to generate various host groups with a given inventory. We followed that with performing an automated installation of an example three tier application stack. Finally, we verified the three tier application stack functionality via an automated application smoke test. -Use the link below to move on the the next exercise. +Use the link below to move on the next exercise. --- diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_ec2_filter.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_ec2_filter.png deleted file mode 100644 index 7aec5c232..000000000 Binary files a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_ec2_filter.png and /dev/null differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_ec2_instance_action.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_ec2_instance_action.png deleted file mode 100644 index 993a3b7a5..000000000 Binary files a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_ec2_instance_action.png and /dev/null differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_launch.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_launch.png deleted file mode 100644 index 44db7f6e8..000000000 Binary files a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_launch.png and /dev/null differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_other.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_other.png deleted file mode 100644 index accaff12c..000000000 Binary files a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_other.png and /dev/null differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_survey.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_survey.png deleted file mode 100644 index 1599a4891..000000000 Binary files a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/ec2_instance_action_survey.png and /dev/null differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/README.md index 82c1b2d38..7a2a28aed 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/README.md @@ -2,19 +2,19 @@ ## Table of Contents -- [Workshop Exercise - Run Pre-conversion Analysis Jobs](#workshop-exercise---run-pre-conversion-jobs) +- [Workshop Exercise - Run Pre-conversion Analysis Jobs](#workshop-exercise---run-pre-conversion-analysis-jobs) - [Table of Contents](#table-of-contents) - [Objectives](#objectives) - [Guide](#guide) - [Step 1 - CentOS Conversion Automation Workflow](#step-1---centos-conversion-automation-workflow) - - [Analysis](#analysis) + - [Analyze](#analyze) - [Convert](#convert) - [Commit](#commit) - [Let's Get Started](#lets-get-started) - [Step 2 - Patch OS to latest package versions](#step-2---patch-os-to-latest-package-versions) - [Step 3 - Change Content Source for Content Host](#step-3---change-content-source-for-content-host) - [Step 4 - Use AAP to Launch an Analysis Playbook Job](#step-4---use-aap-to-launch-an-analysis-playbook-job) - - [Step 5 - Review the Playbook Job Output](#step-5---review-the-playbook-job-output) + - [Step 5 - Review the Workflow Job Output](#step-5---review-the-workflow-job-output) - [Step 6 - Challenge Lab: Analysis Playbook](#step-6---challenge-lab-analysis-playbook) - [Conclusion](#conclusion) @@ -28,7 +28,7 @@ ### Step 1 - CentOS Conversion Automation Workflow -Red Hat provides the Convert2RHEL utility, a tool to convert RHEL-like systems to their RHEL counterparts. The [Convert2RHEL documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/converting_from_an_rpm-based_linux_distribution_to_rhel/index) guides users on how to utilize the Convert2RHEL utility to manually convert a RHEL host. This is fine if there only a few CentOS hosts to convert, but what if you are a large enterprise with tens, hundreds, or even thousands of CentOS hosts? The manual process does not scale. Using automation, the end-to-end process for converting a RHEL host is reduced to a matter of days and the total downtime required for the actual conversion is measured in hours or less. +Red Hat provides the Convert2RHEL utility, a tool to convert RHEL-like systems to their RHEL counterparts. The [Convert2RHEL documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/converting_from_a_linux_distribution_to_rhel_using_the_convert2rhel_utility/index) guides users on how to utilize the Convert2RHEL utility to manually convert a RHEL host. This is fine if there are only a few CentOS hosts to convert, but what if you are a large enterprise with tens, hundreds, or even thousands of CentOS hosts? The manual process does not scale. Using automation, the end-to-end process for converting a RHEL host is reduced to a matter of days and the total downtime required for the actual conversion is measured in hours or less. Our CentOS conversion automation approach follows a workflow with three phases: @@ -38,7 +38,7 @@ Our CentOS conversion automation approach follows a workflow with three phases: > > The ![arrow pointing down at server](images/playbook_icon.svg) icon indicates workflow steps that are automated by Ansible playbooks. -#### Analysis +#### Analyze During the analysis phase, theoretically, no changes should be made to the system, other than the installation of the `Convert2RHEL` utility. However, to err on the side of caution, a first playbook is executed to create a snapshot that can be used for rolling back if any unforeseen issues corrupt the system. After the snapshot is created, the analysis playbook is executed, where the `Convert2RHEL` utility scans the host for issues or blockers that may prevent a successful conversion and then generates a report listing any potential risks found. The report also includes recommended actions that should be followed to reduce the likelihood of the reported issues impacting the conversion. If any recommended remediation actions are performed, the analysis workflow should be run again (snapshot/analyze) to verify the risks are resolved. This iteration continues until everyone reviewing the report is comfortable that any remaining findings are acceptable. @@ -53,7 +53,7 @@ After the analysis phase is complete and the report indicates acceptable risk, a #### Commit -If there are any application impacts discovered that can't be easily corrected within the scheduled maintenance window, the decision can be made to undo the conversion by rolling back the snapshot. This will revert all changes and return the host back to the previous CentOS version. However, if there are no issues found, the commit phase begins. During the commit phase, the host can be returned to normal operation while keeping the snapshot just in case any issues are uncovered later. +If there are any application impacts discovered that can't be easily corrected within the scheduled maintenance window, the decision can be made to undo the conversion by rolling back the snapshot. This will revert all changes and return the host back to the previous CentOS state. However, if there are no issues found, the commit phase begins. During the commit phase, the host can be returned to normal operation while keeping the snapshot just in case any issues are uncovered later. > **ⓘ** This is LVM specific: However, while the snapshots are kept, regular disk writes to volume groups will continue to consume the free space allocated to the snapshots. The amount of time this takes will depend on the amount of free space initially available and the volume of write i/o activity to the volume groups. Before the snapshot space is exhausted, the snapshots must be deleted and then there is no turning back. Once comfortable with the converted host, the commit playbook should be executed to delete the snapshot. The CentOS conversion to RHEL is complete. @@ -104,7 +104,7 @@ One of the prerequisites for successful Convert2RHEL OS conversions is that the ### Step 3 - Change Content Source for Content Host -Before we start the pre-conversion OS analysis, we need to change the Satellite content source for our CentOS content hosts. With the release of Convert2RHEL 2.x, providing content registration details as part of the variables supplied are no longer utilized. Instead, the system to be converted should be registered to a content view that provides access to package repositories for both the current version of installed operating system, as well as access to package repositories for the target version of RHEL that is being converted to. In addition, access to the Convert2RHEL related package repositories should be included. +Before we start the pre-conversion OS analysis, we need to change the Satellite content source for our CentOS content hosts. The system to be converted should be registered to a content view that provides access to package repositories for both the current version of installed operating system, as well as access to package repositories for the target version of RHEL that is being converted to. In addition, access to the Convert2RHEL related package repositories should be included. If you would like to review the content view configuration that we will be utilizing as part of the conversion process, switch to the browser tab where you are logged in to Satellite. @@ -114,7 +114,7 @@ If you would like to review the content view configuration that we will be utili > **Note** > - > A composite content view in Satellite is a content view that is composed of other composite views, typically multiples of content views. + > A composite content view in Satellite is a content view that is composed of other content views, typically multiples of content views. - Click on the `CentOS7_to_RHEL7` composite content view. @@ -188,7 +188,7 @@ The first step in converting our three tier app hosts will be executing the anal > **Note** > - > While we did change the `CentOS7_to_RHEL7_Dev` lifecycle environment that the CentOS nodes are assigned to in Satellite, this was only for selecting the requisite software packge repositories for the conversion process. We are still utilizing the `CentOS_Dev` inventory group in the Ansible Automation Platform inventory for specifying the proper instances to launch conversion automation against. + > While we did change the `CentOS7_to_RHEL7_Dev` lifecycle environment that the CentOS nodes are assigned to in Satellite, this was only for selecting the requisite software package repositories for the conversion process. We are still utilizing the `CentOS_Dev` inventory group in the Ansible Automation Platform inventory for specifying the proper instances to launch conversion automation against. ![Analysis job preview on AAP Web UI](images/analysis_preview.png) @@ -202,7 +202,7 @@ After launching the analysis workflow job, the AAP Web UI will navigate automati - While the workflow job is running, you can monitor progress by clicking on an individual workflow job node and then click on the "Output" tab within the individual job run. The job output will scroll automatically as task results are streamed to the bottom of job output shown in the AAP Web UI. -- The analysis workflow will run the Convert2RHEL pre-conversion system analysis. Click on the `OS / Pre-conversion Analysis` job node and then click on the "Output" tab to follow the job outout log. This will take about nine to ten minutes to complete. When it is done, you can find a "PLAY RECAP" at the end of the job output showing the success or failure status for the playbook runs executed on each host. A status of "failed=0" indicates a successful playbook run. Scroll to the bottom of the job output and you should see that your job summary looks like this example: +- The analysis workflow will run the Convert2RHEL pre-conversion system analysis. Click on the `OS / Pre-conversion Analysis` job node and then click on the "Output" tab to follow the job output log. This will take about nine to ten minutes to complete. When it is done, you can find a "PLAY RECAP" at the end of the job output showing the success or failure status for the playbook runs executed on each host. A status of "failed=0" indicates a successful playbook run. Scroll to the bottom of the job output and you should see that your job summary looks like this example: ![Analysis job "PLAY RECAP" as seen at the end of the job output](images/analysis_job_recap.png) @@ -232,7 +232,7 @@ Can you find the upstream source repo and playbook code? - With the new tab opened and the `redhat-partner-tech/automated-satellite` repo displayed, on the left side of the browser, click the drop down for the branch selection where `main` is displayed. Click the `aap2-rhdp-prod` branch to select this branch for viewing. -- Go back to the AAP Web UI and now navigate to Resources > Templates > CONVERT2RHEL / 01 Analysis. Under the Details tab, you will see that this is a workflow template. In order to view the individual jobs within the workflow, click on the tab named "Visualizer". Once, the workflow visualization is displayed, hover the mouse pointer over the node named "OS / Pre-conversion Analysis". We can see that the node name in this workflow is the same as the resource used, in this case, the name of the job template "OS / Pre-conversion Analysis". +- Go back to the AAP Web UI and now navigate to Resources > Templates > CONVERT2RHEL / 01 Analysis. Under the Details tab, you will see that this is a workflow template. In order to view the individual jobs within the workflow, click on the tab named "Visualizer". Once the workflow visualization is displayed, hover the mouse pointer over the node named "OS / Pre-conversion Analysis". We can see that the node name in this workflow is the same as the resource used, in this case, the name of the job template "OS / Pre-conversion Analysis". ![CONVERT2RHEL / 01 Analysis workflow visualizer](images/analysis_workflow_visualizer.png) @@ -257,7 +257,7 @@ Can you find the upstream source repo and playbook code? ``` By checking the `collections/requirements.yml` file in the `redhat-partner-tech/automated-satellite` git repo, we can discover that this role comes from another git repo at [https://github.com/heatmiser/infra.convert2rhel](https://github.com/heatmiser/infra.convert2rhel). It is the `analysis` role under this second git repo that provides all the automation tasks that ultimately runs the Convert2RHEL analysis scan and generates the report. - > **NOTE:** We are utilizing a fork of the upstream infra.convert2rhel Ansible collection [https://github.com/redhat-cop/infra.convert2rhel](https://github.com/redhat-cop/infra.convert2rhel). Because the upstream collections is a fast moving project, we utilize a fork where we can closely manage the state of the code base to ensure optimal stability for the lab/workshop/demo environment. + > **NOTE:** We are utilizing a fork of the upstream infra.convert2rhel Ansible collection [https://github.com/redhat-cop/infra.convert2rhel](https://github.com/redhat-cop/infra.convert2rhel). Because the upstream collection is a fast moving project, we utilize a fork where we can closely manage the state of the code base to ensure optimal stability for the lab/workshop/demo environment. - In a new browser tab/instance, open the [https://github.com/heatmiser/infra.convert2rhel](https://github.com/heatmiser/infra.convert2rhel) URL. Drill down to the `roles/analysis` directory in this git repo to review the README and yaml source files. diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/README.md index fb744f978..442b3f5e2 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/README.md @@ -7,9 +7,9 @@ - [Objectives](#objectives) - [Guide](#guide) - [Step 1 - Managing Convert2RHEL Pre-conversion Results](#step-1---managing-convert2rhel-pre-conversion-results) - - [Step 2 - Navigating the CentOS Web Console](#step-2---navigating-the-rhel-web-console) + - [Step 2 - Navigating the CentOS Web Console](#step-2---navigating-the-centos-web-console) - [Step 3 - Review Convert2RHEL Pre-conversion Report of CentOS 7 Host](#step-3---review-convert2rhel-pre-conversion-report-of-centos-7-host) - - [Challenge Lab: What About Ignoring So Many High Findings?](#challenge-lab-what-about-ignoring-so-many-high-findings) + - [Challenge Lab: What About Ignoring So Many High Findings?](#challenge-lab-what-if-we-were-to-experience-warnings-we-are-unsure-of) - [Conclusion](#conclusion) ## Objectives @@ -24,7 +24,7 @@ In the previous exercise, we used a workflow template with associated job templates and playbooks to analyze our CentOS7 app servers. Behind the scenes, the `analysis` module from the `infra.convert2rhel` Ansible collection launched a Convert2RHEL pre-conversion analysis on each of our CentOS 7 app servers and once complete, parsed the pre-conversion analysis report for any issues that would either block the conversion from initiating or potentially failing. If any problems were found, then the Ansible Automation Platform automation job would have reported a failure. -- If we are using the Convert2RHEL utility to manually convert just a single CentOS host, we could simply get to a shell prompt on the host and look at the local report file output. In [Exercise 1.1, Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session), we learned how to open an ssh session to one of our app servers. Follow those steps and after logging in, use this command to review the local Convert2RHEL pre-conversion report file: +- If we are using the Convert2RHEL utility to manually convert just a single CentOS host, we could simply get to a shell prompt on the host and look at the local report file output. In [Exercise 1.1, Step 3](../1.1-setup/README.md#step-3---open-a-terminal-session), we learned how to open an ssh session to one of our app servers. Follow those steps and after logging in, use this command to review the local Convert2RHEL pre-conversion report file: ``` less /var/log/convert2rhel/convert2rhel-pre-conversion.txt @@ -44,7 +44,7 @@ In the previous exercise, we used a workflow template with associated job templa For this workshop, we will be using the CentOS Web Console to access the Convert2RHEL pre-conversion reports we generated. -- Return to the RHEL Web Console browser tab you opened from [Exercise 1.1, Step 4](../1.1-setup/README.md#step-4---access-the-rhel-web-console). This is the RHEL Web Console of the AAP controller host, but we need to access our CentOS 7 app server hosts to see their pre-conversion reports. Do this by clicking the "student​@​ansible-1.example.com" box in the top left corner of the AAP RHEL Web Console to reveal the remote host menu. For example: +- Return to the RHEL Web Console browser tab you opened from [Exercise 1.1, Step 5](../1.1-setup/README.md#step-5---access-the-web-console). This is the RHEL Web Console of the AAP controller host, but we need to access our CentOS 7 app server hosts to see their pre-conversion reports. Do this by clicking the "student​@​ansible-1.example.com" box in the top left corner of the AAP RHEL Web Console to reveal the remote host menu. For example: ![Remote host menu listing all workbench app servers](images/remote_host_menu_with_pets.png) @@ -86,9 +86,9 @@ less /var/log/convert2rhel/convert2rhel-pre-conversion.txt > **Note** > - > The contents of your report may differ from the example above because of updates made to the Convert2RHEL framework and other RHEL packages released over time since this workshop was written. If you discover any differences that materially break the flow of the exercises in the workshop, kindly let us know by raising an issue [here](https://github.com/redhat-partner-tech/automated-satellite/issues/new). + > The contents of your report may differ from the example above because of updates made to the Convert2RHEL utility and other RHEL packages released over time since this workshop was written. If you discover any differences that materially break the flow of the exercises in the workshop, kindly let us know by raising an issue [here](https://github.com/redhat-partner-tech/automated-satellite/issues/new). -- When the pre-conversion report is generated, the Convert2RHEL framework collects system data and assesses convertability based on a large collection of checks. When any of these checks uncovers a potential risk, it is recorded as a finding in the report. +- When the pre-conversion report is generated, the Convert2RHEL utility collects system data and assesses convertability based on a large collection of checks. When any of these checks uncovers a potential risk, it is recorded as a finding in the report. - The good news is that the warning regarding the "third party" package `katello-ca-consumer-satellite`: `(WARNING) LIST_THIRD_PARTY_PACKAGES::THIRD_PARTY_PACKAGE_DETECTED - Third party packages detected` diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/README.md index f90df0849..dd44e28e7 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/README.md @@ -7,13 +7,13 @@ - [Objectives](#objectives) - [Guide](#guide) - [Step 1 - Launch the Conversion Workflow Job Template](#step-1---launch-the-conversion-workflow-job-template) - - [Step 2 - Learn More About Convert2RHEL](#step-2---learn-more-about-leapp) + - [Step 2 - Learn More About Convert2RHEL](#step-2---learn-more-about-convert2rhel) - [Conclusion](#conclusion) ## Objectives * Use a workflow job template to create snapshots and start the conversions -* Learn about how the Convert2RHEL framework goes about converting CentOS to RHEL +* Learn about how the Convert2RHEL utility goes about converting CentOS to RHEL ## Guide @@ -29,7 +29,7 @@ We are about to start the CentOS conversion of our application servers. When the Conversions typically take less than an hour, although they can run for longer if there are applications that shutdown slowly or with bare metal hosts that have a long reboot cycle. The cloud instances provisioned for our workshop lab environment will convert fairly quickly as they are very lightweight compared to traditional enterprise app servers. -One think that's needs to be taken care of first is to remove the snapshots that were taken prior to the analysis, as we will want to take fresh snapshots priore to launching the conversion workflow. +One thing that's needs to be taken care of first is to remove the snapshots that were taken prior to the analysis, as we will want to take fresh snapshots prior to launching the conversion workflow. - Return to the AAP Web UI tab in your web browser. Navigate to Resources > Templates and then open the "UTILITY / Snapshot Instance" job template. Here is what it looks like: @@ -73,13 +73,13 @@ One think that's needs to be taken care of first is to remove the snapshots that ### Step 2 - Learn More About Convert2RHEL -After launching the conversion job, the AAP Web UI will navigate automatically to the workflow job output page of the job we just started. This job will take up to 20 minutes to finish, so let's take this time to learn a little more about how the Convert2RHEL framework converts your EL OS to the associated RHEL major version. +After launching the conversion job, the AAP Web UI will navigate automatically to the workflow job output page of the job we just started. This job will take up to 20 minutes to finish, so let's take this time to learn a little more about how the Convert2RHEL utility converts your EL OS to the associated RHEL major version. -- Keep in mind that the Convert2RHEL framework is responsible only for converting the CentOS packages. Additional tasks required for upgrading your standard agents, tools, middleware, etc., need to be included in the conversion playbooks you develop to deal with the specific requirements of your organization's environment. +- Keep in mind that the Convert2RHEL utility is responsible only for converting the CentOS packages. Additional tasks required for upgrading your standard agents, tools, middleware, etc., need to be included in the conversion playbooks you develop to deal with the specific requirements of your organization's environment. ## Conclusion -In this exercise, we launched a workflow job template to create snapshots and start the conversions of our CentOS app servers. We learned more about the Convert2RHEL framework to better understand what is happening as the CentOS systems are being converted. +In this exercise, we launched a workflow job template to create snapshots and start the conversions of our CentOS app servers. We learned more about the Convert2RHEL utility to better understand what is happening as the CentOS systems are being converted. In the next exercise, we'll learn more about how snapshots work. diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.2-snapshots/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.2-snapshots/README.md index e81d8632f..1c98b50fd 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/2.2-snapshots/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.2-snapshots/README.md @@ -6,7 +6,7 @@ - [Table of Contents](#table-of-contents) - [Objectives](#objectives) - [Guide](#guide) - - [Step 1 - What are Snapshots and What are They Not](#step-1---what-are-snapshots-and-what-are-they-not) + - [Step 1 - What are Snapshots and What are They Not](#step-1---what-are-snapshots-and-what-they-are-not) - [Step 2 - Assessing Different Snapshot Solutions](#step-2---assessing-different-snapshot-solutions) - [LVM](#lvm) - [VMware](#vmware) @@ -50,7 +50,7 @@ There are a number of different types of snapshot solutions you may choose from. | Snapshot type | Works with | Benefits | Drawbacks | | ------------- | ---------- | -------- | --------- | -| LVM |||| +| LVM |||| | VMware |||| | Amazon EBS |||| | Break Mirror |||| @@ -66,9 +66,9 @@ The Logical Volume Manager (LVM) is a set of tools included in CentOS that provi > > The snapshot and rollback automation capability implemented for our workshop lab environment creates LVM snapshots managed using Ansible roles from the [`infra.lvm_snapshots`](https://github.com/swapdisk/infra.lvm_snapshots#readme) collection. -Logical volumes are contained in a storage pool known as a volume group. The storage available in a volume group comes from one or more physical volumes, that is, block devices underlying actual disks or disk partitions. Typically, the logical volumes where the CentOS OS is installed will be in a "rootvg" volume group. If best practices are followed, applications and app data will be isolated in their own logicial volumes either in the same volume group or a separate volume group, "appvg" for example. +Logical volumes are contained in a storage pool known as a volume group. The storage available in a volume group comes from one or more physical volumes, that is, block devices underlying actual disks or disk partitions. Typically, the logical volumes where the CentOS OS is installed will be in a "rootvg" volume group. If best practices are followed, applications and app data will be isolated in their own logical volumes either in the same volume group or a separate volume group, "appvg" for example. -To create logical volume snapshots, there must be free space in the volume group. That is, the total size of the logical volumes in the volume group must be less than the total size of the volume group. The `vgs` command can be used query volume group free space. For example: +To create logical volume snapshots, there must be free space in the volume group. That is, the total size of the logical volumes in the volume group must be less than the total size of the volume group. The `vgs` command can be used to query volume group free space. For example: ``` # vgs @@ -98,7 +98,7 @@ In our experience, having this access granted can be extremely challenging. The The VMware team may resist supporting snapshots because of limited storage space. While standard VMDK files are fixed in size, COW snapshots will grow over time and require careful monitoring with data stores in VMware environments often running tight on capacity. -Another justification for pushing back on supporting automated snapshots will be the VMware vendor recommendation that snapshots should never be used for more than 72 hours (see KB article [Best practices for using VMware snapshots in the vSphere environment](https://kb.vmware.com/s/article/1025279)). Unfortunately, app teams usually need more than 3 days of soak time before they are comfortable that no impact to their apps has resulted from a CentOS conversion. +Another justification for pushing back on supporting automated snapshots will be the VMware vendor recommendation that snapshots should never be used for more than 72 hours (see KB article [Best practices for using VMware snapshots in the vSphere environment](https://knowledge.broadcom.com/external/article/318825/best-practices-for-using-vmware-snapshot.html)). Unfortunately, app teams usually need more than 3 days of soak time before they are comfortable that no impact to their apps has resulted from a CentOS conversion. VMware snapshots work great when they can be automated. If you are considering this option, engage early with the team that controls the VMware environment for your organization and be prepared for potential resistance. @@ -128,7 +128,7 @@ Refer to the [Relax-and-Recover (ReaR) User Guide Documentation](https://relax-a ### Step 3 - Snapshot Scope -A best practice for allocating the local storage of servers is to configure volumes that separate the OS from the apps and app data. For example, the OS filesystems would be under a "rootvg" volume group while the apps and app data would be in an "appvg" volume group or at least in their own dedicated logical volumes. This separation helps isolate the storage usage requirements of these two groups so they can be manged based on their individual requirements and are less likely to impact each other. For example, the backup profile for the OS is likely different than for the apps and app data. +A best practice for allocating the local storage of servers is to configure volumes that separate the OS from the apps and app data. For example, the OS filesystems would be under a "rootvg" volume group while the apps and app data would be in an "appvg" volume group or at least in their own dedicated logical volumes. This separation helps isolate the storage usage requirements of these two groups so they can be managed based on their individual requirements and are less likely to impact each other. For example, the backup profile for the OS is likely different than for the apps and app data. This practice helps to enforce a key tenet of the CentOS conversion approach: that is that the OS conversion should leave the applications untouched with the expectation that system library forward compatibility and middleware runtime abstraction reduces the risk of the CentOS to RHEL conversion impacting app functionality. diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/README.md index f49bb5162..d71d24c70 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/README.md @@ -17,7 +17,7 @@ ## Guide -In the previous exercises, we reviewed pre-conversion analyis reports, as well as reviewing the potential for incorporating remediations. After all of that, you finally launched the Ansible workflow that initiated jobs with corresponding playbooks to run the CentOS conversions on your servers. +In the previous exercises, we reviewed pre-conversion analysis reports, as well as reviewing the potential for incorporating remediations. After all of that, you finally launched the Ansible workflow that initiated jobs with corresponding playbooks to run the CentOS conversions on your servers. It's time to verify the results of the conversions and let our application team assess if their three tier application stack is in working order. We are here in our CentOS in-place conversion automation workflow: @@ -51,13 +51,13 @@ The first thing we want to do is see if the job running the conversion playbook If there are no failed runs, the CentOS in-place conversion is complete on all of our application servers. -### Step 2 - Verify the Hosts are Upgraded to Next RHEL Version +### Step 2 - Verify the Hosts are Converted to Next RHEL Version Now let's make sure our application servers have actually converted to RHEL. -- In [Exercise 1.3: Step 2](../1.3-report/README.md#step-2---navigating-the-rhel-web-console), you used the RHEL Web Console to check the installed CentOS versions on your application servers. Let's repeat those steps to see the RHEL versions reported after our conversions. +- In [Exercise 1.4: Step 2](../1.4-report/README.md#step-2---navigating-the-centos-web-console), you used the CentOS Web Console to check the installed CentOS versions on your application servers. Let's repeat those steps to see the RHEL versions reported after our conversions. - Return to your RHEL Web Console browser tab and use the remote host menu to navigate to the web consoles of each of your application servers. The RHEL Web Console system overview page should now show the converted versions. + Return to your Web Console browser tab and use the remote host menu to navigate to the web consoles of each of your application servers. The Web Console system overview page should now show the converted versions. > **Note** > @@ -69,7 +69,7 @@ Now let's make sure our application servers have actually converted to RHEL. - Additionally, if you recorded the `Asset Tag` and `Machine ID`, note that they are the same, serving as verification that this is indeed the same system that was previously operating with CentOS 7. -- You can also check the RHEL and kernel versions from the command line following the steps you used with [Exercise 1.4: Step 2](../1.4-report/README.md###step-3---review-convert2rhel-pre-conversion-report-of-centos-7-host). +- You can also check the RHEL and kernel versions from the command line following the steps you used with [Exercise 1.4: Step 3](../1.4-report/README.md#step-3---review-convert2rhel-pre-conversion-report-of-centos-7-host). At the shell prompt of your application servers, use the `cat /etc/redhat-release` and `uname -r` commands. Here's an example showing that application server `node4` was converted to RHEL 7: diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/README.md index 8aec6db15..e4bd20aa5 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/README.md @@ -44,7 +44,7 @@ This should take ~15 seconds to complete. In [Exercise 2.2](../2.2-snapshots/README.md), we considered the potential pitfalls of including app data in the scope of our snapshot. Imagine what would happen if your app at first appeared fine after the conversion, but an issue was later discovered after the app had been returned to production use. -- Wait at least one minute since running the previous smoke test job template and add a new table to the database via an additional run of of the **CONVERT2RHEL / 99 - Three Tier App smoke test** job template. Check the job template output for a task _similar_ to this, typically the last task in the job run: +- Wait at least one minute since running the previous smoke test job template and add a new table to the database via an additional run of the **CONVERT2RHEL / 99 - Three Tier App smoke test** job template. Check the job template output for a task _similar_ to this, typically the last task in the job run: `TASK [Fail if database db01 did not contain table 06-06-2024-04-01]` diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/README.md index f3a119082..3da4be470 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/README.md @@ -15,7 +15,7 @@ This is an optional exercise. It is not required to successfully complete the workshop, but it will help demonstrate the effectiveness of rolling back a CentOS to RHEL conversion. Review the objectives listed in the next section to decide if you want to do this exercise or if you would rather skip ahead to the next exercise: -* [Exercise 3.2 - Run Rollback Job](3.2-rollback/README.md) +* [Exercise 3.2 - Run Rollback Job](../3.2-rollback/README.md) ## Objectives @@ -34,7 +34,7 @@ In the next exercise, we will be rolling back the CentOS to RHEL conversion acro - Choose one of the servers. It can be the HAproxy node, or the Tomcat node, or the PostgreSQL node. In this example, the PostgreSQL node, node6, will be utilized. -- Follow the steps you used with [Exercise 1.1: Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session) to open a terminal session on the application stack server you have chosen misconfigure. +- Follow the steps you used with [Exercise 1.1: Step 3](../1.1-setup/README.md#step-3---open-a-terminal-session) to open a terminal session on the application stack server you have chosen misconfigure. - At the shell prompt, ssh to node6: `ssh node6` and then use the `sudo -i` command to switch to the root user. For example: diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/README.md index c46a2785b..cdd0da0bc 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/README.md @@ -32,7 +32,7 @@ In this step, we will be rolling back the CentOS conversion for our entire three > **Note** > -> In this case, only one of our nodes has an issue. Depending on overall thoughts on how to best proceed, an argument could be made for just rolling back the PostgreSQL node, node6, and leave node4 and node5 as they are. However, in this case, we are going to demonstrate the ability to simulataneously roll back an entire application stack of systems at once. +> In this case, only one of our nodes has an issue. Depending on overall thoughts on how to best proceed, an argument could be made for just rolling back the PostgreSQL node, node6, and leave node4 and node5 as they are. However, in this case, we are going to demonstrate the ability to simultaneously roll back an entire application stack of systems at once. - Return to the AAP Web UI tab in your web browser. Navigate to Resources > Templates and then open the "CONVERT2RHEL / 03 Rollback" workflow template. Here is what it looks like: @@ -66,11 +66,11 @@ After launching the rollback workflow job, the AAP Web UI will navigate automati ![Rollback job "PLAY RECAP" as seen at the end of the job output](images/rollback_job_recap.png) - Notice in the example above, we see the job completed in aproximately two and a half minutes. However, most of that time was spent in the final "Wait for the snapshot to drain" task which holds the job until the snapshot merges finish in the background. The instance was actually rolled back and service ready in just under a minute. Impressive, right? + Notice in the example above, we see the job completed in approximately two and a half minutes. However, most of that time was spent in the final "Wait for the snapshot to drain" task which holds the job until the snapshot merges finish in the background. The instance was actually rolled back and service ready in just under a minute. Impressive, right? ### Step 3 - Check the CentOS Version -Repeat the steps you followed with [Exercise 2.3: Step 2](../2.3-check-upg/README.md#step-2---verify-the-hosts-are-converted-to-next-rhel-version), this time to verify that the CentOS version is reverted back. +Repeat the steps you followed with [Exercise 2.3: Step 2](../2.3-check-convert/README.md#step-2---verify-the-hosts-are-converted-to-next-rhel-version), this time to verify that the CentOS version is reverted back. - For example, if the three tier host you rolled back had been converted from CentOS7 to RHEL7, you should now see it is back to CentOS7: diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.3-check-undo/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.3-check-undo/README.md index 6c53b080e..d23ba04b9 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/3.3-check-undo/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.3-check-undo/README.md @@ -24,13 +24,13 @@ In the previous exercise, we rolled back our three tier application servers. Now In this step, we will repeat the observations we made on our host after the conversion with the expectation that everything is back as it was before the conversion. -- In the previous exercise, we checked that the CentOS version is reverted back. You can verify this at a shell prompt using commands like `cat /etc/redhat-release` and `uname -r` to output the OS release information and kernel version. You can also refresh the RHEL Web Console to confirm the CentOS version shown on the system overview page. +- In the previous exercise, we checked that the CentOS version is reverted back. You can verify this at a shell prompt using commands like `cat /etc/redhat-release` and `uname -r` to output the OS release information and kernel version. You can also refresh the Web Console to confirm the CentOS version shown on the system overview page. -- If you inflicted some damage to any of the three tier application servers with the optional [Simulate conversion failure](../3.1-error-condition/README.md) exercise, you will now find no evidence of that. You could switch over to the Ansible Automation Platform UI and run the `CONVERT2RHEL / 99 - Three Tier App smoke test` job template to verify complete application stack functinality. Or check via some of the following: +- If you inflicted some damage to any of the three tier application servers with the optional [Simulate conversion failure](../3.1-error-condition/README.md) exercise, you will now find no evidence of that. You could switch over to the Ansible Automation Platform UI and run the `CONVERT2RHEL / 99 - Three Tier App smoke test` job template to verify complete application stack functionality. Or check via some of the following: For example, did you delete everything with the `rm -rf /*` command or remove the standard C library with the `rpm -e --nodeps glibc` command? Your efforts to nuke the OS have been nullified! - Did you break your three tier applicationlication by removing the PostgreSQL package on node6? If you check now with the `yum list 'postgresql*'` command, you will see that postgresql packages are installed. + Did you break your three tier application by removing the PostgreSQL package on node6? If you check now with the `yum list 'postgresql*'` command, you will see that postgresql packages are installed. If you filled up your disk, check now with the `df -h /` command. You will see there is now plenty of free space reported. diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.4-conclusion/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.4-conclusion/README.md index 9e74e1d43..54cb6505b 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/3.4-conclusion/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.4-conclusion/README.md @@ -40,9 +40,9 @@ With these exercises, you gained hands-on experience while learning about a pres Hopefully, these exercises have opened your eyes to what is possible, but we have just scratched the surface. -- Is it possible to convert/upgrade from CentOS7 directly to RHEL8 or RHEL9? While the Convert2RHEL and Leapp frameworks do not support a "conversion plus upgrades" directly, it is possible to take a host that was converted from CentOS7 to RHEL7 and then upgrade from there to RHEL8 and, if desired, upgrade onwards to RHEL 9. You can follow this path in this workshop via the next exercise in this workshop series, **Automated Satellite Workshop: RHEL In-place Upgrade Automation exercise** +- Is it possible to convert/upgrade from CentOS7 directly to RHEL8 or RHEL9? While the Convert2RHEL and Leapp frameworks do not support a "conversion plus upgrades" directly, it is possible to take a host that was converted from CentOS7 to RHEL7 and then upgrade from there to RHEL8 and, if desired, upgrade onwards to RHEL 9. You can follow this path in this workshop via the next exercise in this workshop series, [Automated Satellite Workshop: RHEL In-place Upgrade Automation exercise](../../4-ripu/README.md). - There are a couple things to be aware of if you want to continue through to the RHEL In Place Upgrade content. If you stepped through the conversion rollback exercise, you will have to perform the conversion again and then verify the conversion as successful. You will then need to run the `SATELLITE / Change content source for content host` and select `CentOS7_Dev` for the inventory group and `RHEL7_Dev` for the target lifecycle environment. + There are a couple things to be aware of if you want to continue through to the RHEL In-Place Upgrade content. If you stepped through the conversion rollback exercise, you will have to perform the conversion again and then verify the conversion as successful. You will then need to run the `SATELLITE / Change content source for content host` and select `CentOS7_Dev` for the inventory group and `RHEL7_Dev` for the target lifecycle environment. ![Satellite Change content source for content host](images/content_host_change_source_survey.png) @@ -60,7 +60,7 @@ All of the Ansible roles and playbooks used in this workshop are maintained in u #### [redhat-cop/infra.convert2rhel](https://github.com/redhat-cop/infra.convert2rhel) -- The `infra.convert2rhel` Ansible collection provides the Ansible role that generates the pre-conversion analysis reports and another that is used to perform conversions for EL rebuild OS's. This collection serves as a framework around the Convert2RHEL utility for conversions from CentOS7, Oracle Linux 7 and more. The collection is published on Ansible Galaxy [here](https://galaxy.ansible.com/ui/repo/published/infra/convert2rhel/) and also available from Ansible Automation Hub validated content [here - Red Hat account required](https://console.redhat.com/ansible/automation-hub/repo/validated/infra/convert2rhel/). If you are planning to do EL conversions for your organization, these Ansible collections will help you quickly roll out proof-of-concept automation and start upgrading. +- The `infra.convert2rhel` Ansible collection provides the Ansible role that generates the pre-conversion analysis reports and another that is used to perform conversions for EL rebuild OS's. This collection serves as a framework around the Convert2RHEL utility for conversions from CentOS7, Oracle Linux 7 and more. The collection is published on Ansible Galaxy [here](https://galaxy.ansible.com/ui/repo/published/infra/convert2rhel/) and also available from Ansible Automation Hub validated content [here - Red Hat account required](https://console.redhat.com/ansible/automation-hub/repo/validated/infra/convert2rhel/). If you are planning to do EL conversions for your organization, these Ansible collections will help you quickly roll out proof-of-concept automation and start converting. #### [redhat-partner-tech/automated-satellite](https://github.com/redhat-partner-tech/automated-satellite) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/README.md index 535eb3d1e..e89d71c4c 100644 --- a/exercises/rhdp_auto_satellite/3-convert2rhel/README.md +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/README.md @@ -4,7 +4,7 @@ > > This workshop is available with either CentOS 7 or Oracle Linux 7 nodes. In the case where Oracle Linux nodes are present, substitute "Oracle Linux" wherever "CentOS" is mentioned in the exercise instructions. -This exercise will introduce a comprehensive approach to automate conversions of CentOS 7 to Red Hat Enterprise Linux (RHEL) 7. The solution uses Ansible Automation Platform (AAP) to execute upgrades at enterprise scale across a large estate of CentOS hosts. The exercise demonstrates how to use an example of this approach to perform conversions of CentOS7 to RHEL7. You will also learn about how this solution can be customized to meet the special requirements of your enterprise environment. +This exercise will introduce a comprehensive approach to automate conversions of CentOS Linux 7 to Red Hat Enterprise Linux (RHEL) 7. The solution uses Ansible Automation Platform (AAP) to execute upgrades at enterprise scale across a large estate of CentOS hosts. The exercise demonstrates how to use an example of this approach to perform conversions of CentOS7 to RHEL7. You will also learn about how this solution can be customized to meet the special requirements of your enterprise environment. There are three key features that the solution approach recommends to deliver success at scale: diff --git a/exercises/rhdp_auto_satellite/README.md b/exercises/rhdp_auto_satellite/README.md index 49a8587fc..6eba67082 100644 --- a/exercises/rhdp_auto_satellite/README.md +++ b/exercises/rhdp_auto_satellite/README.md @@ -19,7 +19,7 @@ In this workshop, you will learn how to get the most from Red Hat Satellite in c This workshop currently focuses on 5 main customer pain points: - Compliance (OpenSCAP Scanning) and Vulnerability Management - Patch/Package Management -- CentOS/OracleLinux to RHEL Conversion +- CentOS/Oracle Linux to RHEL Conversion - RHEL In-Place-Upgrades - Vulnerability Management with Insights