tips-and-tricks.md

+- [Tips and tricks](#tips-and-tricks)
+  * [Kubernetes troubleshooting](#kubernetes-troubleshooting)
+    + [Get an overview](#get-an-overview)
+    + [Obtain node information](#obtain-node-information)
+    + [Open a terminal to a node](#open-a-terminal-to-a-node)
+    + [Open a terminal to a pod](#open-a-terminal-to-a-pod)
+  * [Kubernetes memory requirements dimensioning](#kubernetes-memory-requirements-dimensioning)
+  * [Grafana dashboard definition in the Kubernetes configuration](#grafana-dashboard-definition-in-the-kubernetes-configuration)
+  * [Providing ipv4 access to the Kubernetes master node](#providing-ipv4-access-to-the-kubernetes-master-node)
+    + [Introduction](#introduction)
+    + [Workaround step by step](#workaround-step-by-step)
+    + [A note on InfluxDB datasource definition in Grafana](#a-note-on-influxdb-datasource-definition-in-grafana)
+
 # Tips and tricks
 
 ## Kubernetes troubleshooting
@@ -75,6 +88,8 @@ as in **launch-experiment.sh** in the
   ```
 
 ## Providing ipv4 access to the Kubernetes master node
+
+### Introduction
 Any node on the virtual wall has a network interface with a public ipv6 address and a local ipv4 address.
 These can be found using the `ifconfig` command in a terminal window to a node.
 
@@ -118,7 +133,7 @@ The local ipv4 address of the Kubernetes master node is what `<KUBE_MASTER_IP>`
 This `<KUBE_MASTER_IP>` is accessible from your machine without further work, if you're connected to the iGent network.
 
 If not connected to the iGent network (and your network connection does not support ipv6), you need a public ipv4 address to talk to in the virtual wall.
-The virtual wall has different solutions, of which we'll select one below.
+The virtual wall has different solutions to provide a workaround.
 * Configure the Kubernetes master node (a bare metal server) to have a public ipv4 address.
   * We won't select this option, because it complicates the Kubernetes environment.
 We certainly do not want Kubernetes traffic over the public ipv4 address.
@@ -129,6 +144,7 @@ Note that there are issues with Kubernetes to select a network interface.
 This solution is based on the fact that all virtual wall nodes on the same wall can connect with each other.  
   * We'll select this option, because it leaves the original experiment unchanged. Follow the steps below.
   
+### Workaround step by step
 Do the next steps after the Kubernetes experiment was started and is up and running.
 
 In jFED, obtain the virtual wall node name of the Kubernetes master node, using the context menu `Show Node Info`.
@@ -176,6 +192,18 @@ ssh -N -f -L 8086:n079-01.wall1.ilabt.iminds.be:8086 -g localhost
  
 Finally, we can now access Grafana and InfluxDB from our local machine, by replacing `<KUBE_MASTER_IP>` with `<FORWARDER_IP>` in the normal instructions!
 
+### A note on InfluxDB datasource definition in Grafana
+In Grafana, there are two possibilities to define access to an InfluxDB data source:
+* "Server" (in the UI), `proxy` (in the configuration file): Grafana frontend code will access InfluxDB through the Grafana backend (this is the default)
+* "Browser" (in the UI), `direct` (in the configuration file): Grafana frontend code will access InfluxDB directly
+
+The second option is not compatible with our workaround without further work.
+
+The easiest and permanent solution is to change the access to `proxy` in the experiment configuration upfront.
+
+It is also possibe to modify the datasource settings in Grafana at runtime (if the datasource was set to editable in the configuration).
+In that case, you can either set the access type to "Server" or modify the InfluxDB IP address to `<FORWARDER_IP>`.
+