-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Update provider deprecations #117
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few questions but nothing blocking
condition = contains(["5.7", "8.0.mysql_aurora.3.01.0", "8.0.mysql_aurora.3.02.0"], var.database_engine_version) | ||
error_message = "We only support MySQL: \"5.7\"; \"8.0.mysql_aurora.3.01.0\"; \"8.0.mysql_aurora.3.02.0\"." | ||
} | ||
default = "8.0.mysql_aurora.3.02.2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd think we still want validation here that it's 5.7 or 8.
@@ -27,8 +27,8 @@ variable "cluster_endpoint_public_access_cidrs" { | |||
|
|||
variable "cluster_version" { | |||
description = "Indicates AWS EKS cluster version" | |||
nullable = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a sane minimum here?
resource "aws_s3_bucket" "file_storage" { | ||
bucket = "${var.namespace}-file-storage-${random_pet.file_storage.id}" | ||
|
||
force_destroy = !var.deletion_protection |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this also apply to object_lock_enabled
?
## [2.1.0](v2.0.0...v2.1.0) (2023-08-14) ### Features * Update provider deprecations ([#117](#117)) ([e210dc6](e210dc6))
This PR is included in version 2.1.0 🎉 |
* elasticache, tgt group * rm sid from iam policy docs (reduce churn) * updates + readme * fmt + default eks var * order * eks cluster version * remove "inline_policies" from iam roles * removed extren comments
## [2.1.0](v2.0.0...v2.1.0) (2023-08-14) ### Features * Update provider deprecations ([#117](#117)) ([e210dc6](e210dc6))
This update addresses:
aws_s3_bucket_acl
,aws_s3_bucket_cors_configuration
,aws_s3_bucket_ownership_controls
,aws_s3_bucket_public_access_block
, andaws_s3_bucket_server_side_encryption_configuration
1.25
in both the repository root and in theapp_eks
module. neither sets a default or allows anull
value, which relegates the definition of the kubernetes version used in the EKS cluster explicitly to the invocation of the module. (For example, look at the invocation of thewandb_infra
module inexamples/public-dns-external/main.tf
.)inline_policies
attribute has been removed from the IAM role policies in theapp_eks
module. the effect here is that terraform will not delete any in-line policies it finds attached to the role. this shouldn't be a problem, since we moved from inline policies to the resource-attachment style prior to the v2.0 release. Again, it's critical that upgrades to this version be executed serially to make sure that these changes are affected. if inline policies remain defined, there will be a confilct, and the result is that the policies defined in theapp_eks
module.