add summary and remove the quiz

modules/ch1-microshift/nav.adoc

@@ -1,4 +1,5 @@
 * xref:index.adoc[]
 ** xref:s1-microshift-vs-ocp.adoc[]
-** xref:s3-prepare-lab.adoc[]
-** xref:s4-air-gapped-lab.adoc[]
+** xref:s2-prepare-lab.adoc[]
+** xref:s3-air-gapped-lab.adoc[]
+** xref:s4-summary.adoc[]

modules/ch1-microshift/pages/s1-microshift-vs-ocp.adoc

@@ -42,44 +42,46 @@ The following figure compares MicroShift with the smallest edition of Red Hat Op
 
 image::s1-microshift-vs-ocp-fig-1.svg[title="MicroShift versus OpenShift"]
 
-It shows that, while both the Red Hat build of MicroShift and Red Hat OpenShift include Kubernetes as their container ochiestrator, plus security and a number of cluster services, Red Hat OpenShift includes a larger set of cluster services. The figure also shows that Red Hat OpenShift relies on RHEL CoreOS as its cluster  node operating system, while MicroShift relies on plain RHEL and on RHEL services, such as the system journal daemon, for tasks that Red Hat OpenShift would defer to its cluster services.
+It shows that, while both the Red Hat build of MicroShift and Red Hat OpenShift include Kubernetes as their container ochestrator, plus security and a number of cluster services, Red Hat OpenShift includes a larger set of cluster services. The figure also shows that Red Hat OpenShift relies on RHEL CoreOS as its cluster  node operating system, while MicroShift relies on plain RHEL and on RHEL services, such as the system journal daemon, for tasks that Red Hat OpenShift would defer to its cluster services.
 
 A number of components of Red Hat OpenShift are _absent_ from MicroShift, among them:
 
 * The Cluster Version Operator, which manages installation and upgrades of Red Hat OpenShift.
 * The Machine Configuration Operator, which manages the configuration of the RHEL CoreOS operating system in OpenShift cluster nodes.
 * Most Cluster Operators, which manage cluster services like Ingress, OAuth, Monitoring, and Kubernetes control plane components such as Etcd.
 
-It is also expected that Red Hat OpenShift users deploy a number of optional compoents as add-on operators, through the Operator Lifecycle Manager, such as:
+It is also expected that Red Hat OpenShift users deploy a number of optional compoents as add-on operators, through the Operator Lifecycle Manager (OLM), such as:
 
 * OpenShift GitOps
 * OpenShift Pipelines
 * OpenShift Virtualization
 * OpenShift ServiceMesh
 * Red Hat DevSpaces
 
-A number products certified for OpenShift, including storage and network providers, are also deployed as add-on operators. While you can install the OLM in MicroShift, as an optional component, most add-on operators are not currently tested or supported on MicroShift, and many of them would make no sense. For example, you would run OpenShift Pipelines or Red Hat Ansible Automation Platform in a regular OpenShift cluster to produce system images of Red Hat Device Edge for applications that target MicroShift. That OpenShift instance could even manage the final deployment of the application in actual edge devices, or in OpenShift Virtualization VMs for integration testing of such applications on actual RHEL for Edge system images.
+A number of products certified for OpenShift, including storage and network providers, are also deployed as add-on operators. While you can install the OLM in MicroShift, as an optional component, most add-on operators are not currently tested or supported on MicroShift, and many of them would make no sense. For example, you would run OpenShift Pipelines or Red Hat Ansible Automation Platform in a regular OpenShift cluster to produce system images of Red Hat Device Edge for applications that target MicroShift. That OpenShift instance could even manage the final deployment of the application in actual edge devices, or in OpenShift Virtualization VMs for integration testing of such applications on actual RHEL for Edge system images.
 
-Both Red Hat build of MicroShift and Red Hat OpenShift are https://www.cncf.io/training/certification/software-conformance/#logos[certified kubernetes] distributions, so they are expected to be compatible with the same applications. At least, this is the theory, but the fact is that Kubernetes certification only tests a small set of application APIs, and does _not_ validate the infrastructure nor operational processes for managing Kubernetes clusters. It leaves room for lots of diferentiation between Kubernetes distributions and applications could depend on a number of extension APIs which may not be available or compatible with every distribution.
+Both Red Hat build of MicroShift and Red Hat OpenShift are https://www.cncf.io/training/certification/software-conformance/#logos[certified kubernetes] distributions, so they are expected to be compatible with the same applications. At least, this is the theory, but the fact is that Kubernetes certification only tests a comprehensive set of core API required to support application workloads, and does _not_ validate the infrastructure nor operational processes for managing Kubernetes clusters. It leaves room for lots of diferentiation between Kubernetes distributions and applications could depend on a number of extension APIs which may not be available or compatible with every distribution of Kubernetes.
 
 MicroShift uses the same container engine (CRI-O) than Red Hat OpenShift and the same container images for components such as the Ingress controller, the OVN network provider, and the LVM Storage operator.
 
 == MicroShift Versus OpenShit
 
