have 5.0 docs pass jenkins lint check
Change-Id: I050c171c54172953e4ea5e6334f7004c7d2782a7
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
+