changes for 0.6 (#428)

.versions

@@ -1,2 +1,2 @@
 #!/bin/bash
-export IMAGE_TAG=0.5.0
+export IMAGE_TAG=0.6.0

docs/howtos/latencyserver.md

@@ -5,14 +5,35 @@ parent: How to's
 nav_order: 3
 ---
 
-# How to measure latency
+# How to measure latency to various regions
 
-If you have multiple Thundernetes clusters on different regions, it might be useful to have a way to measure latency to these clusters. For this, we implemented a basic UDP echo server based on PlayFab's Quality of Service Server, you can check both the [C++ implementation](https://github.com/PlayFab/XPlatCppSdk/blob/master/code/source/playfab/QoS/PlayFabQoSApi.cpp) and the [C# implementation](https://github.com/PlayFab/CSharpSDK/blob/master/PlayFabSDK/source/Qos/PlayFabQosApi.cs).This server follows these simple rules:
+You can deploy Thundernetes to more than one regions. There are two reasons to do this:
+
+- Additional regions provide redundancy. If a single region fails, players can access servers in other regions.
+- Additional regions allow players to access servers that are "nearby" and deliver low-latency connectivity.
+
+If you have multiple Thundernetes clusters on different regions, it is useful to have a way to measure latency from the client device (e.g. console/PC) to these clusters. For this purpose, we  have implemented a basic UDP echo server based on PlayFab's Quality of Service Server. This server follows these simple rules:
 
 - The server only accepts UDP requests, and the data must be 32 bytes max and must also start with 0xFFFF (1111 1111 1111 1111).
 - If the requests are valid, the server will respond with the same data it received, but with the first 4 bytes flipped to 0x0000 (0000 0000 0000 0000).
 
-In [Thundernetes' main repository](https://github.com/PlayFab/thundernetes/tree/main/cmd/latencyserver) you can find the code for the server and a Dockerfile to build the image. We also provide 2 example YAML files: one for [deploying the server](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/latencyserver.yaml), and another for [deploying a ServiceMonitor](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/monitor.yaml) to crawl the [prometheus metrics](./monitoring.md). All you have to do is run:
+The usage of UDP is important, because most multiplayer games use UDP transport for their most performance-critical game traffic. Internet service providers and other elements of the Internet ecosystem may deliver differentiated performance for UDP vs TCP vs ICMP flows.
+
+For client code, you can check the [C++ implementation](https://github.com/PlayFab/XPlatCppSdk/blob/master/code/source/playfab/QoS/PlayFabQoSApi.cpp) and the [C# implementation](https://github.com/PlayFab/CSharpSDK/blob/master/PlayFabSDK/source/Qos/PlayFabQosApi.cs).
+
+## Flow
+
+This is the typical flow for using the latency server in the context of a player device:
+
+- Create a UDP socket.
+- For each region, send a single UDP datagram to port 3075 on the latency server. The message content must start with 0xFFFF (1111 1111 1111 1111).
+- The server will reply with a single datagram, with the message contents having the first 2 bytes "flipped" to 0x0000 (0000 0000 0000 0000). The rest of the datagram contents will be copied from the initial ping.
+- Measure the time between sending the UDP message and receiving a response.
+- Sort the response times from lowest to highest, and request a GameServer in the region with the lowest latency.
+
+## Deploying the latency server
+
+In [Thundernetes' main repository](https://github.com/PlayFab/thundernetes/tree/main/cmd/latencyserver) you can find the code for the server and a Dockerfile to build the image. We also provide 2 example YAML files: one for [deploying the server](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/latencyserver.yaml), and another for [deploying a ServiceMonitor](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/monitor.yaml) to grab the [prometheus metrics](./monitoring.md). All you have to do is run:
 
 {% include code-block-start.md %}
 # for the latency server
@@ -23,7 +44,3 @@ kubectl apply -f https://raw.githubusercontent.com/PlayFab/thundernetes/main/sam
 {% include code-block-end.md %}
 
 The UDP server runs on the port defined by the `UDP_SERVER_PORT` environment variable. A prometheus `/metrics` endpoint is also exposed, on the port defined by the `METRICS_SERVER_PORT` environment variable, with a counter for the number of successful requests it has received.
-
-## Deploying the latency server
-
-You can find the deployment YAML file [here](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/latencyserver.yaml) and the corresponding ServiceMonitor file [here](https://github.com/PlayFab/thundernetes/blob/main/samples/latencyserver/monitor.yaml).

docs/howtos/uninstallthundernetes.md

@@ -7,7 +7,7 @@ nav_order: 15
 
 ## Uninstalling Thundernetes
 
-You should first remove all your GameServerBuilds. Since each GameServer has a finalizer, removing the controller before removing GameServer instances will make the GameServer instances get stuck if you try to delete them.
+You should first remove all your GameServerBuilds. This will remove all GameServers and the corresponding Pods.
 
 {% include code-block-start.md %}
 kubectl delete gsb --all -A # this will delete all GameServerBuilds from all namespaces, which in turn will delete all GameServers

docs/troubleshooting/controllernodeagent.md

@@ -2,7 +2,7 @@
 layout: default
 title: Controller/NodeAgent logs
 parent: Troubleshooting
-nav_order: 4
+nav_order: 3
 ---
 
 # How can I get access to the controller and the NodeAgent logs and status? 

docs/troubleshooting/defaultportinuse.md

@@ -1,17 +1,17 @@
 ---
 layout: default
-title: Port 5000 is already in use
+title: Controller port 5000
 parent: Troubleshooting
-nav_order: 5
+nav_order: 4
 ---
 
-# How can I change the port that Thundernetes uses?
+# How can I change the port that Thundernetes uses for the Allocation API service?
 
-By default, Thundernetes's Allocation API listens on port 5000 which is opened with the kind config set-up [here](../quickstart/installing-kind.md). This port can already be in use by another service thus causing Thundernetes to fail.
+By default, Thundernetes's Allocation API service listens on port 5000. Locally, it opens with the kind config set-up [here](../quickstart/installing-kind.md). This port can already be in use by another service thus causing Thundernetes to fail.
 
 ## Kind Changes
 
-The first step (if using kind) is changing the `kind-config.yaml` to use the desired port. For example:
+To use an alternate port, the first step is changing the `kind-config.yaml` to use the desired port. For example:
 
 {% include code-block-start.md %}
 kind: Cluster

docs/troubleshooting/stuckgameserver.md

@@ -2,7 +2,7 @@
 layout: default
 title: Game server is stuck
 parent: Troubleshooting
-nav_order: 2
+nav_order: 1
 ---
 
 # What should we do if a GameServer gets stuck? 
@@ -13,4 +13,4 @@ If you want to delete the Pod, you can use the kubectl command `kubectl delete g
 
 ❗ Do not directly delete the Pod. It will be deleted automatically when the GameServer is deleted.
 
-❗ Do not manually overwrite GameServer.status details, this will create issues during controller reconciliation. 
+❗ Do not manually overwrite GameServer.status fields, this will create issues during controller reconciliation. 

docs/troubleshooting/stuckinitializing.md

@@ -2,10 +2,10 @@
 layout: default
 title: Game Server does not transition to StandingBy state
 parent: Troubleshooting
-nav_order: 3
+nav_order: 2
 ---
 
-# My GameServer state stays in empty or Initializing state and does not transition into StandingBy
+# GameServer state stays in empty or Initializing state and does not transition into StandingBy
 
 ❗ Check [here](../gsdk/gameserverlifecycle.md) for more information on GameServer lifecycle.