-The Red Hat build of MicroShift is different than other components of Red Hat Device Edge in the sense that its more than just a different SKU to acquire and entitle the same software and capabilities. While RHEL for Edge is just RHEL, without any difference in binaries, packages, and other components of RHEL, and Ansible for Edge is just the same Red Hat Ansible Automation Platform, with a set of supported content collections that includes edge and non-edge content collections, MicroShift is actually a unique build of Red Hat OpenShift, starting from the same sources, but producing different binaries with only a subset of the capabilities of Red Hat OpenShift.
+The Red Hat build of MicroShift is different than other components of Red Hat Device Edge in the sense that its more than just a different SKU to acquire and entitle the same software and capabilities. While RHEL for Edge is just RHEL, without any difference in its kernel, binaries, packages, and other components of RHEL, and Ansible for Edge is just the same Red Hat Ansible Automation Platform, with a set of supported content collections that includes both edge and non-edge content collections, MicroShift is actually a unique build of Red Hat OpenShift, starting from the same sources, but producing different binaries with only a subset of the capabilities of Red Hat OpenShift.
 
 // Based on slide #12 of https://docs.google.com/presentation/d/1Qw91HF7ohJErY8m7y9ItjGZAgLSklOR88MAq_5MtT4U/edit#slide=id.g152bfd145ff_0_2419
 
-While Red Hat OpenShift runs core Kubernetes components, such as Etcd, the Kubernetes scheduler, and the Kubernetes API server, as independent processes or containers, which are managed by OpenShift cluster operators, MicroShift runs all these components in a single process, managed by Systemd. In a sense, MicroShift is an "all-on-one" build of selected pieces of Red Hat OpenShift.
+MicroShift is designed to require only a small number of cluster services (and their containers) that it runs well withing the CPU and memory constraints of edge devices, while Red Hat OpenShift, even on its single-node cluster topology, requires data center-class server machines.
 
-OpenShift includes, since its 3.0 release, a number of extension APIs, and an OpenShift API server and controllers component that handles them. Some of these extension APIs are still today essential to Red Hat OpenShift as an application platform, for example Security Context Constraints, while others, such as Image Streams, are losing developer's preference in favor or alternatives such as GitOps. The Red Hat build of MicroShift includes, on its API server and resource controller only two of the extension APIs originatged from OpenShift 3.0:
+While Red Hat OpenShift runs core Kubernetes components, such as Etcd, the Kubernetes scheduler, and the Kubernetes API server, as independent processes on distinct pods, which are managed by OpenShift cluster operators, MicroShift runs all these components in a single process, managed by Systemd. In a sense, MicroShift is an "all-in-one" build of selected pieces of Red Hat OpenShift.
+
+OpenShift includes, since its 3.0 release, a number of extension APIs, and an OpenShift API server component that handles them. Some of these extension APIs are still today essential to the Red Hat OpenShift application platform, for example Security Context Constraints, while others, such as Image Streams, are losing developer's preference in favor or alternatives such as GitOps. The Red Hat build of MicroShift includes, on its build of the OpenShift API server, only two of the extension APIs originated from OpenShift 3.0:
 
 * Security Context Constraints
 * Routes
 
-And they are in the same process as its Kubernetes core components.
+And MicroShift runs its OpenShift API server in the same process and pod as its Kubernetes core components.
 
-MicroShift also includes selected componentes of OpenShift as they are, meaning it runs the same container images that provides those key services as Red Hat OpenShift:
+MicroShift also includes selected componentes of OpenShift unchanged, by running the same container images that provides those components as Red Hat OpenShift:
 
 * Ingress (and Route) controller
 * LVM Storage operator and CSI provider
@@ -93,22 +95,24 @@ A few components of Red Hat OpenShift can also be installed in MicroShift from R
 * Multus seconday networks
 * Operator Lifecycle Manager
 
-Red Hat OpenShift is designed to be compatible with a large number of certified third-party components, from storage and network providers to security agents and DevOps tools. MicroShift is designed to work with a much more oppinionated set of components, but also to enable adding optional components, such as GPU enablement, from either RPM packages or add-on operators.
+NOTE: The OpenShift GitOps package for MicroShift is _not_ a complete OpenShift GitOps operator. It cointains only an ArgoCD pull agent to fetch manifests from Git repositories and does not include features such as Argo Rollouts or multi-cluster capabilities. Some features might be included but not tested with MicroShift.
+
+Red Hat OpenShift is designed to be compatible with a large number of certified third-party components, from storage and network providers to security agents and DevOps tools. MicroShift is designed to work with a more restricted and oppinionated set of components, but also to enable adding optional components, such as GPU enablement, from either RPM packages or add-on operators.
 
-The goal of MicroShift is providing sufficient compatibility with Red Hat OpenShift that applications developed and tested on OpenShift can move to edge deployments unchanged, using the same container images and Kubernetes manifests.
+The goal of MicroShift to provide sufficient compatibility with Red Hat OpenShift that applications developed and tested on OpenShift can move to edge deployments unchanged, using the same container images and Kubernetes manifests.
 
