Provide terraform support to set up production cluster

[yfei1]

[Laremere]

I currently don't see much request for this. Please chime in if this is something you want.

[comerford]

I'd love to see something similar to the Terraform Helm module for Agones which allows the configuration for Helm to then live within the overall Terraform config. In terms of a use case, I currently have my Kubernetes cluster configured using the VPC and EKS modules on AWS, then Agones in the same config using the agones_helm module I mentioned. Rather than install openmatch via helm separately it would be very nice to have it declared directly in the terraform config. It would also allow you to have a module for open-match that builds on existing modules to give a reference implementation of open-match from scratch for testing/demo purposes. For example, the AKS/EKS/GKE + Agones module already exists and acts as a great entrypoint for those that want to try things out, see the system working.

[comerford]

this is a quick mock-up of what such a module would look like - I have taken a guess at what the relevant configurable values actually are here:

https://github.com/comerford/open-match/tree/create_terraform_helm_module/install/terraform/modules/helm

This could (once merged of course) then be used with something like the following code in a terraform config:

module "helm_open-match" {
  source = "git::https://github.com/googleforgames/open-match.git//install/terraform/modules/helm/?ref=master"

  open-match-telemetry_enabled             = "true"
  global_image_tag                                   = "0.0.1-dev"
  ...
  global_grafana_enabled                          = "true"

}

I'd be happy to create a pull request based on the branch above, but I'd appreciate some guidance on the desired configurable values for the module first.

[Laremere]

Hey Adam, thanks for looking into this.

I will note that I'm not familiar with how all of the helm stuff was set up, and think it's a likely source of future refactoring. There's no immediate plans. However this looks fairly light weight, so I'm not worried much about maintenance if things change a bit.

I'm not that familiar with terraform - any proposals for how this is going to work with our release and versioning process?

For variables:
Is it possible to remove the variable defaults and instead use the values from values.yaml by default? I would prefer to not add another place where default values need to be maintained.

I don't know if image tags should be considered here - ideally you're requesting a specific OM version from helm, which should dictate the required image versions?

A few of the core open match configurations seem important:

• registrationInterval
• pendingReleaseTimeout
• assignedDeleteTimeout
• queryPageSize

Other than that, I good with starting with what you want, and iterating from there on requests.

[comerford]

Is it possible to remove the variable defaults and instead use the values from values.yaml by default? I would prefer to not add another place where default values need to be maintained.

From a Terraform perspective I think we can just declare the variables without a default value defined (will see if I can confirm that is true - doing so is valid config, I just need to make sure it won't barf on a lack of values at all), and the defaults will not be altered, but it will still be possible to configure the values, and refer people to the documentation of the main project for the defaults.