Merge pull request #8 from RedHatQuickCourses/rutuja-edits/ch3

Edits suggested for chapter 3

modules/ch3-test/pages/index.adoc

@@ -7,6 +7,6 @@ WARNING: Pending SME Review & Proofreading
 
 == Introduction
 
-This chapter explains to use KVM virtualization from RHEL to test edge device images, as part of a development or CI/CD workflow, and the usage scenarios for different kinds of edge installer images.
+This chapter explains the use of KVM virtualization from RHEL to test edge device images, as part of a development or CI/CD workflow, and the usage scenarios for different kinds of edge installer images.
 
-This chapter presents a series of hands-on activities which provision VMs from OSTree repositories, either directly, by using the standard RHEL installation media, or by means of an edge installer image generated by Image Builder. The next and final chapter shows how to apply update to VMs provisioned using either method.
+This chapter presents a series of hands-on activities that provision VMs from OSTree repositories, either directly, by using the standard RHEL installation media, or by means of an edge installer image generated by Image Builder. The next and final chapter shows how to apply updates to VMs provisioned using either method.

modules/ch3-test/pages/s1-boot.adoc

@@ -18,13 +18,13 @@ You can use the standard RHEL installation media, together with a small custom k
 
 image::s1-boot-fig-1.svg[title="End of an edge device installation workflow the standard RHEL installation media"]
 
-Alternatively, you can use the Image Builder service to create an edge installer image, which embeds an OSTree commit, and copy the generated edge installer image to an USB media. Then you provision edge systems using the edge installer image.
+Alternatively, you can use the Image Builder service to create an edge installer image, which embeds an OSTree commit, and copy the generated edge installer image to a USB media. Then you provision edge systems using the edge installer image.
 
 image::s1-boot-fig-2.svg[title="End of an edge device installation workflow an edge installer image and custom boot media"]
 
 There's a third alternative, which we do not cover in this course: you can use Image Builder to create an edge cloud image, which embeds an OSTree commit, and upload that image to a cloud provider. Then you provision edge cloud instances using the edge cloud image.
 
-The two alternatives described here can be used with either PXE or UEFI network boot. The details will be presented by a future course. Here we focus on testing our edge images by provision local virtual machines using the KVM technology fgrom RHEL.
+The two alternatives described here can be used with either PXE or UEFI network boot. The details will be presented in a future course. Here we focus on testing our edge images by provisioning local virtual machines using the KVM technology from RHEL.
 
 == Types of Edge Installer Images
 
@@ -38,40 +38,40 @@ Simplified edge Installer image::
 
 It is a custom RHEL CoreOS installation media, which includes a raw disk image, and the raw disk image includes an OSTree commit.
 
-The main difference between those two types of edge installer images is the syntax for applying installation-time customizations: the edge installer image uses the familiar kickstart syntax from RHEL, while the edige simplified installer image uses the ignition syntax from RHEL CoreOS.
+The main difference between those two types of edge installer images is the syntax for applying installation-time customizations: the edge installer image uses the familiar kickstart syntax from RHEL, while the edge simplified installer image uses the ignition syntax from RHEL CoreOS.
 
-There is some overlap between customizations that could be specified in an Image Builder blueprint, a kickstart file, or an  ignition configuration. Red Hat recommends that you use blueprint customizations as much as possible, reserving kickstart and ignition for settings you wish to change in an individual edge device or edge site basis. Also consider if other kinds of automation, such as Red Hat Ansible Automation Platform, may be best suited for applying customizations as a day-2 activity instead of as a installation or first boot basis.
+There is some overlap between customizations that could be specified in an Image Builder blueprint, a kickstart file, or an  ignition configuration. Red Hat recommends that you use blueprint customizations as much as possible, reserving kickstart and ignition for settings you wish to change in an individual edge device or edge site basis. Also consider if other kinds of automation, such as Red Hat Ansible Automation Platform, may be best suited for applying customizations as a day-2 activity instead of as an installation or first boot basis.
 
-Red Hat also recommends that you do not abuse the possibilities of kickstart and ignition: both could be used to run arbitrary scripts and even download executable files from remote servers. It's generally better if you follow a "shift left" approach and perform as many customizations as you can at image building time instead of at installation time.
+Red Hat also recommends that you do not abuse the possibilities of kickstart and ignition: both could be used to run arbitrary scripts and even download executable files from remote servers. It's generally better if you follow a "shift left" approach and perform as many customizations as you can at image-building time instead of at installation time.
 
 == Creating Edge Installer Images
 
 The process for creating an edge installer image (or its simplified counterpart) requires a minimal blueprint. There are a few customizations that you could include in that blueprint, such as defining Linux users and groups, but most other customizations, and any attempt at including package information, will fail the compose.
 
