Superfluous call to ModifyNetworkInterfaceAttribute

[brettahale]

Terraform Version

• TF 0.10.8
• AWS provider v1.6.0

Affected Resource(s)

• aws_instance

Terraform Configuration Files

resource "aws_instance" "web" {
  ami               = "${module.ami.ami_id}"
  availability_zone = "us-east-1a"
  instance_type     = "r4.large"
  ebs_optimized = "true"
  iam_instance_profile = "${aws_iam_instance_profile.default.name}"
  vpc_security_group_ids = ["sg-xxx","sg-xyx","sg-xyz"]
  subnet_id = "subnet-xxx"

  root_block_device {
    delete_on_termination   = "true"
    volume_size = "12"
  }
}

Debug Output

2018/02/07 18:40:22 [INFO] Modifying vpc_security_group_ids on Instance “i-xxxxxxxxxx”
2018/02/07 18:40:23 [DEBUG] [aws-sdk-go] DEBUG: Request ec2/ModifyNetworkInterfaceAttribute

Expected Behavior

I'm not sure why these are getting called. I wouldn't expect these. It feels like a race condition.

Actual Behavior

Given our ACLs we cannot do anything using the permission ec2/ModifyNetworkInterfaceAttribute and the TF job will fail. However, the instance gets created and works fine. Since the modifyNetworkAttribute action returns 403, I would expect the instance to be improperly configured but it seems to have no affect on the outcome. So why is that call needed? When I run this with volume attachments, ebs_volumes and other configs etc, since the job fails, I can't create all the resources I need.

Steps to Reproduce

1. terraform apply

Important Factoids

• Our AWS security and build pipelines prevent us from doing anything needing this permission ec2/ModifyNetworkInterfaceAttribute.

[brettahale]

More info --
Action=ModifyNetworkInterfaceAttribute&NetworkInterfaceId=eni-12345&SecurityGroupId.1=sg-f7890&SecurityGroupId.2=sg-f123456&Version=2016-11-15

it calls that action after getting the describe back showing the networkInterface setup with the same security-groups

        <networkInterfaceSet>
            <item>
                <networkInterfaceId>eni-12345</networkInterfaceId>
                <subnetId>subnet-xxx</subnetId>
                <vpcId>vpc-xxx</vpcId>
                <description/>
                <ownerId>111111111</ownerId>
                <status>in-use</status>
                <macAddress>12:2s:3d:bc:ef:d2</macAddress>
                <privateIpAddress>101.111.11.111</privateIpAddress>
                <privateDnsName>ip-101-111-11-111.ec2.internal</privateDnsName>
                <sourceDestCheck>true</sourceDestCheck>
                <groupSet>
                    <item>
                        <groupId>sg-f7890</groupId>
                        <groupName>onprem</groupName>
                    </item>
                    <item>
                        <groupId>sg-f123456</groupId>
                        <groupName>qa1east</groupName>
                    </item>
                </groupSet>
                <attachment>
                    <attachmentId>eni-attach-111111</attachmentId>
                    <deviceIndex>0</deviceIndex>
                    <status>attached</status>
                    <attachTime>2018-02-16T23:47:20.000Z</attachTime>
                    <deleteOnTermination>true</deleteOnTermination>
                </attachment>
                <privateIpAddressesSet>
                    <item>
                        <privateIpAddress>10.189.68.86</privateIpAddress>
                        <privateDnsName>ip-10-189-68-86.ec2.internal</privateDnsName>
                        <primary>true</primary>
                    </item>
                </privateIpAddressesSet>
                <ipv6AddressesSet/>
            </item>
        </networkInterfaceSet>
        <iamInstanceProfile>
            <arn>arn:aws:iam::1111111:instance-profile/xyz.test2</arn>
            <id>QQQQQQQQQQQQQQ</id>
        </iamInstanceProfile>
        <ebsOptimized>true</ebsOptimized>
        <enaSupport>true</enaSupport>
    </item>
</instancesSet>

heavily redacted

[hmalphettes]

Hi! I have the exact same issue.

The workaround has consisted of calling terraform apply twice:

terraform apply -var ... || terraform apply -var ...

[brettahale]

@hmalphettes Unfortunately that won't work for me because when this errors, the volume_attachment I have fails and when I run it twice, the ebs volume doesn't mount in time for the setup to succeed.

I feel like this https://github.com/terraform-providers/terraform-provider-aws/blob/3cff28ef3f7ad804393cf1b8e6b937a7f25cb31b/aws/resource_aws_instance.go#L917
should be:
if d.HasChange("vpc_security_group_ids") && !d.IsNewResource() {

[brettahale]

Pull Request

Tested locally and seemed to solve the issue

[hmalphettes]

@brettahale Much appreciated.

[bflad]

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

[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!