fixed typos

Author: llpeterson

arch.rst

@@ -130,11 +130,11 @@ the internal working of SD-RAN, SD-Core, and SD-Fabric.)
 .. _reading_5g:
 .. admonition:: Further Reading
 
-   `5G Mobile Networks: A Systems Approach
-   <https://5G.systemsapproach.org>`__
+   L. Peterson and O. Sunay. `5G Mobile Networks: A Systems Approach
+   <https://5G.systemsapproach.org>`__. March 2020.
 
-   `Software-Defined Networks: A Systems Approach
-   <https://sdn.systemsapproach.org>`__
+   L. Peterson, *et al.* `Software-Defined Networks: A Systems Approach
+   <https://sdn.systemsapproach.org>`__. November 2021.
 
 Once ACE is running in this configuration, it is ready to host a
 collection of edge applications (not shown in :numref:`Figure %s
@@ -537,7 +537,7 @@ subsystems to help make sense of it all.
 There are, in practice, many opportunities for interactions among the
 four components, and in some cases, there are overlapping concerns
 that lead to considerable debate. This is what makes operationalizing
-a cloud a thorny problem. For example, it's difficult to draw a crisp
+a cloud such a thorny problem. For example, it's difficult to draw a crisp
 line between where resource provisioning ends and lifecycle management
 begins. One could view provisioning as "Step 0" of lifecycle
 management. As another example, the runtime control and monitoring

control.rst

@@ -356,7 +356,7 @@ Helm charts already identify the version of each microservice (Docker
 Image) to be deployed. This means the version of the Runtime Control
 Helm chart effectively specifies the version of the Runtime Control
 API, since that API is auto-generated from the set of models, as we'll
-see in a the next subsection. All of this is to say that version
+see in the next subsection. All of this is to say that version
 control for the Northbound Interface of the cloud, as an aggregated
 whole, is managed in exactly the same way as version control for each
 functional building block that contributes to the cloud's internal
@@ -527,7 +527,7 @@ for distributing, revoking, and renewing certificates.
 
 For components that speak REST, HTTPS is used to secure the
 connection, and authentication can take place using mechanisms within
-the HTTPS protocol (basic auth, tokens, etc). Oath2 and OpenID Connect
+the HTTPS protocol (basic auth, tokens, etc). Oauth2 and OpenID Connect
 are leveraged as an authorization provider when using these REST APIs.
 
 5.3 Modeling Connectivity Service
@@ -776,8 +776,8 @@ isolating a distinct traffic flow.
 .. _reading_sdn:
 .. admonition:: Further Reading
 
-   `Software-Defined Networks: A Systems Approach
-   <https://sdn.systemsapproach.org>`__
+   L. Peterson, *et al.* `Software-Defined Networks: A Systems Approach
+   <https://sdn.systemsapproach.org>`__. November 2021.
 
 5.4 Revisiting GitOps
 ---------------------

foreword.rst

@@ -9,7 +9,7 @@ As markets grow, the unit of function around which one can build a
 business shrinks. A classic example of this can be seen in the history
 of the automotive industry. The Ford River Rouge Complex was built in
 the late 1920s. At the time, mass-produced cars were relatively new,
-and the market relatively small. And so factories like the River Rouge
+and the market was relatively small. And so factories like the River Rouge
 Complex had to build all the subcomponents too. Roughly, in one side
 of the factory went water, rubber, and iron ore, and out the other
 side came full automobiles. Of course, as the market for cars grew, so

intro.rst

@@ -61,7 +61,7 @@ available open source software packages.
   operationalizes (activates) their code. It is common to focus on the
   former and view the latter as a burden (especially if someone else
   will be responsible for deploying and operating their code), but
-  coding to the mangement platform interface is a central part of the
+  coding to the management platform interface is a central part of the
   contract for delivering a managed service. Understanding and
   appreciating the "hows" and "whys" of this platform is critical to
   developers doing their job.*
@@ -290,11 +290,11 @@ process of operationalizing the devices they sell, which in turn
 dictates how network operators and enterprise system admins bring
 those devices online. While the general framework has been extended to
 Virtual Network Functions (VNFs), it is still a device-centric view of
-operations. But once a system becomes cloud native, two things happen
-that shift the balance of concerns. First, all hardware is commodity,
-and so Days 0 and 1 configurations become fully automated (and Day -1
-is minimized since all devices are identical).\ [#]_ Second, Day 2
-operations become a much more sophisticated process. This is because
+operations. But once a system becomes cloud native, two things shift
+the balance of concerns. First, all hardware is commodity, and so Days
+0 and 1 configurations become fully automated (and Day -1 is minimized
+since all devices are identical).\ [#]_ Second, Day 2 operations
+become a much more sophisticated process. This is because
 software-based systems are more agile, making functional upgrades more
 commonplace. This focus on *feature velocity* is one of the inherent
 values of cloud-based systems, but not surprisingly, it brings its own

lifecycle.rst

@@ -444,7 +444,7 @@ principle then, you could define a single CI/CD pipeline for the
 entire system. It would start with "Build" stage, followed by a "Test"
 stage, and then conditional upon success, conclude with a "Deliver"
 stage. But this approach doesn't take into account the loose coupling
-of all the components that go into a building a cloud. Instead, what
+of all the components that go into building a cloud. Instead, what
 happens in practice is that Jenkins is used more narrowly to (1)
 build and test individual components, both before and after they are
 merged into the code repository; (2) integrate and test various
@@ -667,7 +667,7 @@ curated set of services.
 The CI/CD toolchain introduced in this chapter works only when applied
 in concert with an end-to-end versioning strategy, ensuring that the
 right combination of source modules get integrated, and later, the
-right combination of images get deployed. Remember, the high-level
+right combination of images gets deployed. Remember, the high-level
 challenge is to manage the set of features that our cloud supports,
 which is another way of saying that everything hinges on how we
 version those features.
@@ -751,7 +751,7 @@ sanity tests that catch obvious mistakes, responsibility ultimately
 falls to the developers checking in source code and the operators
 checking in configuration code; they must correctly specify the
 versions they intend. Having a simple and clear versioning strategy is
-a pre-requisite for doing that job.
+a prerequisite for doing that job.
 
 Finally, because versioning is inherently related to APIs, with the
 *MAJOR* version number incremented whenever the API changes in a
@@ -774,7 +774,7 @@ The discussion up this point has glossed over one important detail,
 which is how secrets are managed. These include, for example, the
 credentials Terraform needs to access remote services like GCP, as
 well as the keys used to secure communication among microservices
-within a edge cluster. Such secrets are effectively part of the hybrid
+within an edge cluster. Such secrets are effectively part of the hybrid
 cloud's configuration state, which would imply they are stored in the
 Config Repo, like all other Configuration-as-Code artifacts. But
 repositories are typically not designed to be secure, which is

monitor.rst

@@ -474,11 +474,11 @@ general strategies.
 First, both Kibana and Grafana can be configured to display telemetry
 data from multiple sources. For example, it is straightforward to
 integrate both logs and traces in Kibana. This is typically done by
-first feeding the tracing data into Elastic Search, which Kibana then
+first feeding the tracing data into ElasticSearch, which Kibana then
 queries. Similarly, it is useful to have a convenient way to see the
 log messages associated with a particular component in the context of
 metrics that have been collected. This is easy to accomplish because
-Grafana can be configured to display data from Elastic Search just as
+Grafana can be configured to display data from ElasticSearch just as
 easily as from Prometheus. Both are data sources that can be
 queried. This makes it to possible to create a Grafana dashboard that
 includes a selected set of log messages, similar to the one from

preface.rst

@@ -55,12 +55,16 @@ Intended Audience
 We hope this book makes valuable reading for anyone who is trying to
 stand up and operationalize their own edge cloud infrastructure, but
 we also aim to provide useful information for at least two other broad
-groups. First, there will be a set of readers who need to evaluate the
+groups.
+
+First, there will be a set of readers who need to evaluate the
 options available, particularly to decide between using the cloud
 services offered by one of the hyperscalers or building their own edge
 cloud (or some combination of these). We hope to demystify the
 landscape of edge clouds for this audience to help inform those
-decisions. Secondly, there will be a group of application and service
+decisions.
+
+Secondly, there will be a group of application and service
 developers who need to build on top of whatever cloud infrastructure
 their organization has chosen to use. We believe it is important for
 these developers to understand what goes on "under the hood" of the
@@ -129,5 +133,5 @@ comments using the `Issues Link
 list we're currently working on.
 
 | Larry Peterson, Scott Baker, Andy Bavier, Zack Williams, and Bruce Davie
-| October 2021
+| June 2022
 

provision.rst

@@ -23,7 +23,7 @@ When a cloud is built from virtual resources (e.g., VMs instantiated
 on a commercial cloud) the "rack and connect" step is carried out by a
 sequence of API calls rather than a hands-on technician.  Of course,
 we want to automate the sequence of calls needed to activate virtual
-infrastructure, which has inspired an approach know as
+infrastructure, which has inspired an approach known as
 *Infrastructure-as-Code*, a special case of the
 *Configuration-as-Code* concept introduced in Chapter 2. The general
 idea is to document, in a declarative format that can be "executed",
@@ -125,7 +125,7 @@ is NetBox. It supports IP address management (IPAM); inventory-related
 information about types of devices and where they are installed; how
 infrastructure is organized (racked) by group and site; and how
 devices are connected to consoles, networks, and power sources. More
-information is readily available on the NetBox web site:
+information is readily available on the NetBox web site.
 
 .. _reading_netbox:
 .. admonition:: Further Reading
@@ -217,7 +217,7 @@ purposes:
 There are other edge prefixes used by Kubernetes, but they do not need
 to be created in NetBox. Note that ``qsfp0`` and ``qsfp1`` in this
 example denote transceiver ports connecting the switching fabric,
-where *QSFP* stand for Quad (4-channel) Small Form-factor Pluggable.
+where *QSFP* stands for Quad (4-channel) Small Form-factor Pluggable.
 
 With this site-wide information recorded, the next step is to install
 and document each *Device*. This includes entering a ``<devname>``,
@@ -403,7 +403,7 @@ paired with Netplan to configure kernel-level details, there is also
 an Ansible playbook that installs Docker on each compute server and
 fabric switch, and then launches a Docker container running a
 "finalize" image. This image makes calls into the next layer of the
-provisioning stack, effectively signalling that the cluster is running and
+provisioning stack, effectively signaling that the cluster is running and
 ready for further instructions. We are now ready to describe that next
 layer of the stack.
 
@@ -496,7 +496,7 @@ physical machine, but using virtualization mechanisms like KVM and
 Proxmox. There is no need for a full-fledged IaaS mechanism, such as
 OpenStack. These VMs would then be recorded as first-class cloud
 resource in NetBox and the other tools described in this section, no
-different than a physical machine.
+different from a physical machine.
 
 The unanswered question is why one might decide to do that,
 considering that Kubernetes already allows us to deploy multiple