Merge "Adding offline installation docs"
diff --git a/SUMMARY.md b/SUMMARY.md
index 5ad8044..115f433 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -38,6 +38,7 @@
* [XOSSH](charts/xossh.md)
* [Logging and Monitoring](charts/logging-monitoring.md)
* [Persistent Storage](charts/storage.md)
+ * [BBSim](charts/bbsim.md)
* [Operations Guide](operating_cord/operating_cord.md)
* [General Info](operating_cord/general.md)
* [GUI](operating_cord/gui.md)
diff --git a/charts/bbsim.md b/charts/bbsim.md
new file mode 100644
index 0000000..cabc6c6
--- /dev/null
+++ b/charts/bbsim.md
@@ -0,0 +1,53 @@
+# BBSim Helm Chart
+
+This chart let you install the broadband simulator.
+Note that this chart depends on [kafka](kafka.md)
+
+```shell
+helm install -n bbsim bbsim
+```
+
+## Set a different number of ONUs
+
+You can configure the number of ONUs trough a parameter in the installation:
+
+```shell
+helm install -n bbsim bbsim --set onus_per_pon_port={number_od_onus}
+```
+
+## Set a different mode
+
+By default BBSim will bring up a certain number of ONUs and the start sending
+authentication requests, via EAPOL, and DHCP requests.
+
+You can change the behaviour via:
+
+```shell
+helm install -n bbsim bbsim --set emulation_mode="{both|aaa|default}"
+```
+
+Where:
+
+- `both` stands for authentication and DHCP
+- `aaa` stands for authentication only
+- `default` will just activate the devices
+
+## Start BBSim without Kafka
+
+Kafka is used to aggregate the logs in CORD's [logging](logging-monitoring.md)
+framework.
+
+If you want to start BBSim without pushing the logs to kafka, you can install it
+with:
+
+```shell
+helm install -n bbsim bbsim --set kafka_broker=""
+```
+
+## Provision the BBSim OLT in NEM
+
+You can use this file to bring up the BBSim OLT in NEM: [bbsim-16.yaml](https://github.com/opencord/pod-configs/blob/master/tosca-configs/bbsim/bbsim-16.yaml).
+
+Note that in that file there is a bit of configuration for the `dhcpl2relay` application
+in ONOS that instructs it to send DHCP packet back to the OLT. This may differ
+from a POD where you are sending those packets out of the fabric.
\ No newline at end of file
diff --git a/charts/voltha.md b/charts/voltha.md
index 26641a0..05e748c 100644
--- a/charts/voltha.md
+++ b/charts/voltha.md
@@ -12,30 +12,33 @@
helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
```
+Install the etcd-operator helm chart. This chart provides a convenient way of creating and managing etcd clusters. When voltha installs it will attempt to use etcd-operator to create its etcd cluster. Once installed etcd-operator can be left running.
+
+```shell
+helm install -n etcd-operator stable/etcd-operator --version 0.8.0
+```
+
+Allow etcd-operator enough time to create the EtdCluster CustomResourceDefinitions. This should only be a couple of seconds after the etcd-operator pods are running. Check the CRD are ready by running the following:
+
+```shell
+kubectl get crd | grep etcd
+```
+
+
+
Update dependencies within the voltha chart:
```shell
helm dep up voltha
```
-There is an `etcd-operator` **known bug** that prevents deploying
-Voltha correctly the first time. We suggest the following workaround:
-
-First, install Voltha without an `etcd` custom resource definition:
+Install the voltha helm chart. This will create the voltha pods and additionally create the etcd-cluster pods
```shell
-helm install -n voltha --set etcd-operator.customResources.createEtcdClusterCRD=false voltha
+helm install -n voltha voltha
```
-Then upgrade Voltha, which defaults to using the `etcd` custom
-resource definition:
-
-```shell
-helm upgrade --set etcd-operator.customResources.createEtcdClusterCRD=true voltha ./voltha
-```
-
-After this first installation, you can use the standard
-install/uninstall procedure described below.
+Allow enough time for the 3 etcd-cluster pods to start before using the voltha pods.
## Standard Uninstall
@@ -89,11 +92,32 @@
```yaml
# voltha-values.yaml
-envoyForEtcdImage: 'voltha/voltha-envoy:dev'
-netconfImage: 'voltha/voltha-netconf:dev'
-ofagentImage: 'voltha/voltha-ofagent:dev'
-vcliImage: 'voltha/voltha-cli:dev'
-vcoreImage: 'voltha/voltha-voltha:dev'
+images:
+ vcore:
+ repository: '192.168.99.100:30500/voltha-voltha'
+ tag: 'dev'
+ pullPolicy: 'Always'
+
+ vcli:
+ repository: '192.168.99.100:30500/voltha-cli'
+ tag: 'dev'
+ pullPolicy: 'Always'
+
+ ofagent:
+ repository: '192.168.99.100:30500/voltha-ofagent'
+ tag: 'dev'
+ pullPolicy: 'Always'
+
+ netconf:
+ repository: '192.168.99.100:30500/voltha-netconf'
+ tag: 'dev'
+ pullPolicy: 'Always'
+
+ envoy_for_etcd:
+ repository: '192.168.99.100:30500/voltha-envoy'
+ tag: 'dev'
+ pullPolicy: 'Always'
+
```
and you can install VOLTHA using:
diff --git a/prereqs/k8s-multi-node.md b/prereqs/k8s-multi-node.md
index 841cb67..95791eb 100644
--- a/prereqs/k8s-multi-node.md
+++ b/prereqs/k8s-multi-node.md
@@ -89,7 +89,7 @@
on the remote machines.
The configuration file to access the POD will be saved in the
-sub-directory *configs/onf.conf*.
+sub-directory *inventories/onf/artifacts/admin.conf*.
If you want to deploy another POD without affecting your existing
deployment run the following: