Skip to content
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

supplying cluster_type to an aws_redshift_cluster resource can cause the resource to always be "changed" on subsequent apply operations #11275

Open
ghost opened this issue Dec 12, 2019 · 2 comments
Labels
service/redshift Issues and PRs that pertain to the redshift service.

Comments

@ghost
Copy link

ghost commented Dec 12, 2019

This issue was originally opened by @mmccord-mdbuyline as hashicorp/terraform#23660. It was migrated here as a result of the provider split. The original body of the issue is below.


@stack72 @bsiegel -- The change associated with this issue appears to have introduced a slight bug with the aws_redshift_cluster resource. If you create a cluster by supplying the resource with a cluster_type of single-node and number_of_nodes with 1 and then resize the cluster by supplying a cluster_type of multi-node and number_of_nodes with 2 then the resource will always be listed as "changed" in any subsequent apply operations.

In the plan output of any subsequent apply operations it will show cluster_type as changing from multi-node to multi-node and then try to execute a resize operation with the AWS API (which AWS will dutifully carry out even if the actual size of the cluster hasn't changed, thus taking the cluster down in the process). Re-worded: Essentially supplying a cluster_type in this way will continuously taint the cluster resource on apply.

The work around is to simply remove the supplied cluster_type entirely and allow it to be computed via number_of_nodes. I'm not sure what the suggested behavior here should be, but the current behavior is certainly surprising when you first encounter it. I was able to find the source issue fairly easily, but others may not be so lucky and resize operations do take down the cluster.

Whatever the code change is here I also suspect that some addition to the documentation is in order given that the below don't really fully explain the computed relationship.

number_of_nodes - (Optional) The number of compute nodes in the cluster. This parameter is required when the ClusterType parameter is specified as multi-node. Default is 1.

and

cluster_type - (Optional) The cluster type to use. Either single-node or multi-node.

documentation for convenience
original code change that seems to have caused the issue

@github-actions github-actions bot added the needs-triage Waiting for first response or review from a maintainer. label Dec 12, 2019
@DrFaust92 DrFaust92 added the service/redshift Issues and PRs that pertain to the redshift service. label May 21, 2020
@justinretzolk
Copy link
Member

Hey @mmccord-mdbuyline 👋 Thank you for taking the time to file this issue! Given that there's been a number of AWS provider releases since you initially filed it, can you confirm whether you're still experiencing this behavior?

@justinretzolk justinretzolk added waiting-response Maintainers are waiting on response from community or contributor. and removed needs-triage Waiting for first response or review from a maintainer. labels Nov 18, 2021
@ljluestc
Copy link


resource "aws_redshift_cluster" "example" {
  cluster_identifier = "example-cluster"
  node_type         = "dc2.large"  # Specify the desired node type
  number_of_nodes   = 2             # Set the desired number of nodes (for multi-node)

  # Omitting cluster_type to avoid tainting issues
  # cluster_type    = "multi-node"  # This line should be removed

  master_username   = "admin"
  master_password   = "yourpassword"  # Ensure this is secure
  db_name           = "mydatabase"
  skip_final_snapshot = true

  # Additional configuration as needed
}

@github-actions github-actions bot removed the waiting-response Maintainers are waiting on response from community or contributor. label Sep 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service/redshift Issues and PRs that pertain to the redshift service.
Projects
None yet
Development

No branches or pull requests

3 participants