-If you wish, you can package those applications as Helm charts or add-on operators, and still deploy them on MicroShift the same way you would on OpenShift. On the other hand, MicroShift should require a small enough number of cluster services (and their containers) that it runs well withing the CPU and memory constraints of edge devices, while Red Hat OpenShift, even on its single-node cluster topology, requires data center-class server machines.
+If you wish, you can package those applications as Helm charts or add-on operators, and still deploy them on MicroShift the same way you would on OpenShift.
 
 == MicroShift Cluster Management
 
-You manage Red Hat OpenShift almost entirely from Kuberentes APIs, using either custom resources from OpenShift cluster operators or from add-on operators. Even the operating system on OpenShift cluster nodes is managed using Kubernetes APIs. OpenShift cluster administrators, especially when running OpenShift in IaaS clouds, may never see the need to run Linux command on their OpenShift cluster nodes. They are advised to *NOT* open SSH sessions to these nodes.
+You manage Red Hat OpenShift almost entirely from Kuberentes APIs, using either custom resources from OpenShift cluster operators or from add-on operators. Even the operating system on OpenShift cluster nodes is managed using Kubernetes APIs. OpenShift cluster administrators, especially when running OpenShift in IaaS clouds, may never see the need to run Linux command on their OpenShift cluster nodes. They are advised to *NOT* open SSH sessions to these nodes for day-to-day tasks.
 
-Managing MicroShift, on the other hand, requires using traditional RHEL tools, such as the DNF package manager, Systemd, and SSH. Red Hat OpenShift is a complete application platform by itself, which provides a cloud-like experience, while MicroShift is closer to "just" a Kubernetes which you run on RHEL to manage containerized applications.
+Managing MicroShift, on the other hand, requires using traditional RHEL tools, such as the DNF package manager, Systemd, and SSH. Red Hat OpenShift is a complete application platform by itself, which provides a cloud-like experience, while MicroShift is closer to "just" running Kubernetes on top of RHEL.
 
-Finally, MicroShift clusters are always single node. If you need HA, you have to either consider RHEL HA services, such as Pacemaker, or consider Red Hat OpenShift editions. If you need horizontal scalability among multiple nodes, or vertical scalability to larger servers, you should also consider Red Hat OpenShift editions. On the other hand, MicroShift integrates well with other features of RHEL for Edge, for example the Greenboot capability of rolling back system upgrades to a previously known good image.
+Finally, MicroShift clusters are always single node. If you need HA, you have to either consider RHEL HA services, such as Pacemaker, or switch to Red Hat OpenShift. If you need horizontal scalability among multiple nodes, or vertical scalability to larger servers, you should also consider Red Hat OpenShift. On the other hand, MicroShift integrates well with other features of RHEL for Edge, for example the Greenboot capability of rolling back system upgrades to a previously known good image.
 
-You can run MicroShift in cloud instances, if you wish, but MicroShift lacks the integration components to use cloud auto-scaling, cloud storage, and cloud load balancers. It is really designed for small physical edge devices, and provides all componentes required by those devices as an integrated product, while upstream Kubernetes would require that you add, configure, and integrate a number of third-party componentes such as network providers, storage providers, ingress controllers, and service discovery, at mininum.
+You can run MicroShift in cloud instances, if you wish, but MicroShift lacks the integration components to use cloud auto-scaling, cloud storage, and cloud load balancers. It is really designed for small physical edge devices, and provides all componentes required by those devices as an integrated product, while upstream Kubernetes would require that you add, configure, and integrate a number of third-party componentes such as network providers, storage providers, ingress controllers, service discovery, and more.
 
 == What's Next
 
-After a knowledge check that you understand the differences and similarities between Red Hat OpenShift and Red Hat build of MicroShift, there's an activity that prepares the virtual labs environment for the remaining of this course. It should provide enough information for you to replicate the activities on your own environment, if you prefer. In fact, it's easier to run MicroShift on your regular work machine than it is running Red Hat OpenShift.
+There first activities in this course prepare the virtual labs environment for air-gappend deployment of MicroShift using either package-based RHEL or RHEL for Edge. It should provide enough information for you to replicate the activities on your own environment, if you prefer, or trying a simpler deployment, not air-gapped.

modules/ch1-microshift/pages/s4-summary.adoc

@@ -0,0 +1,15 @@
+= Summary
+
+In this chapter, you learned:
+
+* MicroShift rebuilds selected components of an OpenShift control plane as a single process, managed by Systemd.
+
+* MicroShift runs selected components of OpenShift, such as its Ingress controller and LVM Storage operator, using the same container images as Red Hat OpenShift.
+
+* You can install optional componments of MicroShift from RPM packages, including the Operator Lifecycle Manager (OLM), which then enables you to install add-on operators that are tested and supported on MicroShift.
+
+* Unlike Red Hat OpenShift, where you perform almost all day-to-day management of clusters and applications using Kubernetes APIs, deploying and managing MicroShift instances requires using common RHEL tools and processes.
+
+* If your edge deployment requires High Availability (HA), horizontal scalability to multi-node Kubernetes, or vertical scalability to server-class machines, consider the many editions and deployment factors of Red Hat OpenShift.
+
+* MicroShift should run most applications developmed and tested on Red Hat OpenShift unchanged, from the same container images, manigests, helm charts, and add-on operators.