-The compose for edge installer images (and also for edge simplified images) requires two arguments:
+The compose for creating edge installer images (and also for edge simplified images) requires two arguments:
 
 1. The URL of a remote OSTree repository
-2. The branch name of an OSTree commit inside that repository. 
+2. The branch name of an OSTree commits inside that repository. 
 
 The Image Builder service pulls the OSTree commit and includes it in the edge installer image, which can be used to provision edge systems without network access to the remote OSTree repository. This is not intended for true disconnected deployments, but to enable provisioning edge devices with low bandwidth, high latency, or intermittent network connectivity. Remember that edge devices require access to a remote OSTree repository to fetch system updates.
 
 == RPM-OSTree Deployment and Edge System Provisioning
 
 An edge device could pull multiple OSTree commits, but only one of those commits is active, or *deployed*. Deploying an OSTree commit with RPM-OSTree also installs the boot loader, kernel, and initial ram disk (initrd) from the files inside the commit.
 
-When provisioning an edge system, OSTree deployment can happen in different moments:
+When provisioning an edge system, OSTree deployment can happen at different moments:
 
 * At installation time, when using the standard RHEL installation media: the standard RHEL installer creates an empty OSTree repository on the root disk, pulls an OSTree commit from a remote OSTree repository, and deploys the commit;
 
-* At at installation, when using an edge installer image: the standard RHEL installer copies the OSTree repository from the image itself to the system root disk, and deploys the only commit in that repository.
+* At installation, when using an edge installer image: the standard RHEL installer copies the OSTree repository from the image itself to the system root disk, and deploys the only commit in that repository.
 
-* At image build time, when using a simplified edge installer image: the simplified edge installer image contains a raw disk image which an OSTree repository and an already deployed OSTree commit. The RHEL CoreOS installer just copies that raw disk image to the system boot disk.
+* At image build time, when using a simplified edge installer image: the simplified edge installer image contains a raw disk image which is an OSTree repository and an already deployed OSTree commit. The RHEL CoreOS installer just copies that raw disk image to the system boot disk.
 
-Once a system boots into an OSTree deployment, you can pull updates, as a new OSTree commits, from a remote OSTree repository to its local OSTree repository branch and deploy the new OSTree commit. The update process, which we see in details later in this course, does not change based on how the system was initially provisioned.
+Once a system boots into an OSTree deployment, you can pull updates, as a new OSTree commits, from a remote OSTree repository to its local OSTree repository branch and deploy the new OSTree commit. The update process, which we see in detail later in this course, does not change based on how the system was initially provisioned.
 
 == File System Layout of Edge Systems
 
-Just so you have an idea of what to expect in a RHEL for Edge system, and you can verify that you really booted from an edge system image, let's describe the RPM-OSTree file system layout.
+Just so you have an idea of what to expect in an RHEL for Edge system, and you can verify that you really booted from an edge system image, let's describe the RPM-OSTree file system layout.
 
 Unlike package-based systems, which provide freedom of using multiple disk devices and partitions, LVM logical volumes, and many other choices, RPM-OSTree requires a fixed file system layout based on a read-only `/usr` directory, to ensure the pristine state of the operating system as booted from its system image.
 
@@ -81,19 +81,19 @@ The root disk of an RPM-OSTree system contains an OSTree repository with a deplo
 
 Operations which require changing the actual root filesystem, such as deploying a new system image, must happen early in the boot sequence, before it chroots to the deployed RPM-OSTree system image.
 
-An RPM-OSTree system has only two writable file systems: `/etc` and `/var`. That is sufficient to store local system configurations and application data on edge devices. Later in this course we will learn how those directories are treated during system installation and updates.
+An RPM-OSTree system has only two writable file systems: `/etc` and `/var`. That is sufficient to store local system configurations and application data on edge devices. Later in this course, we will learn how those directories are treated during system installation and updates.
 
 Many other top-level directories, which would be writable, are actually symlinks to a directory under `/var`. For example, `/home` is a symlink to `/var/home` and `/usr/local` is a synlink to `/var/usrlocal`.
 
 RPM-OSTree expects that there's nothing on `/` other than mount points and symlinks. All operating system binaries are actually under `/usr` and older system directories are symlinks to directories under `/usr`. For example, `/bin` is a symlink to `/usr/bin`.
 
 RPM-OSTree also enables activating a write file system layer over `/usr` for local customizations, for example to install additional RPM packages not included in the system image. In that case, you must install packages using the `rpm-ostree` command, because the `dnf` command would attempt to write to the RPM database in the system image, which is read-only.
 
-NOTE: It is not expected that production edge systems make use of the RPM-OSTree capability of installing additional packages, but it can be handy during development and troubleshooting of edge images.
+NOTE: It is not expected that production edge systems make use of the RPM-OSTree capability of installing additional packages, but it can be handy during the development and troubleshooting of edge images.
 
 == Testing Edge System Images using VMs
 
