Parameterized name as suffix for all resources tag #31
Conversation
|
Thanks for your contribution @wellsiau-aws I made a couple of comments for our review Once you apply your final version, please remember to apply the same considerations for Blueprints 02 (at-scale) @sboardwell your thought are welcome! |
| @@ -18,3 +32,19 @@ variable "temp_license" { | |||
| description = "Temporary license details" | |||
| type = map(string) | |||
| } | |||
|
|
|||
| variable "k8s_version" { | |||
There was a problem hiding this comment.
@wellsiau-aws I believe that K8 version is best to not be parametrised in alignment with the EKS Addons v5 https://github.com/aws-ia/terraform-aws-eks-blueprints-addons/blob/main/tests/complete/main.tf#L65 and blueprints patterns https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/patterns/stateful/main.tf#L6 in benefit of maintenance and its support.
It is aligned with Blueprints Terraform caveats that differs from AWS Quickstart approach. In the second there were many parameters to be configured (including passing your existing VPC in our old CloudBees CI which makes things more complicated to maintain).
Consecutive releases of this addons increase the version of the K8s as well as the CloudBees CI charts https://github.com/cloudbees/terraform-aws-cloudbees-ci-eks-addon/blob/main/main.tf#L12 ==> That version bump requires to be tested and validated. Leaving the K8s version as variable could lead to a situation not tested and frustration for end-user.
Note: At the end blueprints are seen as pattern but users can modify locals for their requirements at their own risk (assuming they know what they are doing).
There was a problem hiding this comment.
This variable makes it easier for user to run test without modifying the underlying .tf files.
That said, I recognized the concern of externalizing other cluster / EKS level attributes, which are not the purpose of this reference blueprint.
| default = "1.26" | ||
| } | ||
|
|
||
| variable "vpc_cidr" { |
There was a problem hiding this comment.
@wellsiau-aws I personally believe that CIDR for the EKS cluster VPC is best to not be parametrised in alignment with the EKS Addons v5 https://github.com/aws-ia/terraform-aws-eks-blueprints-addons/blob/main/tests/complete/main.tf#L47 and blueprints patterns https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/patterns/stateful/main.tf#L38 in benefit of maintenance.
As it was said before, it is aligned with Blueprints Terraform caveats that differs from AWS Quickstart approach.
| @@ -5,18 +5,18 @@ data "aws_route53_zone" "this" { | |||
| data "aws_availability_zones" "available" {} | |||
|
|
|||
| locals { | |||
| name = "cbci-bp01-i${random_integer.ramdom_id.result}" | |||
| region = "us-east-1" | |||
| name = "cbci-bp-${var.name}" | |||
There was a problem hiding this comment.
Suggestions:
1.- Replace cbci-bp-${var.name} by cbci-bp01${local.name}. Note cbci-bp01 ==> it refers to CBCI Blueprints 01 (getting started). It does nothing to do with random
2.- Add to locals
locals {
name = var.name == "" ? "" : "-${var.name}"
}
3.- Please, repeat the same approach for cbci-bp02${local.name}
There was a problem hiding this comment.
sounds good, I will add the suggestion
|
It has been addressed in #36 |
Resolve #29
Since
for_eachcannot resolve value from random-id provider, the best way to address this is by letting customer to choose the random id. This will keep it deterministic for each plan / apply.I also externalized other parameters such as EKS version and CIDR. This allows end-user to use the module as-is from abstraction such as AWS Service Catalog or Terraform Cloud no-code provisioning without making changes to the locals.