-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
provider/aws: Changing count of instances with volume attachments causes all attachments to be forced to new resources #5240
Comments
another error case: Build the instances as above. Then taint aws_instance.kube_worker.0 and plan. Plan shows this output:
Notice that it wants to rebuild the aws_volume_attachment for aws_instance.kube_worker.1 which it should not do. Running plan causes:
because the instance at count 1 is still running and has the volume attached. To make this work, I have toterminate all the |
I think this issue is caused by the problem reported in #2957. |
I'm seeing the same issue, while using the cloudstack provider. Every time I increase the count, terraform wants to update all resources (not just the new one). |
I've had same issue with EBS vols, which I could work around by moving from separate EBS resource definition to incorporating it into aws_instance resource. Then it started to happen with EIP which can't be defined within aws_instance. The work around that seem to work so far is adding ignore_changes for the attribute that appears in "Mismatch reason". For me it was adding this block to aws_eip definition :
|
@hsergei thank you for posting your workaround (p.s. it works equally as well for |
I also used the function format_if_necessary() {
echo "$(date '+%Y-%m-%d %H:%M:%S') format_if_necessary ${1}" >> ~/user-data.log 2>&1
# return if $1 is not a block device path
[ -b ${1} ] || return 1
# format the block device if it isn't already
[ $(sudo blkid ${1} > /dev/null 2>&1; echo $?) = 0 ] || sudo mkfs -t ext4 ${1} >> ~/user-data.log 2>&1
} |
@PaulCapestany Your solution of using ignore_changes = ["volume", "instance"] does not work when I destroy an instance. Terraform has the correct plan: destroy instance and destroy it's volume_attachment. terraform apply fails: "aws_volume_attachment.attach.2: Error waiting for Volume (vol-xyz) to detach from Instance" Did you try to destroy an instance and see the expected result: instance and attachment destroyed, volume detached? |
No I did not test destroy. I guess you can always remove ignore_changes and let TF use its default behavior |
@hsergei @PaulCapestany : I succeeded only by stopping the instance I want to destroy via console. looks like terraform does not stop instance; this causes volume to move from "in-use" to "busy" verified: terraform's order of destroying resources:
would be better to destroy the instance before destroying the attachment so that if |
the bug with aws_volume_attachment is that the destroy does not unmount the volume from a running instance |
Use destroy provisioners to unmount volumes. |
I'm hitting this too. I would like Terraform to just destroy the instances (causing the volumes to be detached "naturally") but apparently this is not possible, because terraform never gets to actually destroying the instance because it wants to destroy the attachment first, which will never work. Stopping the instance first helps, but I don't see why it should be necessary. |
@c4milo : please give an example with a code snippet. in the docs, I don't know which provisioner you might be talking about. Thanks. |
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. |
here's the scenario: (using latest 0.6.11)
have a cluster of aws_instance with a count
each instance has an aws_ebs_volume and a corresponding aws_volume_attachment, each using the same count (obviously)
all is well for the initial plan/apply
Now, increase the count by 1. Expect to simply add another instance with its ebs volume and attachment.
Instead, Terraform wants to force new resource for ALL the volume attachments. not good!
here's an example (ive removed some of the irrelevant detail so this might now work as is)
if you plan/apply this, then change the 5's to 6's and re-plan, you get something that wants to force a new resource fo the first 5 volume attachments, because it thinks the instance_id and volume_id have changed (which they have not, obviously).
( I unfortunately did not save the actual log.)
This of course fails, because the volumes are still there and attached and Terraform cannot re-attach them.
My only recourse was to taint the existing instances and rebuild them all. This is bad, as I would like to be able to non-disruptively add a new node to my Kubernetes cluster using Terraform. I used to be able to do this before I had these volume attachments on each node.
The text was updated successfully, but these errors were encountered: