Request to do not include other terraform-aws-modules inside the terraform-aws-eks

[haofeif]

Request to do not include other terraform-aws-modules inside the terraform-aws-eks

[bryantbiggs]

we do not have any plans to remove this module, and in fact we have plans to replace some of the duplicated functionality for ASGs/launch templates with the ASG module in the next major version release https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/docs/UPGRADE-20.0.md#%EF%B8%8F-upcoming-changes-planned-in-v210-%EF%B8%8F

[haofeif]

@bryantbiggs okay. What about an another alternative ?

for these two lines, add custom_terraform_registry_version_url as Inputs ?

From

  source  = "terraform-aws-modules/kms/aws"
  version = "2.1.0" # Note - be mindful of Terraform/provider version compatibility between modules

to

variable "custom_terraform_registry_version_url" {
  description = "URL for custom Terraform registry version"
  type        = string
  default     = ""
}

locals {
  version = var.custom_terraform_registry_version_url != "" ? "" : "2.1.0"
}


  source = try(var.custom_terraform_registry_version_url, "terraform-aws-modules/kms/aws")
  version = local.version

As for private terraform registry, customers do want to leverage the full benefits of the public registry. Some customers use github or gitlab with the following format, instead of terraform-aws-eks public terraform registry

source = "[email protected]:XXX/terraform-aws-eks.git?ref=v20.12.0"

[bryantbiggs]

does that work? hashicorp/terraform#1439

they are better off forking and updating these values on their own

[haofeif]

does that work? hashicorp/terraform#1439

they are better off forking and updating these values on their own

@bryantbiggs it doesnt seem to address the same issue. We have no issues using the source = "[email protected]:XXX/terraform-aws-eks.git?ref=v20.12.0". Only when it has hard coded code inside of the module using another public terraform module making it difficult.

Customers did a fork a year ago, and made changes directly on the forked module. Now they found it extremely hard to sync with the latest changes from the public terraform-aws-eks module.

Hence, they made a pivot, which is to develop a terraform-aws-eks-customer-wrapper to incorporate the customer related changes that they would like to make, and make a local copy of the terraform-aws-eks module in their private gitlab. in this case, they could both enjoy syncing with the new changes from public repo, while making custom settings on their wrapper without touching the backend module.

It is all working fine, but the sub hard coded module like this one is challenging. They might need to git fetch remote, git push --force with new changes, then find out the terraform-aws-modules/kms/aws and replace that with source = "[email protected]:XXX/terraform-aws-kms.git?ref=v2.1.0", instead of only touching their wrapper module.

[haofeif]

@bryantbiggs you see the current design for the customer. It will be quite difficult to manage without making the changes as above. In this diagram, eks-cluster is the wrapper class mentioned above.

[bryantbiggs]

@haofeif you are not listening - the two solutions you proposed are not going to be feasible:

1. We are not removing the KMS module
2. Terraform does not support variables for a module source

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.