Merge pull request #85 from eclipse-iofog/develop

Minor fixes and improvements for 1.3.0 documentation - Helm and Tutorial

Author: lkrcal

content/docs/1.3.0/tools/how-to-helm.md

@@ -6,7 +6,7 @@ IoFog Helm chart allows users to easily deploy the ioFog stack onto exiting Kube
 
 ## Prerequisites
 
-First, we need a working Kubernetes cluster. WE can simply set up a cluster on the Google Kubernetes Engine (GKE) by following the [Creating a cluster tutorial](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-cluster). Using any other managed cluster providers works as well, so do custom installations of Kubernetes, e.g. Minikube.
+First, we need a working Kubernetes cluster. We can simply set up a cluster on the Google Kubernetes Engine (GKE) by following the [Creating a cluster tutorial](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-cluster). Using any other managed cluster providers works as well, so do custom installations of Kubernetes, e.g. Minikube.
 
 IoFog also provides [tools for infrastructure setup](https://github.com/eclipse-iofog/platform) to setup a Kubernetes cluster in case we don't have one available. Please see [Platform Tools](./platform-tools.html) for more details.
 
@@ -74,7 +74,12 @@ helm repo add iofog https://eclipse-iofog.github.io/helm
 
 We can list all available versions of the ioFog Helm chart using `helm search -l iofog/iofog`.
 
-To install a specific version of ioFog, use `helm install`:
+To install a specific version of ioFog, use `--version <desired-version>` parameter to `helm install`
+
+_Keep in mind if there already is any existing ioFog stack on the cluster, a set of Custom Resource Definitions has probably already been created. In such case, you will need to disable deploying these CRDs as described in [Multiple Edge Compute Networks](#multiple-edge-compute-networks)._
+
+The final `helm install` command to install ioFog with CRDs then looks like this:
+
 
 ```bash
 helm install \
@@ -86,7 +91,9 @@ helm install \
     iofog/iofog
 ```
 
-To list all Helm releases, we can simply run `helm list`. The result should look like this:
+The `--name my-ecn` refers to the Helm release name as shown below, while the `--namespace my-ecn` refers to the namespace taken by the Helm release in the target Kubernetes cluster.
+
+To list all Helm releases (including deployed ioFog stacks), we can simply run `helm list`. The result should look like this:
 
 ```plain
 NAME      	REVISION	UPDATED                 	STATUS  	CHART          	    APP VERSION	NAMESPACE
@@ -98,10 +105,10 @@ The following is a complete list of all user configurable properties for the ioF
 | Property                                | Default value                   | Description                                                                                   |
 | --------------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------- |
 | createCustomResources                   | true                            | See [Multiple Edge Compute Networks](#multiple-edge-compute-networks)                         |
-| controlPlane.userfirstName              | First                           | First name of initial user in Controller                                                      |
-| controlPlane.usersurname                | Second                          | Surname of initial user in Controller                                                         |
-| controlPlane.useremail                  | [email protected]                 | Email (login) of initial user in Controller                                                   |
-| controlPlane.userpassword               | H23fkidf9hoibf2nlk              | Password of initial user in Controller                                                        |
+| controlPlane.user.firstName             | First                           | First name of initial user in Controller                                                      |
+| controlPlane.user.surname               | Second                          | Surname of initial user in Controller                                                         |
+| controlPlane.user.email                 | [email protected]                 | Email (login) of initial user in Controller                                                   |
+| controlPlane.user.password              | H23fkidf9hoibf2nlk              | Password of initial user in Controller                                                        |
 | controlPlane.database.provider          |                                 | Not supported in ioFog Community Edition                                                      |
 | controlPlane.database.host              |                                 | Not supported in ioFog Community Edition                                                      |
 | controlPlane.database.port              | 0                               | Not supported in ioFog Community Edition                                                      |

content/docs/1.3.0/tutorial/deploy-our-microservice.md

@@ -254,7 +254,8 @@ Sensors		    RUNNING		local-agent	{}			            Moving Average
 
 ## Conclusion
 
-Have a look at new output of the Freeboard at <a href="http://localhost:10102/?load=dashboard.json" target="_blank">http://localhost:10102/?load=dashboard.json</a>. This should now display the values modified by moving average.
+Have a look at new output of the [Freeboard dashboard](http://localhost:10102/?load=dashboard.json). This should now display the values modified by moving average and look similar to this:
+<img src="/images/Freeboard_2.png" style="max-width:100%;border-radius: 0.3em;margin: 35px 0;" />
 
 The magic about microservices and ioFog is that none of those microservice is specifically designed or requires to work with the other microservice. Using ioFog, you can create smart and secure communication channels between independant microservices and easily manage a fleet of Edge devices and microservices.
 

content/docs/1.3.0/tutorial/manage-our-microservices.md

@@ -33,6 +33,9 @@ The _REST API_ is a generic microservice that provides a REST API web server, al
 
 _Freeboard_ is the last microservice that provides an HTML dashboard to view the real-time results coming from a rest API data source. In the case of our tutorial, the source of the data is our REST API microservice.
 
+Currently, loading the [freeboard dashboard](http://localhost:10102/?load=dashboard.json) should look similar to this:
+<img src="/images/Freeboard_1.png" style="max-width:100%;border-radius: 0.3em;margin: 35px 0;" />
+
 ## Routes
 
 The Sensors and REST API microservices are generic. They are not hardcoded to talk with each other, instead, the relationship dictating the flow of data was configured with the Controller. This is in the spirit of the microservice architecture, separating concerns into pieces so that we can combine and interchange them.