"Provider produced inconsistent result after apply" creating multiple ec2 spot requests

[realflash]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.24

• provider.aws v2.56.0

Affected Resource(s)

aws_spot_instance_request

Terraform Configuration Files

resource "aws_spot_instance_request" "no_subnet_1" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_2" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_3" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_4" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_5" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_6" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_7" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_8" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_9" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

resource "aws_spot_instance_request" "no_subnet_10" {
  ami           = "ami-0ed2df11a6d41ea78"
  instance_type = "t3.nano"
  availability_zone = "eu-west-2a"
}

Debug Output

https://gist.githubusercontent.com/realflash/6d08ea50718075263a7d99b4c424dfd2/raw/49400c590bde68aaf6f35fb28c3a315a80497673/az.log

Expected Behaviour

10 spot requests created without error.

Actual Behaviour

10 spot requests created with errors implying only 5 were created. Incorrect state; subsequent plans indicate terraform want to create the 5 that errored previously.

Steps to Reproduce

1. terraform apply

[ewbankkit]

Maybe this is related to #12671?

[stefansundin]

@ewbankkit I am no expert, but I suspect it is not.

@realflash Have you run this before without issues? Is this a new problem? I think that would be an important data point.

I wonder if it is just because so many spot instance requests are created too quickly. Perhaps if wait_for_fulfillment = true was added to all of them (and maybe terraform apply -parallelism=1 was used), it may work better.

The log seems to indicate that the read immediately after the creation returns InvalidSpotInstanceRequestID.NotFound. Maybe the API is not perfectly read-after-write consistent and we need to retry for at least a few seconds?

[realflash]

What I was doing at the time was trying to get at the troublesome attribute for #12680

I was seeing the behaviour described in there (that the instance deployed was not in the requested region), and I thought there might be some kind of load balancing going on whereby AWS was creating the spot instance in the least loaded zone. So I thought I would create ten to see how many would end up in the requested zone. In the end, none did. This was the output from my first run of ten. My second run of ten, all of them completed and I did not get this error. So it is certainly not occurring every time.

I then did many more similar runs, knocking attributes out of my resource definition as I went to find the one causing the problem. I dropped down to five instances and then three as I became more confident that it was an attribute problem and not some kind of load balancing. Then on roughly run 7 (number of instances 3), the error occurred again. Run 8 went fine.

Given an occurrence rate of under 1 in 10, I'd say your theory is reasonable. Given a count of only three servers was enough to produce it, it seems likely to be a problem others will hit.

[ghost]

This has been released in version 3.35.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!