You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
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.
ghost
locked and limited conversation to collaborators
Mar 28, 2020
This issue was closed.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@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 acluster_type
ofsingle-node
andnumber_of_nodes
with1
and then resize the cluster by supplying acluster_type
ofmulti-node
andnumber_of_nodes
with2
then the resource will always be listed as "changed" in any subsequentapply
operations.In the plan output of any subsequent apply operations it will show
cluster_type
as changing frommulti-node
tomulti-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 acluster_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 vianumber_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.
and
documentation for convenience
original code change that seems to have caused the issue
The text was updated successfully, but these errors were encountered: