diff --git a/docs/controlkube_scenario.md b/docs/controlkube_scenario.md
index c7108c4..7f5d206 100644
--- a/docs/controlkube_scenario.md
+++ b/docs/controlkube_scenario.md
@@ -23,7 +23,7 @@
 You should run the following commands on a clean Linux machine in the
 home directory to install this scenario:
 
-```
+```shell
 # Pull down cord-bootstrap.sh script and start a tmux session
 curl -o ~/cord-bootstrap.sh \
 https://raw.githubusercontent.com/opencord/cord/{{ book.branch }}/scripts/cord-bootstrap.sh
@@ -31,7 +31,7 @@
 tmux
 ```
 
-```
+```shell
 # Install CORD with kubernetes and XOS Helm chart (this is a single command wordwrapped)
 time bash ./cord-bootstrap.sh -v -x -t "PODCONFIG=rcord-controlkube.yml config" \
 -t "build" |& tee -a ~/setup.log
diff --git a/docs/install.md b/docs/install.md
index bdfd28f..59e46e4 100644
--- a/docs/install.md
+++ b/docs/install.md
@@ -33,7 +33,7 @@
 - [Docker](https://www.docker.com/community-edition), for *local* build
   scenarios, *tested with Community Edition version 17.06*
 - [Vagrant](https://www.vagrantup.com/downloads.html), for all other scenarios
-  *tested with version 1.9.3, requires specific plugins and modules if using
+  *tested with version 2.0.1, requires specific plugins and modules if using
   with libvirt, see `cord-bootstrap.sh` for more details *
 
 You can manually install these on your development system - see [Getting the
@@ -118,29 +118,33 @@
 ### POD Config
 
 Each CORD *use-case* (e.g., R-CORD, M-CORD, E-CORD) has its own repository
-containing configuration files for that type of POD.  All of these
-repositories appear in the source tree under `orchestration/profiles/`.
-For example, R-CORD's repository is
-[orchestration/profiles/rcord](https://github.com/opencord/rcord/tree/{{ book.branch }}).
+containing configuration files for that type of POD.  All of these repositories
+appear in the source tree under `orchestration/profiles/`.  For example,
+R-CORD's repository is
+[orchestration/profiles/rcord](https://github.com/opencord/rcord/tree/{{
+  book.branch }}).
 
-The top level configuration for a build is the *POD config* file, a
-YAML file stored in each use-case repository's `podconfig` subdirectory.
-Each Pod config file contains a list of variables that control how
-the build proceeds, and can override the configuration of the rest of the
-build.  A minimal POD config file must define two variables:
+The top level configuration for a build is the *POD config* file, a YAML file
+stored in each use-case repository's `podconfig` subdirectory.  Each Pod config
+file contains a list of variables that control how the build proceeds, and can
+override the configuration of the rest of the build.  A minimal POD config file
+must define two variables:
 
 `cord_scenario` - the name of the *scenario* to use, which is defined in a
-directory under [build/scenarios](https://github.com/opencord/cord/tree/{{ book.branch }}/scenarios).
+directory under [build/scenarios](https://github.com/opencord/cord/tree/{{
+  book.branch }}/scenarios).
 
-`cord_profile` - the name of a *profile* to use, defined as a YAML file at
-the top level of the use-case repository - ex:
-[mcord-ng40.yml](https://github.com/opencord/mcord/blob/{{ book.branch }}/mcord-ng40.yml).
+`cord_profile` - the name of a *profile* to use, defined as a YAML file at the
+top level of the use-case repository - ex:
+[mcord-ng40.yml](https://github.com/opencord/mcord/blob/{{ book.branch
+}}/mcord-ng40.yml).
 
-The naming convention for POD configs stored in the use case
-repository is `<profile>-<scenario>.yml` - ex:
-[mcord-ng40-virtual.yml](https://github.com/opencord/mcord/blob/{{ book.branch }}/podconfig/mcord-ng40-virtual.yml) builds the `virtual` scenario using the
-`mcord-ng40` profile.  All such POD configs can be specified during a
-build using the `PODCONFIG` variable:
+The naming convention for POD configs stored in the use case repository is
+`<profile>-<scenario>.yml` - ex:
+[mcord-ng40-virtual.yml](https://github.com/opencord/mcord/blob/{{ book.branch
+}}/podconfig/mcord-ng40-virtual.yml) builds the `virtual` scenario using the
+`mcord-ng40` profile.  All such POD configs can be specified during a build
+using the `PODCONFIG` variable:
 
 ```shell
 make PODCONFIG=rcord-virtual.yml config
