spot_instance_request: fixed network interfaces configuration

[hrach]

Fixes configuration public ip for spot_instance_request. Originally hashicorp/terraform#13736 & bug hashicorp/terraform#9575.

[hrach]

Hm, I can't see how it the test failure related to this PR. Previously it has passed test ok.

[radeksimko]

Hi @hrach
I think the failure may be caused by wrong path. The right path begins with aws/ whereas in your diff you're moving that file to providers/aws/.... 😉

[hrach]

@radeksimko thanks a lot. I have wrongly modified the patch; fixed now.

[radeksimko]

Hi @hrach
thanks for the PR and sorry to keep you waiting here.

It would be great to have a test covering this bugfix to make sure we won't break it again in the future.

Basically you can copy one of the existing tests here https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_spot_instance_request_test.go#L15 and modify accordingly.

Then you can run the test against an AWS account like this:

AWS_PROFILE=yourprofile make testacc TESTARGS='-run= TestAccAWSSpotInstanceRequest_nameOfYourNewTest'

I hope the above makes sense.

I left you one question there regarding the implementation.

[radeksimko]

Is there any reason we can't just add this line here?

spotOpts.LaunchSpecification.NetworkInterfaces = instanceOpts.NetworkInterfaces

We don't seem to have a test covering the case in the comment here, but I'd be worried that removing the logic may break some unrelated edge cases... 🤔

[hrach]

Ok, repushed.

• I've left my implementation. It seems correct to me. The pull request with the discussed logic is providers/aws: Update Spot Instance request to provide connection information  terraform#3940. It also contains tests, so the if is/was tested. Since the method RequestSpotLaunchSpecification is from the official aws sdk, I think they may have also fixed and it should/may return correctly initizialized object.
• Added tests have passed:

TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v -run=TestAccAWSSpotInstanceRequest_SubnetAndSGAndPublicIpAddress -timeout 120m
?       github.com/terraform-providers/terraform-provider-aws   [no test files]
=== RUN   TestAccAWSSpotInstanceRequest_SubnetAndSGAndPublicIpAddress
--- PASS: TestAccAWSSpotInstanceRequest_SubnetAndSGAndPublicIpAddress (151.46s)
PASS
ok      github.com/terraform-providers/terraform-provider-aws/aws       151.509s

I'm definitely open to fix it as you wish, though, I have no idea how to make further inspection of aws-sdk to validate my points.

[hrach]

Well, the bad thing is that the test also pass when I do not apply the fix :-O So probably I would need some guidance what and how should I test the real instance setting.

[radeksimko]

I think they may have also fixed and it should/may return correctly initizialized object.

That's a good point, although given the structure of the AWS SDK and the way it works it would has to be an API (server side) fix, because the SDK structures are pretty much all generated from API JSON/XML structures. There's rarely any (if any) custom parsing logic. Server-side bugfix is certainly what may have happened though 👍

I don't have too strong opinion on this, so as long as @catsby is happy as the original author of the linked PR, we're all happy. 😃

Well, the bad thing is, that the test also pass when I do not apply the fix

I think the reason the test is passing is because we're launching the instance into a subnet with auto-assignment enabled, as mentioned in this comment.

If you set map_public_ip_on_launch = false in the test config you should see a failure (without the bugfix).

It's not necessary, but if you want you can also make the test more thorough by checking API response, e.g. adding a condition to testAccCheckAWSSpotInstanceRequest_InstanceAttributes or adding a new check for the spot request:

testAccCheckAWSSpotInstanceRequest_attributes(&sir),

where you can check contents of sir.LaunchSpecification.NetworkInterfaces.

As a side note it would be nice to separate this test instead of modifying an existing one so we can cover that specific use-case in isolation from others. Copy-pasting is totally aok in test cases.

[catsby]

Merged in #1070 , 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!