Fix merge conflict

.gitignore

@@ -26,6 +26,7 @@ populations
 
 # Discarded code snippets
 build.sh
+*-fast.yaml
 
 # Dotnet Core ignores
 *.swp

CHANGELOG.md

@@ -1,6 +1,6 @@
 # Release history
 
-##v0.2.0 RC2 (alpha)
+##v0.2.0 (alpha)
   This is a pretty large update.  Custom MMFs or evaluators from 0.1.0 may need some tweaking to work with this version. Some Backend API function arguments have changed. Please join the [Slack channel](https://open-match.slack.com/) if you need help ([Signup link](https://join.slack.com/t/open-match/shared_invite/enQtNDM1NjcxNTY4MTgzLWQzMzE1MGY5YmYyYWY3ZjE2MjNjZTdmYmQ1ZTQzMmNiNGViYmQyN2M4ZmVkMDY2YzZlOTUwMTYwMzI1Y2I2MjU))!
 
   v0.2.0 focused on adding additional functionality to Backend API calls and on **reducing the amount of boilerplate code required to make a custom Matchmaking Function**.  For this, a new internal API for use by MMFs called the [Matchmaking Logic API (MMLogic API)](README.md#matchmaking-logic-mmlogic-api) has been added.  Many of the core components and examples had to be updated to use the new Backend API arguments and the modules to support them, so we recommend you rebuild and redeploy all the components to use v0.2.0. 

README.md

@@ -1,20 +1,18 @@
 # Open Match
 
-Open Match is an open source game matchmaker designed to allow game creators to re-use a common matchmaker framework. It’s designed to be flexible (run it anywhere Kubernetes runs), extensible (match logic can be customized to work for any game), and scalable.
+Open Match is an open source game matchmaking framework designed to allow game creators to re-use a common matchmaker framework. It’s designed to be flexible (run it anywhere Kubernetes runs), extensible (match logic can be customized to work for any game), and scalable.
 
 Matchmaking is a complicated process, and when large player populations are involved, many popular matchmaking approaches touch on significant areas of computer science including graph theory and massively concurrent processing. Open Match is an effort to provide a foundation upon which these difficult problems can be addressed by the wider game development community. As Josh Menke — famous for working on matchmaking for many popular triple-A franchises — put it:
 
 ["Matchmaking, a lot of it actually really is just really good engineering. There's a lot of really hard networking and plumbing problems that need to be solved, depending on the size of your audience."](https://youtu.be/-pglxege-gU?t=830)
 
-
 This project attempts to solve the networking and plumbing problems, so game developers can focus on the logic to match players into great games.
 
 ## Disclaimer
-This software is currently alpha, and subject to change. **It is not yet ready to be used in production.**
+This software is currently alpha, and subject to change.  Although Open Match has already been used to run [production workloads within Google](https://cloud.google.com/blog/topics/inside-google-cloud/no-tricks-just-treats-globally-scaling-the-halloween-multiplayer-doodle-with-open-match-on-google-cloud), but it's still early days on the way to our final goal. There's plenty left to write and we welcome contributions. **We strongly encourage you to engage with the community through the [Slack or Mailing lists](#get-involved) if you're considering using Open Match in production before the 1.0 release, as the documentation is likely to lag behind the latest version a bit while we focus on getting out of alpha/beta as soon as possible.**
 
 ## Version
-The current stable version in master is 0.1.0.  
-The 0.2.0 RC1 is now available.
+[The current stable version in master is 0.2.0 (alpha)](https://github.com/GoogleCloudPlatform/open-match/releases/tag/020).  
 
 # Core Concepts
 
@@ -32,6 +30,7 @@ Open Match is designed to support massively concurrent matchmaking, and to be sc
 * **MMFOrc** — Matchmaker function orchestrator. This Open Match core component is in charge of kicking off custom matchmaking functions (MMFs) and evaluator processes.
 * **State Storage** — The storage software used by Open Match to hold all the matchmaking state. Open Match ships with [Redis](https://redis.io/) as the default state storage.
 * **Assignment** — Refers to assigning a player or group of players to a dedicated game server instance. Open Match offers a path to send dedicated game server connection details from your backend to your game clients after a match has been made.
+* **DGS** — Dedicated game server
 
 ## Requirements
 * [Kubernetes](https://kubernetes.io/) cluster — tested with version 1.9.
@@ -107,19 +106,23 @@ Large-scale concurrent matchmaking functions is a complex topic, and users who w
 
 Matchmaking Functions (MMFs) are run by the Matchmaker Function Orchestrator (MMFOrc) — once per profile it sees in state storage. The MMF is run as a Job in Kubernetes, and has full access to read and write from state storage. At a high level, the encouraged pattern is to write a MMF in whatever language you are comfortable in that can do the following things:
 
-[x] Be packaged in a (Linux) Docker container.
-[x] Read/write from the Open Match state storage — Open Match ships with Redis as the default state storage.
-[x] Read a profile you wrote to state storage using the Backend API.
-[x] Select from the player data you wrote to state storage using the Frontend API.
-[ ] Run your custom logic to try to find a match.
-[x] Write the match object it creates to state storage at a specified key.
-[x] Remove the players it selected from consideration by other MMFs.
-[x] Notify the MMFOrc of completion.
-[x] (Optional, but recommended) Export stats for metrics collection.
+- [x] Be packaged in a (Linux) Docker container.
+- [x] Read/write from the Open Match state storage — Open Match ships with Redis as the default state storage.
+- [x] Read a profile you wrote to state storage using the Backend API.
+- [x] Select from the player data you wrote to state storage using the Frontend API.
+- [ ] Run your custom logic to try to find a match.
+- [x] Write the match object it creates to state storage at a specified key.
+- [x] Remove the players it selected from consideration by other MMFs.
+- [x] Notify the MMFOrc of completion.
+- [x] (Optional, but recommended) Export stats for metrics collection.
 
-** Open Match offers [matchmaking logic API](#matchmaking-logic-mmlogic-api) calls for handling the checked items, as long as you are willing to format your input and output in the data schema Open Match expects (defined in the [protobuf messages](api/protobuf-spec/messages.proto)). **  You can to do this work yourself if you don't want to or can't use the data schema Open Match is looking for.  However, the data formats expected by Open Match are pretty generalized and will work with most common matchmaking scenarios and game types.  If you have questions about how to fit your data into the formats specified, feel free to ask us in the Slack or mailing group.
+**Open Match offers [matchmaking logic API](#matchmaking-logic-mmlogic-api) calls for handling the checked items, as long as you are able to format your input and output in the data schema Open Match expects (defined in the [protobuf messages](api/protobuf-spec/messages.proto)).**  You can to do this work yourself if you don't want to or can't use the data schema Open Match is looking for.  However, the data formats expected by Open Match are pretty generalized and will work with most common matchmaking scenarios and game types.  If you have questions about how to fit your data into the formats specified, feel free to ask us in the [Slack or mailing group](#get-involved).
 
-Example MMFs are provided in Golang and C#.
+Example MMFs are provided in these languages:
+- [C#](examples/functions/csharp/simple) (doesn't use the MMLogic API)
+- [Python3](examples/functions/python3/mmlogic-simple) (MMLogic API enabled)
+- [PHP](examples/functions/php/mmlogic-simple)  (MMLogic API enabled)
+- [golang](examples/functions/golang/manual-simple)  (doesn't use the MMLogic API)
 
 ## Open Source Software integrations
 
@@ -152,17 +155,17 @@ The following examples of how to call the APIs are provided in the repository. B
 
 Documentation and usage guides on how to set up and customize Open Match.
 
-## Precompiled container images
+### Precompiled container images
 
 Once we reach a 1.0 release, we plan to produce publicly available (Linux) Docker container images of major releases in a public image registry. Until then, refer to the 'Compiling from source' section below.
 
-## Compiling from source
+### Compiling from source
 
 All components of Open Match produce (Linux) Docker container images as artifacts, and there are included `Dockerfile`s for each. [Google Cloud Platform Cloud Build](https://cloud.google.com/cloud-build/docs/) users will also find `cloudbuild_COMPONENT.yaml` files for each component in the repository root.
 
 All the core components for Open Match are written in Golang and use the [Dockerfile multistage builder pattern](https://docs.docker.com/develop/develop-images/multistage-build/). This pattern uses intermediate Docker containers as a Golang build environment while producing lightweight, minimized container images as final build artifacts. When the project is ready for production, we will modify the `Dockerfile`s to uncomment the last build stage. Although this pattern is great for production container images, it removes most of the utilities required to troubleshoot issues during development.
 
-## Configuration
+### Configuration
 
 Currently, each component reads a local config file `matchmaker_config.json`, and all components assume they have the same configuration. To this end, there is a single centralized config file located in the `<REPO_ROOT>/config/` which is symlinked to each component's subdirectory for convenience when building locally. When `docker build`ing the component container images, the Dockerfile copies the centralized config file into the component directory.
 
@@ -220,8 +223,9 @@ Apache 2.0
 
 ## State storage
 - [ ] All state storage operations should be isolated from core components into the `statestorage/` modules.  This is necessary precursor work to enabling Open Match state storage to use software other than Redis.
-- [ ] The Redis deployment should have an example HA configuration using HAProxy 
+- [ ] [The Redis deployment should have an example HA configuration](https://github.com/GoogleCloudPlatform/open-match/issues/41)
 - [ ] Redis watch should be unified to watch a hash and stream updates.  The code for this is written and validated but not committed yet. We don't want to support two redis watcher code paths, so the backend watch of the match object should be switched to unify the way the frontend and backend watch keys.  The backend part of this is in but the frontend part is in another branch and will be committed later. 
+- [ ] Player/Group records generated when a client enters the matchmaking pool need to be removed after a certain amount of time with no activity. When using Redis, this will be implemented as a expiration on the player record.
 
 ## Instrumentation / Metrics / Analytics
 - [ ] Instrumentation of MMFs is in the planning stages.  Since MMFs are by design meant to be completely customizable (to the point of allowing any process that can be packaged in a Docker container), metrics/stats will need to have an expected format and formalized outgoing pathway.  Currently the thought is that it might be that the metrics should be written to a particular key in statestorage in a format compatible with opencensus, and will be collected, aggreggated, and exported to Prometheus using another process.
@@ -235,7 +239,6 @@ Apache 2.0
 - [ ] Autoscaling isn't turned on for the Frontend or Backend API Kubernetes deployments by default.
 - [ ] A [Helm](https://helm.sh/) chart to stand up Open Match will be provided in an upcoming version. For now just use the [installation YAMLs](./install/yaml).
 
-- [ ] Player/Group records generated when a client enters the matchmaking pool need to be removed after a certain amount of time with no activity. When using Redis, this will be implemented as a expiration on the player record.
 ## CI / CD / Build
 - [ ] We plan to host 'official' docker images for all release versions of the core components in publicly available docker registries soon.
 - [ ] CI/CD for this repo and the associated status tags are planned.
@@ -244,3 +247,6 @@ Apache 2.0
 
 ## Will not Implement 
 - [X] Defining multiple images inside a profile for the purposes of experimentation adds another layer of complexity into profiles that can instead be handled outside of open match with custom match functions in collaboration with a director (thing that calls backend to schedule matchmaking) 
+
+### Special Thanks
+- Thanks to https://jbt.github.io/markdown-editor/ for help in marking this document down.

cloudbuild_mmf_py3.yaml

@@ -1,11 +1,8 @@
 steps:
-- name: 'gcr.io/cloud-builders/docker'
-  args: [ 'pull', 'gcr.io/$PROJECT_ID/openmatch-mmf:py3' ]
 - name: 'gcr.io/cloud-builders/docker'
   args: [
             'build', 
             '--tag=gcr.io/$PROJECT_ID/openmatch-mmf:py3', 
-            '--cache-from=gcr.io/$PROJECT_ID/openmatch-mmf:py3', 
             '-f', 'Dockerfile.mmf_py3', 
             '.'
         ]

cloudbuild_mmforc.yaml

@@ -1,11 +1,8 @@
 steps:
-- name: 'gcr.io/cloud-builders/docker'
-  args: [ 'pull', 'gcr.io/$PROJECT_ID/openmatch-mmforc:dev']
 - name: 'gcr.io/cloud-builders/docker'
   args: [
             'build', 
             '--tag=gcr.io/$PROJECT_ID/openmatch-mmforc:dev', 
-            '--cache-from=gcr.io/$PROJECT_ID/openmatch-mmforc:dev', 
             '-f', 'Dockerfile.mmforc', 
             '.'
         ]

cloudbuild_mmlogicapi.yaml

@@ -1,11 +1,8 @@
 steps:
-- name: 'gcr.io/cloud-builders/docker'
-  args: [ 'pull', 'gcr.io/$PROJECT_ID/openmatch-mmlogicapi:dev' ]
 - name: 'gcr.io/cloud-builders/docker'
   args: [
             'build', 
             '--tag=gcr.io/$PROJECT_ID/openmatch-mmlogicapi:dev', 
-            '--cache-from=gcr.io/$PROJECT_ID/openmatch-mmlogicapi:dev', 
             '-f', 'Dockerfile.mmlogicapi', 
             '.'
         ]

docs/development.md

@@ -4,17 +4,58 @@ All components of Open Match produce (Linux) Docker container images as artifact
 
 Note: Although Google Cloud Platform includes some free usage, you may incur charges following this guide if you use GCP products.
 
-**This project has not completed a first-line security audit, and there are definitely going to be some service accounts that are too permissive.  This should be fine for testing/development in a local environment, but absolutely should not be used as-is in a production environment.**
+## Security Disclaimer
+**This project has not completed a first-line security audit, and there are definitely going to be some service accounts that are too permissive.  This should be fine for testing/development in a local environment, but absolutely should not be used as-is in a production environment without your team/organization evaluating it's permissions.**
+
+## Before getting started
+**NOTE**: Before starting with this guide, you'll need to update all the URIs from the tutorial's gcr.io container image registry with the URI for your own image registry. If you are using the gcr.io registry on GCP, the default URI is `gcr.io/<PROJECT_NAME>`.  Here's an example command in Linux to do the replacement for you this (replace YOUR_REGISTRY_URI with your URI, this should be run from the repository root directory):
+```
+# Linux
+egrep -lR 'gcr.io/matchmaker-dev-201405' . | xargs sed -i -e 's|gcr.io/matchmaker-dev-201405|YOUR_REGISTRY_URI|g'
+```
+```
+# Mac OS, you can delete the .backup files after if all looks good 
+egrep -lR 'gcr.io/matchmaker-dev-201405' . | xargs sed -i'.backup' -e 's|gcr.io/matchmaker-dev-201405|YOUR_REGISTRY_URI|g'
+```
 
 ## Example of building using Google Cloud Builder
 
 The [Quickstart for Docker](https://cloud.google.com/cloud-build/docs/quickstart-docker) guide explains how to set up a project, enable billing, enable Cloud Build, and install the Cloud SDK if you haven't do these things before. Once you get to 'Preparing source files' you are ready to continue with the steps below.
 
 * Clone this repo to a local machine or Google Cloud Shell session, and cd into it.
-* Run the following one-line bash script to compile all the images for the first time, and push them to your gcr.io registry. You must enable the [Container Registry API](https://console.cloud.google.com/flows/enableapi?apiid=containerregistry.googleapis.com) first.
-```
-for dfile in $(ls Dockerfile.*); do gcloud builds submit --config cloudbuild_${dfile##*.}.yaml; done
-```
+* In Linux, you can run the following one-line bash script to compile all the images for the first time, and push them to your gcr.io registry. You must enable the [Container Registry API](https://console.cloud.google.com/flows/enableapi?apiid=containerregistry.googleapis.com) first.
+    ```
+    # First, build the 'base' image.  Some other images depend on this so it must complete first.
+    gcloud build submit --config cloudbuild_base.yaml
+    # Build all other images. 
+    for dfile in $(ls Dockerfile.* | grep -v base); do gcloud builds submit --config cloudbuild_${dfile##*.}.yaml & done
+    ```
+* Once the cloud builds have completed, you can verify that all the builds succeeded in the cloud console or by by checking the list of images in your **gcr.io** registry:
+    ```
+    gcloud container images list
+    ```
+    (your registry name will be different)
+    ```
+    NAME
+    gcr.io/matchmaker-dev-201405/openmatch-backendapi
+    gcr.io/matchmaker-dev-201405/openmatch-devbase
+    gcr.io/matchmaker-dev-201405/openmatch-evaluator
+    gcr.io/matchmaker-dev-201405/openmatch-frontendapi
+    gcr.io/matchmaker-dev-201405/openmatch-mmf
+    gcr.io/matchmaker-dev-201405/openmatch-mmforc
+    gcr.io/matchmaker-dev-201405/openmatch-mmlogicapi
+    ```
+* The default example MMF images all use the same name (`openmatch-mmf`), with different image tags designating the different examples.  You can check that these exist by running this command (again, substituting your **gcr.io** registry):
+    ```
+    gcloud container images list-tags gcr.io/matchmaker-dev-201405/openmatch-mmf
+    ```
+    You should see tags for several of the example MMFs.  By default, Open Match will try to use the `openmatch-mmf:py3` image in the examples below, so it is important that the image build was successful and a `py3` image tag exists in your **gcr.io** registry before you continue:
+    ```
+    DIGEST        TAGS     TIMESTAMP
+    5345475e026c  php      2018-12-05T00:06:47
+    e5c274c3509c  go       2018-12-05T00:02:17
+    1b3ec3176d0f  py3      2018-12-05T00:02:07
+    ```
 
 ## Example of starting a GKE cluster
 
@@ -32,78 +73,115 @@ gcloud compute zones list
 
 ## Configuration
 
-Currently, each component reads a local config file `matchmaker_config.json`, and all components assume they have the same configuration.  To this end, there is a single centralized config file located in the `<REPO_ROOT>/config/` which is symlinked to each component's subdirectory for convenience when building locally.
-
-**NOTE** 'defaultImages' container images names in the config file will need to be updated with **your container registry URI**.  Here's an example command in Linux to do this (just replace YOUR_REGISTRY_URI with the appropriate location in your environment, should be run from the config directory):
-```
-sed -i 's|gcr.io/matchmaker-dev-201405|YOUR_REGISTRY_URI|g' matchmaker_config.json
-```
-For MacOS the `-i` flag creates backup files when changing the original file in place. You can use the following command, and then delete the `*.backup` files afterwards if you don't need them anymore:
-```
-sed -i'.backup' -e 's|gcr.io/matchmaker-dev-201405|YOUR_REGISTRY_URI|g' matchmaker_config.json
-```
-If you are using the gcr.io registry on GCP, the default URI is `gcr.io/<PROJECT_NAME>`.
-
-We plan to replace this with a Kubernetes-managed config with dynamic reloading when development time allows.  Pull requests are welcome!
+Currently, each component reads a local config file `matchmaker_config.json`, and all components assume they have the same configuration (if you would like to help us design the replacement config solution, please join the [discussion](https://github.com/GoogleCloudPlatform/open-match/issues/42).  To this end, there is a single centralized config file located in the `<REPO_ROOT>/config/` which is symlinked to each component's subdirectory for convenience when building locally.
 
 ## Running Open Match in a development environment
 
 The rest of this guide assumes you have a cluster (example is using GKE, but works on any cluster with a little tweaking), and kubectl configured to administer that cluster, and you've built all the Docker container images described by `Dockerfiles` in the repository root directory and given them the docker tag 'dev'.  It assumes you are in the `<REPO_ROOT>/deployments/k8s/` directory.
 
-**NOTE** Kubernetes resources that use container images will need to be updated with **your container registry URI**. Here's an example command in Linux to do this (just replace YOUR_REGISTRY_URI with the appropriate location in your environment):
-```
-sed -i 's|gcr.io/matchmaker-dev-201405|YOUR_REGISTRY_URI|g' *deployment.json
-```
-For MacOS the `-i` flag creates backup files when changing the original file in place. You can use the following command, and then delete the `*.backup` files afterwards if you don't need them anymore:
-```
-sed -i'.backup' -e 's|gcr.io/matchmaker-dev-201405|YOUR_REGISTRY_URI|g' *deployment.json
-```
-If you are using the gcr.io registry on GCP, the default URI is `gcr.io/<PROJECT_NAME>`.
-
 * Start a copy of redis and a service in front of it:
-```
-kubectl apply -f redis_deployment.json
-kubectl apply -f redis_service.json
-```
+    ```
+    kubectl apply -f redis_deployment.json
+    kubectl apply -f redis_service.json
+    ```
 * Run the **core components**: the frontend API, the backend API, the matchmaker function orchestrator (MMFOrc), and the matchmaking logic API.
 **NOTE** In order to kick off jobs, the matchmaker function orchestrator needs a service account with permission to administer the cluster. This should be updated to have min required perms before launch, this is pretty permissive but acceptable for closed testing:
-```
-kubectl apply -f backendapi_deployment.json
-kubectl apply -f backendapi_service.json
-kubectl apply -f frontendapi_deployment.json
-kubectl apply -f frontendapi_service.json
-kubectl apply -f mmforc_deployment.json
-kubectl apply -f mmforc_serviceaccount.json
-kubectl apply -f mmlogic_deployment.json
-kubectl apply -f mmlogic_service.json
-```
+    ```
+    kubectl apply -f backendapi_deployment.json
+    kubectl apply -f backendapi_service.json
+    kubectl apply -f frontendapi_deployment.json
+    kubectl apply -f frontendapi_service.json
+    kubectl apply -f mmforc_deployment.json
+    kubectl apply -f mmforc_serviceaccount.json
+    kubectl apply -f mmlogic_deployment.json
+    kubectl apply -f mmlogic_service.json
+    ```
 * [optional, but recommended] Configure the OpenCensus metrics services:
-```
-kubectl apply -f metrics_services.json
-```
+    ```
+    kubectl apply -f metrics_services.json
+    ```
 * [optional] Trying to apply the Kubernetes Prometheus Operator resource definition files without a cluster-admin rolebinding on GKE doesn't work without running the following command first. See https://github.com/coreos/prometheus-operator/issues/357
-```
-kubectl create clusterrolebinding projectowner-cluster-admin-binding --clusterrole=cluster-admin --user=<GCP_ACCOUNT>
-```
+    ```
+    kubectl create clusterrolebinding projectowner-cluster-admin-binding --clusterrole=cluster-admin --user=<GCP_ACCOUNT>
+    ```
 * [optional, uses beta software] If using Prometheus as your metrics gathering backend, configure the [Prometheus Kubernetes Operator](https://github.com/coreos/prometheus-operator):
-
-```
-kubectl apply -f prometheus_operator.json
-kubectl apply -f prometheus.json
-kubectl apply -f prometheus_service.json
-kubectl apply -f metrics_servicemonitor.json
-```
+    
+    ```
+    kubectl apply -f prometheus_operator.json
+    kubectl apply -f prometheus.json
+    kubectl apply -f prometheus_service.json
+    kubectl apply -f metrics_servicemonitor.json
+    ```
 You should now be able to see the core component pods running using a `kubectl get pods`, and the core component metrics in the Prometheus Web UI by running `kubectl proxy <PROMETHEUS_POD_NAME> 9090:9090` in your local shell, then opening http://localhost:9090/targets in your browser to see which services Prometheus is collecting from.
 
+Here's an example output from `kubectl get all` if everything started correctly, and you included all the optional components (note: this could become out-of-date with upcoming versions; apologies if that happens):
+```
+NAME                                       READY     STATUS    RESTARTS   AGE
+pod/om-backendapi-84bc9d8fff-q89kr         1/1       Running   0          9m
+pod/om-frontendapi-55d5bb7946-c5ccb        1/1       Running   0          9m
+pod/om-mmforc-85bfd7f4f6-wmwhc             1/1       Running   0          9m
+pod/om-mmlogicapi-6488bc7fc6-g74dm         1/1       Running   0          9m
+pod/prometheus-operator-5c8774cdd8-7c5qm   1/1       Running   0          9m
+pod/prometheus-prometheus-0                2/2       Running   0          9m
+pod/redis-master-9b6b86c46-b7ggn           1/1       Running   0          9m
+
+NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
+service/kubernetes            ClusterIP   10.59.240.1     <none>        443/TCP          19m
+service/om-backend-metrics    ClusterIP   10.59.254.43    <none>        29555/TCP        9m
+service/om-backendapi         ClusterIP   10.59.240.211   <none>        50505/TCP        9m
+service/om-frontend-metrics   ClusterIP   10.59.246.228   <none>        19555/TCP        9m
+service/om-frontendapi        ClusterIP   10.59.250.59    <none>        50504/TCP        9m
+service/om-mmforc-metrics     ClusterIP   10.59.240.59    <none>        39555/TCP        9m
+service/om-mmlogicapi         ClusterIP   10.59.248.3     <none>        50503/TCP        9m
+service/prometheus            NodePort    10.59.252.212   <none>        9090:30900/TCP   9m
+service/prometheus-operated   ClusterIP   None            <none>        9090/TCP         9m
+service/redis-sentinel        ClusterIP   10.59.249.197   <none>        6379/TCP         9m
+
+NAME                                        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+deployment.extensions/om-backendapi         1         1         1            1           9m
+deployment.extensions/om-frontendapi        1         1         1            1           9m
+deployment.extensions/om-mmforc             1         1         1            1           9m
+deployment.extensions/om-mmlogicapi         1         1         1            1           9m
+deployment.extensions/prometheus-operator   1         1         1            1           9m
+deployment.extensions/redis-master          1         1         1            1           9m
+
+NAME                                                   DESIRED   CURRENT   READY     AGE
+replicaset.extensions/om-backendapi-84bc9d8fff         1         1         1         9m
+replicaset.extensions/om-frontendapi-55d5bb7946        1         1         1         9m
+replicaset.extensions/om-mmforc-85bfd7f4f6             1         1         1         9m
+replicaset.extensions/om-mmlogicapi-6488bc7fc6         1         1         1         9m
+replicaset.extensions/prometheus-operator-5c8774cdd8   1         1         1         9m
+replicaset.extensions/redis-master-9b6b86c46           1         1         1         9m
+
+NAME                                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+deployment.apps/om-backendapi         1         1         1            1           9m
+deployment.apps/om-frontendapi        1         1         1            1           9m
+deployment.apps/om-mmforc             1         1         1            1           9m
+deployment.apps/om-mmlogicapi         1         1         1            1           9m
+deployment.apps/prometheus-operator   1         1         1            1           9m
+deployment.apps/redis-master          1         1         1            1           9m
+
+NAME                                             DESIRED   CURRENT   READY     AGE
+replicaset.apps/om-backendapi-84bc9d8fff         1         1         1         9m
+replicaset.apps/om-frontendapi-55d5bb7946        1         1         1         9m
+replicaset.apps/om-mmforc-85bfd7f4f6             1         1         1         9m
+replicaset.apps/om-mmlogicapi-6488bc7fc6         1         1         1         9m
+replicaset.apps/prometheus-operator-5c8774cdd8   1         1         1         9m
+replicaset.apps/redis-master-9b6b86c46           1         1         1         9m
+
+NAME                                     DESIRED   CURRENT   AGE
+statefulset.apps/prometheus-prometheus   1         1         9m
+```
+
 ### End-to-End testing
 
-**Note** The programs provided below are just bare-bones manual testing programs with no automation and no claim of code coverage. This sparseness of this part of the documentation is because we expect to discard all of these tools and write a fully automated end-to-end test suite and a collection of load testing tools, with extensive stats output and tracing capabilities before 1.0 release. Tracing has to be integrated first, which will be in an upcoming release.
+**Note**: The programs provided below are just bare-bones manual testing programs with no automation and no claim of code coverage. This sparseness of this part of the documentation is because we expect to discard all of these tools and write a fully automated end-to-end test suite and a collection of load testing tools, with extensive stats output and tracing capabilities before 1.0 release. Tracing has to be integrated first, which will be in an upcoming release.
 
-In the end: *caveat emptor*. These tools all work and are quite small, and as such are fairly easy for developers to understand by looking at the code and logging output. They are provided as-is just as a reference point of how to begin experimenting with Open Match integrations.
+In the end: *caveat emptor*. These tools all work and are quite small, and as such are fairly easy for developers to understand by looking at the code and logging output. They are provided as-is just as a reference point of how to begin experimenting with Open Match integrations.  
 
-* `examples/frontendclient` is a fake client for the Frontend API.  It pretends to be a real game client connecting to Open Match and requests a game, then dumps out the connection string it receives.  Note that it doesn't actually test the return path by looking for arbitrary results from your matchmaking function; it pauses and tells you the name of a key to set a connection string in directly using a redis-cli client.
-* `examples/backendclient` is a fake client for the Backend API.  It pretends to be a dedicated game server backend connecting to openmatch and sending in a match profile to fill.  Once it receives a match object with a roster, it will also issue a call to assign the player IDs, and gives an example connection string.  If it never seems to get a match, make sure you're adding players to the pool using the other two tools. Note: building this image requires that you first build the 'base' dev image (look for `cloudbuild_base.yaml` and `Dockerfile.base` in the root directory) and then update the first step to point to that image in your registry.  This will be simplified in a future release.
-* `test/cmd/client` is a (VERY) basic client load simulation tool.  It does **not** test the Frontend API - in fact, it ignores it and writes players directly to state storage on its own.  It doesn't do anything but loop endlessly, writing players into state storage so you can test your backend integration, and run your custom MMFs and Evaluators (which are only triggered when there are players in the pool).
+* `examples/frontendclient` is a fake client for the Frontend API.  It pretends to be a real game client connecting to Open Match and requests a game, then dumps out the connection string it receives.  Note that it doesn't actually test the return path by looking for arbitrary results from your matchmaking function; it pauses and tells you the name of a key to set a connection string in directly using a redis-cli client.  **Note**: If you're using the rest of these test programs, you're probably using the Backend Client below.  The default profiles that sends to the backend look for way more than one player, so if you want to see meaningful results from running this Frontend Client, you're going to need to generate a bunch of fake players using the client load simulation tool at the same time. Otherwise, expect to wait until it times out as your matchmaker never has enough players to make a successful match.
+* `examples/backendclient` is a fake client for the Backend API.  It pretends to be a dedicated game server backend connecting to openmatch and sending in a match profile to fill.  Once it receives a match object with a roster, it will also issue a call to assign the player IDs, and gives an example connection string.  If it never seems to get a match, make sure you're adding players to the pool using the other two tools. Note: building this image requires that you first build the 'base' dev image (look for `cloudbuild_base.yaml` and `Dockerfile.base` in the root directory) and then update the first step to point to that image in your registry.  This will be simplified in a future release.  **Note**: If you run this by itself, expect it to wait about 30 seconds, then return a result of 'insufficient players' and exit - this is working as intended.  Use the client load simulation tool below to add players to the pool or you'll never be able to make a successful match. 
+* `test/cmd/client` is a (VERY) basic client load simulation tool.  It does **not** test the Frontend API - in fact, it ignores it and writes players directly to state storage on its own.  It doesn't do anything but loop endlessly, writing players into state storage so you can test your backend integration, and run your custom MMFs and Evaluators (which are only triggered when there are players in the pool). 
 
 ### Resources
 

install/yaml/02-open-match.yaml

@@ -33,7 +33,7 @@ spec:
     spec:
       containers:
       - name: om-backend
-        image: gcr.io/unite-au-demo/openmatch-backendapi:dev
+        image: gcr.io/matchmaker-dev-201405/openmatch-backendapi:dev
         imagePullPolicy: Always
         ports:
         - name: grpc
@@ -79,7 +79,7 @@ spec:
     spec:
       containers:
       - name: om-frontendapi
-        image: gcr.io/unite-au-demo/openmatch-frontendapi:dev
+        image: gcr.io/matchmaker-dev-201405/openmatch-frontendapi:dev
         imagePullPolicy: Always
         ports:
         - name: grpc
@@ -125,7 +125,7 @@ spec:
     spec:
       containers:
       - name: om-mmforc
-        image: gcr.io/unite-au-demo/openmatch-mmforc:dev
+        image: gcr.io/matchmaker-dev-201405/openmatch-mmforc:dev
         imagePullPolicy: Always
         ports:
         - name: metrics

install/yaml/README.md

@@ -0,0 +1,73 @@
+# install/yaml
+This directory contains Kubernetes YAML resource definitions, which should be applied according to their filename order.  Only Redis & Open Match are required, Prometheus is optional.
+```
+kubectl apply -f 01-redis.yaml
+kubectl apply -f 02-open-match.yaml
+```
+**Note**: Trying to apply the Kubernetes Prometheus Operator resource definition files without a cluster-admin rolebinding on GKE doesn't work without running the following command first. See https://github.com/coreos/prometheus-operator/issues/357
+```
+kubectl create clusterrolebinding projectowner-cluster-admin-binding --clusterrole=cluster-admin --user=<GCP_ACCOUNT>
+```
+```
+kubectl apply -f 03-prometheus.yaml
+```
+[There is a known dependency ordering issue when applying the Prometheus resource; just wait a couple moments and apply it again.](https://github.com/GoogleCloudPlatform/open-match/issues/46)
+
+[Accurate as of v0.2.0] Output from `kubectl get all` if everything succeeded should look something like this:
+```
+NAME                                       READY     STATUS    RESTARTS   AGE
+pod/om-backendapi-84bc9d8fff-q89kr         1/1       Running   0          9m
+pod/om-frontendapi-55d5bb7946-c5ccb        1/1       Running   0          9m
+pod/om-mmforc-85bfd7f4f6-wmwhc             1/1       Running   0          9m
+pod/om-mmlogicapi-6488bc7fc6-g74dm         1/1       Running   0          9m
+pod/prometheus-operator-5c8774cdd8-7c5qm   1/1       Running   0          9m
+pod/prometheus-prometheus-0                2/2       Running   0          9m
+pod/redis-master-9b6b86c46-b7ggn           1/1       Running   0          9m
+
+NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
+service/kubernetes            ClusterIP   10.59.240.1     <none>        443/TCP          19m
+service/om-backend-metrics    ClusterIP   10.59.254.43    <none>        29555/TCP        9m
+service/om-backendapi         ClusterIP   10.59.240.211   <none>        50505/TCP        9m
+service/om-frontend-metrics   ClusterIP   10.59.246.228   <none>        19555/TCP        9m
+service/om-frontendapi        ClusterIP   10.59.250.59    <none>        50504/TCP        9m
+service/om-mmforc-metrics     ClusterIP   10.59.240.59    <none>        39555/TCP        9m
+service/om-mmlogicapi         ClusterIP   10.59.248.3     <none>        50503/TCP        9m
+service/prometheus            NodePort    10.59.252.212   <none>        9090:30900/TCP   9m
+service/prometheus-operated   ClusterIP   None            <none>        9090/TCP         9m
+service/redis-sentinel        ClusterIP   10.59.249.197   <none>        6379/TCP         9m
+
+NAME                                        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+deployment.extensions/om-backendapi         1         1         1            1           9m
+deployment.extensions/om-frontendapi        1         1         1            1           9m
+deployment.extensions/om-mmforc             1         1         1            1           9m
+deployment.extensions/om-mmlogicapi         1         1         1            1           9m
+deployment.extensions/prometheus-operator   1         1         1            1           9m
+deployment.extensions/redis-master          1         1         1            1           9m
+
+NAME                                                   DESIRED   CURRENT   READY     AGE
+replicaset.extensions/om-backendapi-84bc9d8fff         1         1         1         9m
+replicaset.extensions/om-frontendapi-55d5bb7946        1         1         1         9m
+replicaset.extensions/om-mmforc-85bfd7f4f6             1         1         1         9m
+replicaset.extensions/om-mmlogicapi-6488bc7fc6         1         1         1         9m
+replicaset.extensions/prometheus-operator-5c8774cdd8   1         1         1         9m
+replicaset.extensions/redis-master-9b6b86c46           1         1         1         9m
+
+NAME                                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+deployment.apps/om-backendapi         1         1         1            1           9m
+deployment.apps/om-frontendapi        1         1         1            1           9m
+deployment.apps/om-mmforc             1         1         1            1           9m
+deployment.apps/om-mmlogicapi         1         1         1            1           9m
+deployment.apps/prometheus-operator   1         1         1            1           9m
+deployment.apps/redis-master          1         1         1            1           9m
+
+NAME                                             DESIRED   CURRENT   READY     AGE
+replicaset.apps/om-backendapi-84bc9d8fff         1         1         1         9m
+replicaset.apps/om-frontendapi-55d5bb7946        1         1         1         9m
+replicaset.apps/om-mmforc-85bfd7f4f6             1         1         1         9m
+replicaset.apps/om-mmlogicapi-6488bc7fc6         1         1         1         9m
+replicaset.apps/prometheus-operator-5c8774cdd8   1         1         1         9m
+replicaset.apps/redis-master-9b6b86c46           1         1         1         9m
+
+NAME                                     DESIRED   CURRENT   AGE
+statefulset.apps/prometheus-prometheus   1         1         9m
+```