diff --git a/docs/install_physical.md b/docs/install_physical.md
index 34ad577..80a4afd 100644
--- a/docs/install_physical.md
+++ b/docs/install_physical.md
@@ -316,12 +316,12 @@
 the external and the internal networks, what users the system should run during
 the automated installation, and much more.
 
-POD configuration files are YAML files with extension .yml. You can either create a new
-file with your favorite editor or copy-and-edit an existing file. The
-[physical-example.yml](https://github.com/opencord/cord/blob/{{ book.branch }}/podconfig/physical-example.yml)
-configuration file is there for this purpose, and the most commonly set
-parameters are described. Optional lines have been commented out, but can be
-used as needed.
+POD configuration files are YAML files with extension .yml. You can either
+create a new file with your favorite editor or copy-and-edit an existing file.
+The [physical-example.yml](https://github.com/opencord/cord/blob/{{ book.branch
+}}/podconfig/physical-example.yml) configuration file is there for this
+purpose, and the most commonly set parameters are described. Optional lines
+have been commented out, but can be used as needed.
 
 More information about how the network configuration for the POD can be
 customized can be found in [Network Settings](appendix_network_settings.md).
diff --git a/docs/release-notes/satisfying-cactus.md b/docs/release-notes/satisfying-cactus.md
index f5cb0e3..de0102b 100644
--- a/docs/release-notes/satisfying-cactus.md
+++ b/docs/release-notes/satisfying-cactus.md
@@ -8,33 +8,32 @@
 ## Platform and Build System
 
 * Added support for dynamically loading new services and service profiles into
-a running system. R-CORD and E-CORD services converted to use new
-dynamic loading mechanism, but M-CORD still uses `corebuilder`.
+  a running system. R-CORD and E-CORD services converted to use new dynamic
+  loading mechanism, but M-CORD still uses `corebuilder`.
 
-* Refactored build to isolate profile-specific information (e.g., models,
-TOSCA templates). R-CORD, M-CORD, and E-CORD converted to use
-refactoring.
+* Refactored build to isolate profile-specific information (e.g., models, TOSCA
+  templates). R-CORD, M-CORD, and E-CORD converted to use refactoring.
 
-* Added support for logging and diagnostics. See the
-[Logging and Diagnostics](../operate/elk_stack.md) section of the
-guide for more information.
+* Added support for logging and diagnostics. See the [Logging and
+  Diagnostics](../operate/elk_stack.md) section of the guide for more
+  information.
 
 * Added new scenarios to build:
 
-  * `preppedpod`: Installs a CORD POD without MaaS on pre-prepared systems,
-  which can run the R-CORD test suite.
+    * `preppedpod`: Installs a CORD POD without MaaS on pre-prepared systems,
+      which can run the R-CORD test suite.
 
-  * `controlpod`: Installs XOS and ONOS without VNF support. Runs on Ubuntu
-16.04 in preparation for updating the entire CORD platform.
+    * `controlpod`: Installs XOS and ONOS without VNF support. Runs on Ubuntu
+      16.04 in preparation for updating the entire CORD platform.
 
-  * `controlkube`: Preliminary support for running XOS on Kubernetes, in preparation
-  for greater functionality in the next release.
+    * `controlkube`: Preliminary support for running XOS on Kubernetes, in
+      preparation for greater functionality in the next release.
 
 * Preliminary integration of Kubernetes into CORD (pre-alpha):
 
-  * Manages XOS containers
+    * Manages XOS containers
 
-  * Works with `controlkube` Scenario
+    * Works with `controlkube` Scenario
 
 * Removed old TOSCA Engine.
 
@@ -57,3 +56,4 @@
 ## E-CORD
 
 * Automated Monitoring at EVC creation
+