open-match
open-match copied to clipboard
googleforgames
Remove the hard coding of openmatch namespace from the examples and tutorials
Is your feature request related to a problem? Please describe.
Working on a shared cluster, we can't all use the namespace open-match for our installations of Open Match. So I have installed open-match in my own namespace, using Helm.
However, in order to work on implementing a Director and Game Frontend, I needed a working Match Function service (which a different team is implementing in parallel). I was hoping to use the ones from the getting started demo, but it (and all the examples) hard-codes the om-query service address to om-query.open-match.svc.cluster.local:50503.
Describe the solution you'd like
My preference would be some kind of configuration option, e.g, the one in the demo script, that points the MMF examples to the right place to find om-query.
Describe alternatives you've considered
As an alternative, simply removing all the hard-coded namespaces from the examples, and directing users to install the demo into the same namespace as their Open Match install.
That would also have the nice benefit of making kubectl apply --namespace my-demo-namespace -f work without editing the demo setup file. (Which I think is also a bug, but it's easy to fix with a text-editor).
Additional context
I had thought the existing config option in the demo did this. I don't actually know what does consume this option.
A quick check suggests that #1086 removed the harness that managed these configuration settings (see newMatchFunctionService), but didn't remove the config options from the demo script, or reinstate support for the config options in the remaining code.
Although in my case I hit this with the soloduel MMF from the Getting Started guide, a search for open-match.svc.cluster.local suggests that all the examples and tutorials now have the same hard-coded namespace assumption.
Hi Paul,
Thanks for raising this issue. The reason that we chose to hard-coding the open-match namespace for all of our examples and tutorials is that we don't want to overcomplicate the on-boarding process. There are a lot of game developers who are unfamiliar with how k8s and the config library works in golang, so we decided to keep things simple and deliberately decouple the code of the examples and tutorials from most of the third-party dependencies.
The solution that you pointed out is what we did back in v0.8.0, yet having the demo and open match core components living in the same namespace will let new users conceptually confused what are the customizable components in open match, and make reusing the core components for the next steps of the tutorials much harder.
I understand that the hard-coded namespace is annoying when working on a shared cluster. Have you tried to run Open Match with Minikube on your own workstation?
I had thought the existing config option in the demo did this. I don't actually know what does consume this option.
Thanks for pointing out the mistake, and yes, this is a dead code that is no longer referred by any program, will send out a PR and fix it.
I had not used minikube, but the other developers on my team were doing that for their part.
I found this hard-coded open-match namespace actually greatly complicated my understanding, as I spent a fair bit of time thinking that it was like Agones in that you generally had a cluster-wide install, and drove it all from your own config files, but could find no hint towards this in the documentation, or in fact any discussion around namespace surprises or similar in the "Getting Started" guide.
The getting started guide demonstrates creating a namespace and includes --namespace parameter to kubectl apply, but the current demo deployment file has a namespace creation hard-coded, and hard-codes the namespace into each resource, so this was also rather surprising.
I would definitely much-prefer being able to configure the namespace used for the open-match core components in the demo than be installing the demo into the same namespace. The latter was my alternative considered solution.
Perhaps a Helm chart for the demo could be used to isolate the game devs from having to edit hostnames in a config file? That seems like overkill to me, but if we're trying to isolate Open Match users from k8s, that will provide a clear abstraction and allow configuration options in a more-familiar format.
I had not used minikube, but the other developers on my team were doing that for their part.
If you are trying to avoid the namespace conflict problem on a shared cluster then I think Minikube is the right tool that you are looking for. This is also the tool recommended by the k8s team for local Kubernetes application development.
I found this hard-coded open-match namespace actually greatly complicated my understanding, as I spent a fair bit of time thinking that it was like Agones in that you generally had a cluster-wide install, and drove it all from your own config files, but could find no hint towards this in the documentation, or in fact any discussion around namespace surprises or similar in the "Getting Started" guide.
I agree. This can be resolved by adding more documentation and explaining the components of Open Match could be installed under any namespace.
The getting started guide demonstrates creating a namespace and includes --namespace parameter to kubectl apply, but the current demo deployment file has a namespace creation hard-coded, and hard-codes the namespace into each resource, so this was also rather surprising.
I'll remove the kubectl create namespace open-match-demo instruction in the "Getting Started" guide. I don't see why this configuration is surprising though. The goal of the tutorial is to showcase the basic functionalities of Open Match rather than using it as a harness/template for future development. The demo is missing some pieces that are critical for production usage, e.g. healthcheck, resource requirements, and grpc load balancing configurations.
Perhaps a Helm chart for the demo could be used to isolate the game devs from having to edit hostnames in a config file? That seems like overkill to me, but if we're trying to isolate Open Match users from k8s, that will provide a clear abstraction and allow configuration options in a more-familiar format.
We have a future roadmap for an open-match-ecosystem repo after v1.0. All of the tutorials, production setups, and tools for developing and testing open match will go to this repo instead of staying in the main one. We are also considering adding a configurable helm chart for developing the MMFs.
I think the surprise for me is simply encountering k8s instructions that implicitly require developers to use the specific named namespace, rather than it being a placeholder for a namespace.
In the limited experience I have with k8s in my company, it's been strongly the case that less-k8s-knowledgeable developers have an easier time with an allocated namespace on a shared development cluster and "Here's a kubecfg"; than having to manage MiniKube locally including installing all the cluster-wide components (in our case, NGINX Ingress, Agones, Jaeger Operator, Prometheus Operator, some EFK stack), with some Minikube-specific configuration options and bugs to work around.
This can be resolved by adding more documentation and explaining the components of Open Match could be installed under any namespace.
except when following the Getting Started guide or the tutorials, which requires that Open Match be installed in the open-match namespace.
Hello @TBBle
we want to suggest you that it is not a good idea to change the open-match demo examples (remove hard coded namespace) as this would create incompatibility issues for the end users who are consuming for respective examples. Our recommendation would be to create helm charts in order to templatize the open-match demo deployment descriptors. Let Us Know if you have any questions we are happy to discuss more.