-Most times the end goal of producing an edge system image is provisioning and booting physical edge devices, but it is very convenient testing edge images using virtualization technology, such as IaaS cloud instances and Red Hat OpenShift Virtualization. Virtualization technologies also come in handy when performing automated integration testing, as part of a CI/CD pipeline.
+Most times the end goal of producing an edge system image is provisioning and booting physical edge devices, but it is very convenient to test edge images using virtualization technology, such as IaaS cloud instances and Red Hat OpenShift Virtualization. Virtualization technologies also come in handy when performing automated integration testing, as part of a CI/CD pipeline.
 
 Depending on your virtualization technology of choice, it may be possible to emulate special kinds of hardware expected on your physical edge devices, or provide pass-through of physical devices from your development machine to its virtual machines.
 
@@ -107,7 +107,7 @@ The RHEL installation program provides interactive prompts for configuring local
 
 Unattended installation using the standard RHEL installation media, or edge installer images, requires providing a kickstart file that answers all prompts required by the RHEL installation program. You could create a custom RHEL installation media including such kickstart file and also a custom boot loader configuration that references your kickstart file.
 
-An edge installer image already comes with a kickstart file and a boot loader configuration that uses it. But it includes only a minimal kickstart file, which is not sufficient for unattended installation. It provides just enough so the RHEL installation program uses the OSTree commit from the image itself as its installation source.
+An edge installer image already comes with a kickstart file and a boot loader configuration that uses it. But, it includes only a minimal kickstart file, which is not sufficient for unattended installation. It provides just enough so the RHEL installation program uses the OSTree commit from the image itself as its installation source.
 
 For unattended installation, you would amend the kickstart file generated by the Image Builder service and create a custom edge installer image, outside of Image Builder, that includes your longer kickstart file.
 
@@ -121,15 +121,15 @@ Simplified edge installer images, in contrast, always installs unattended. You c
 
 If none of the applications in your edge system image require a graphical desktop to function, you may configure your edge images with a text-only boot and configure your test VMs with a serial virtual console. That way you can do testing over an SSH connection, without requiring any kind of remote graphical display, and you can also easily redirect all boot messages to a text file for troubleshooting boot issues.
 
-As much as text mode boot and serial consoles may be convenient during testing, a graphical boot and desktop are probably be easier for field personnel. In that case, you let your edge images boot with a graphical console, by default, and provide Libvirt with extra kernel arguments to configure a virtual serial console and boot in text mode. Be aware that providing extra kernel arguments at VM creation file also requires using direct kernel loading.
+As much as text mode boot and serial consoles may be convenient during testing, a graphical boot and desktop are probably easier for field personnel. In that case, you let your edge images boot with a graphical console, by default, and provide Libvirt with extra kernel arguments to configure a virtual serial console and boot in text mode. Be aware that providing extra kernel arguments at VM creation file also requires using direct kernel loading.
 
-== Tools to Manage local VMs in RHEL
+== Tools to Manage Local VMs in RHEL
 
 Libvirt is the management API in RHEL for virtual machines using Linux KVM and Qemu technologies. It is the foundation of more sophisticated VM management from Red Hat, such as OpenShift Virtualization, but it is usable by itself and very popular among developers and for single-host virtualization.
 
-The main command-line tool to manage VMs from Libvirt is `virsh`. If you are new to Libvirt and RHEL virtualization, take the time to familiarize yourself with that command and its terminology. You must know that Libvirt uses the "domain" term to refer to the definition of a VMs, and "virtual machine" to refer to an active domain, that is, a running VM (or at least paused in memory).
+The main command-line tool to manage VMs from Libvirt is `virsh`. If you are new to Libvirt and RHEL virtualization, take the time to familiarize yourself with that command and its terminology. You must know that Libvirt uses the "domain" term to refer to the definition of a VMs, and "virtual machine" refers to an active domain, that is, a running VM (or at least paused in memory).
 
-Libvirt also provides a number of helper commands, such as the `virt-install` command to create new VMs. It generates VM configuration files required by Libvirtd from command-line options, so you do not have to learn its XML syntax. The common workflow is using the `virt-install` command to create VMs, them you manage those VMs using `virsh`.
+Libvirt also provides a number of helper commands, such as the `virt-install` command to create new VMs. It generates VM configuration files required by Libvirtd from command-line options, so you do not have to learn its XML syntax. The common workflow is using the `virt-install` command to create VMs, then you manage those VMs using `virsh`.
 
 It is worth noticing that RHEL 9 deprecated the `virt-manager` graphical tool to manage Libvirt VMs, and is keeping only the `virt-viewer` tool to interact with the graphical console of a VM. If all you need is the serial console of a VM, you can use the `virsh console` command to attach to it.