v0.24.0 Unstable Pre-Release

See note in Release v0.21.0 (https://github.com/cloudposse/terraform-aws-eks-node-group/releases/tag/0.21.0)

Always add var.security_groups to launch template if provided @cvittoriasona (#77)

what

• If var.security_groups is present, add any passed in security groups, along with the default cluster security group, to the launch template.

why

• var.security_groups is only added to the launch template if var.remote_access_enabled is true. Additional security groups should not be dependent on SSH access being enabled to be used.
• Specifically, ran into an issue when using a x-account shared VPC where the default security group for the VPC was not available to accounts the VPC was shared with. After encountering this error, when attempting to specify a security group for the launch template using var.security_groups, realized this var isn't active unless var.remote_access_enabled is also set. See below for output:

Error: error creating EKS Node Group (my-eks-node-group): InvalidRequestException: You do not have access to a default security group in VPC vpc-123456. Specify a security group, 310. Specify a security group, and try again.
│ {
│   RespMetadata: {
│     StatusCode: 400,
│     RequestID: "some-uuid"
│   },
│   Message_: "You do not have access to a default security group in VPC vpc-123456. Specify a security group, and try again."
│ }

This seems to be mostly a workaround for launch templates as EKS managed nodegroups should be auto-assigned to the default cluster security group, even if the launch template has no security groups attached to it.

Issue was present in v0.19.0 only when using var.kubernetes_taints, but in >=v0.20.0 this issue applied to all nodegroups created with this module.

references

• Tested with AWS provider v3.44.0 & v3.50.0

v0.23.0 Unstable Pre-release

See note in Release v0.21.0 (https://github.com/cloudposse/terraform-aws-eks-node-group/releases/tag/0.21.0)

Add flag to optionally not attach AmazonEKS_CNI_Policy to nodegroups @cvittoriasona (#76)

what

• Adds worker_role_cni_iam_enabled bool so nodegroups can have the AmazonEKS_CNI_Policy omitted from IAM Instance Role.
• Defaults to true to not break existing use cases.

why

• Meant to be used with EKS IAM role for aws-node service account
• Similar to worker_role_autoscale_iam_enabled bool so nodes are configured with least privileges required for EKS to work (AmazonEC2ContainerRegistryReadOnly and AmazonEKSWorkerNodePolicy) ref

v0.22.0 Unstable Pre-release

We are revising and standardizing our handling of security groups and security group rules across all our Terraform modules. This is an early attempt with significant breaking changes. We will make further breaking changes soon, so using this version is not recommended.

Feature: to be able to increase or decrease the timeouts for aws_eks_node_group resources @alfredo-gil (#70)

Feature: to be able to increase or decrease the timeouts for aws_eks_node_group resources

what

• This PR gives the possibility to increase or decrese the tiemouts managing the node groups

why

• We need it because we use node groups with more than 50 nodes
• When we need to change a node group it takes much more than 60 minutes
• For example, if we need to update the ami version for our node groups with no business impact we use create_before_destroy = true and it takes much more than 60 minutes.
• If we don'r increase the timeout terraform apply would fail because of the timeout

references

• The aws_eks_node_group resource has the option to configure the timeouts:
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_node_group#timeouts

v0.21.0 Unstable Pre-Release

We are revising and standardizing our handling of security groups and security group rules across all our Terraform modules. This is an early attempt with significant breaking changes. We will make further breaking changes soon, so using this version is not recommended.

feat: use security-group module instead of resource @SweetOps (#68)

what

• use security-group module instead of resource
• update tests

why

• more flexible than current implementation
• bring configuration of security group/rules to one standard

references

• CPCO-409

v1.0.0 Initial release with production Semantic Versioning

This is the v1.0.0 release according to production Semantic Versioning, part of Cloud Posse's general policy to convert to production versioning as we make updates to relatively mature modules, especially those where we see breaking changes coming in the near future. This module already has a v2.0.0 with breaking changes where we convert it to use our security-group and make other incompatible fixes and enhancements.

This version is identical to v0.20.0. Versions between 0.20.0 and 0.25.0 are unsupported pre-release versions with no supported migration step. Our best suggestion is to downgrade to v0.20.0 and then upgrade to the latest v2.x version. For older versions, we recommend upgrading to v1.0.0 and then from there following the migration instructions to upgrade to v2.0.0 and then to the latest v2.x version.

v0.20.0

feat(aws_launch_template): parametrize metadata_options @abhinavkhanna-sf (#63)

what

• parametrized launch template metadata options
• moved default values to variables.tf

why

• Restricting access to the IMDS and Amazon EC2 instance profile credentials
• EKS Security Best Practices

references

• closes #62

v0.19.0 Allow list of instance types (may cause rebuild)

🚀 Enhancements

Because we now allow users to supply a list of up to 20 instance types, along with choosing Spot instances, this release may trigger your node group to get rebuilt. If you have not already, we strongly encourage you to take this opportunity to switch to create_before_destroy = true.

Since this release is likely to cause cluster rebuilds anyway, we took this opportunity to sort any lists (like subnet IDs) that, if changed, would trigger a node group rebuild. The first time, however, that will likely trigger a rebuild because you likely were not passing them in sorted to begin with. If you were getting them from a data source, they were likely coming in a different order every time anyway.

Fix allow several instance types @patrickjahns (#54)

what

• Allow to specify more than a single instance_types for eks node groups
• Possible to pass more than a single item in the list since the the introduction of capacity_type see upstream pr

why

• For utilising SPOT instances it is a good practice to specify more than a single instance type

references

• Related to #8
• See also instanceTypes in current AWS eks api

v0.18.3

🤖 Automatic Updates

context.tf updated to v0.24.1, minimum required Terraform version bumped to 0.13.0 when needed, readme updated @maximmi (#59)

what

• update context.tf to v0.24.1
• minimum required Terraform version bumped to 0.13.0
• readme updated, Bridgecrew compliance badges added

why

• It allows for setting the letter case of tag names and labels, back compatibility with context v0.22.0 and below
• we have dropped support for Terraform 0.12
• To be able see and fix the recommendations from Bridgecrew so we can position our modules as standards compliant

v0.18.2

🤖 Automatic Updates

chore(deps): update terraform cloudposse/label/null to v0.24.1 @renovate (#61)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/label/null (source)	terraform	minor	0.23.0 -> 0.24.1

---

Release Notes

cloudposse/terraform-null-label

v0.24.1

Compare Source

Allow control of letter case of outputs @​SweetOps (#​107)

You now have control over the letter case of generated tag names and supplied labels, which means you also have control over the letter case of the ultimate id.

Labels are the elements you can include in label_order, namely namespace, environment, stage, name, and attributes. For every non-empty label, a corresponding tag name is generated. For namespace, environment, stage, the output is the formatted, normalized input. (By "normalized" we mean that it goes through regex_replace_chars.), For attributes, which is a list, each element is normalized, duplicates are removed, and the resulting list is converted to a string by joining the elements with the delimiter (defaults to hyphen). For name, which is special, the output is the same as id, which is the joining of the labels in the order specified by label_order and separated by delimiter.

• You can set label_key_case to one of upper, lower, or title, which will result in generated tag names in the corresponding case: NAME, name, or Name. For backwards compatibility, title is the default
• You can set label_value_case to one of upper, lower, title, or none, which will result in output label values in the corresponding case (with none meaning no case conversion of any kind will be done, though the labels will still be subject to regex_replace_chars). The case converted labels will show up not just in the module output of the labels themselves, but also in the tag values and in the id string.

You can look at the test cases in examples/complete and the expected results in test/src/examples_complete_test.go to see examples of how this is supposed to work.

One interesting example is that you can create ids in Pascal case by setting label_value_case = "title" and delimiter = "".

Include updates to exports/context.tf @​Nuru (#​122 and #​123)

##### what - Include updates to `exports/context.tf` - Update README with features and compatibilty - Add validation for `id_length_limit` ##### why - The `exports/context.tf` is what gets distributed and needs to be in sync - Replace outdated information - Was not validated earlier because validators are not supported in TF 0.12 but now we are dropping support for TF 0.12 and so we can add validators

Restore backward compatibility with v0.22.1 and earlier @​Nuru (#​121)

##### what - Restore backward compatibility with v0.22.1 and earlier - Allow setting of `label_key_case` and `label_value_case` by vars, not just by context attributes. ##### why - Allow interoperability of old and new modules - Normally, root modules make settings via individual variables, not by setting an entire context block.

Incorporates and closes #​120

v0.24.0

Compare Source

Restore backward compatibility with v0.22.1 and earlier @​Nuru (#​121)

##### what - Restore backward compatibility with v0.22.1 and earlier - Allow setting of `label_key_case` and `label_value_case` by vars, not just by context attributes. ##### why - Allow interoperability of old and new modules - Normally, root modules make settings via individual variables, not by setting an entire context block.

Incorporates and closes #​120

Allow control of letter case of outputs @​SweetOps (#​107)

You now have control over the letter case of generated tag names and supplied labels, which means you also have control over the letter case of the ultimate id.

Labels are the elements you can include in label_order, namely namespace, environment, stage, name, and attributes. For every non-empty label, a corresponding tag name is generated. For namespace, environment, stage, the output is the formatted, normalized input. (By "normalized" we mean that it goes through regex_replace_chars.), For attributes, which is a list, each element is normalized, duplicates are removed, and the resulting list is converted to a string by joining the elements with the delimiter (defaults to hyphen). For name, which is special, the output is the same as id, which is the joining of the labels in the order specified by label_order and separated by delimiter.

• You can set label_key_case to one of upper, lower, or title, which will result in generated tag names in the corresponding case: NAME, name, or Name. For backwards compatibility, title is the default
• You can set label_value_case to one of upper, lower, title, or none, which will result in output label values in the corresponding case (with none meaning no case conversion of any kind will be done, though the labels will still be subject to regex_replace_chars). The case converted labels will show up not just in the module output of the labels themselves, but also in the tag values and in the id string.

You can look at the test cases in examples/complete and the expected results in test/src/examples_complete_test.go to see examples of how this is supposed to work.

One interesting example is that you can create ids in Pascal case by setting label_value_case = "title" and delimiter = "".

##### Known issues - `exports/context.tf` still not backwards compatible - Validation for `id_length` not included in `exports/context.tf`

v0.18.1

🤖 Automatic Updates

Update context.tf @cloudpossebot (#60)

what

This is an auto-generated PR that updates the context.tf file to the latest version from cloudposse/terraform-null-label

why

To support all the features of the context interface.