[WIP] Provide ENI for AWS Instance.

[johnrengelman]

This is start for support for things like #3105.
Specifically, this address the use case of wanting to provide a known ENI to an AWS instance as it's primary network interface (for example, create an ENI, use it in the route table and boot an instance onto that ENI).

[catsby]

Is it valid for subnetID to not be specified when configuring an instance with an pre-existing ENI? Here, we haven't verified if subnetID is empty or not

[catsby]

We're also don't yet consider private_ip or vpc_security_group_ids, are those coming, or do they not apply here?

[johnrengelman]

This will need some more work I just wanted to get it out there before
going on travel.
Subnet_id cannot be specified with network interface.
I'll have to look into the others. My guess is that they should be be
specified since they'll be defined on the ENI.
On Wed, Dec 9, 2015 at 11:12 AM Clint notifications@github.com wrote:

In builtin/providers/aws/resource_aws_instance.go
#4231 (comment):

@@ -986,7 +997,15 @@ func buildAwsInstanceOpts(
}
}

• if hasSubnet && associatePublicIPAddress {
• if hasNetworkInterface {

•   ni := &ec2.InstanceNetworkInterfaceSpecification{
  

•       NetworkInterfaceId: aws.String(networkInterfaceID),
  

•       DeviceIndex:        aws.Int64(int64(0)),
  

•       SubnetId:           aws.String(subnetID),
  

We're also don't yet consider private_ip or vpc_security_group_ids, are
those coming, or do they not apply here?

—
Reply to this email directly or view it on GitHub
https://github.com/hashicorp/terraform/pull/4231/files#r47120749.

[catsby]

I thought it was probably a WIP, thanks. Ping us when you're ready!

[johnrengelman]

@catsby -
I'm not sure the best way to proceed on this.
When creating an ENI, you can specify private_ip and security_groups, however it seems that when assigning that to an Instance, if you also specify security_groups then the groups on the instance will replace the groups on the ENI.
However, setting the private_ip will not replace the existing private_ip on the ENI (but does not cause an error).
Setting subnet_id causes an error to occur.

I'm thinking the best way is that if specifying network_interface_id, then we disallow subnet_id, security_group, vpc_security_group_id, and private_ip from being specified and force their configuration via the ENI. Thoughts?

[johnrengelman]

On that note, if we go that path, what's the best way to validate that certain attributes aren't specified together? ConflictsWith won't work because they are Computed attributes as well.

[inkblot]

As far as the EC2 API is concerned, several of the parameters for an instance are effectively delegates for the parameters of the network interface that EC2 implicitly creates for the instance. In the case where existing network interfaces are explicitly supplied using NetworkInterface.N parameters, EC2 does not create an implicit network interfaces and these delegated parameters are invalid. Specifically, PrivateIpAddress, SecurityGroup.N, SecurityGroupId.N, and SubnetId are all mutually exclusive with NetworkInterface.N. Furthermore, the instance's sourceDestCheck attribute is inapplicable if network interfaces have been explicitly supplied to the instance.

[catsby]

Hey @johnrengelman terribly sorry for the silence here.
Looks at the SDK, it seems you are not supposed to supply the subnet id if you're supplying a network interface id, so I think you're idea on not allowing the others is correct.

Regarding validation, I honestly don't know from this vantage, we may just need to fall through to any error returned from AWS

[davidhoyt]

Where is this at? Can it be merged?

[johnrengelman]

@davidhoyt I've been waiting for some direction on how to implement this particular feature. See @inkblot's comments. The modeling in Terraform gets a little wonky here.

This has dropped off my radar as a priority since I came to it when trying to implement some better support for NAT routers in AWS and with the release of NAT Gateway, I am no longer reliant on this.

[catsby]

Sorry for the silence here friends – I relied with what I hope is good direction in this comment, let me know if this is something you're still willing to finish.

Thanks!

[lamdor]

@johnrengelman Is this waiting on anything? I found myself needing this. Looking over the code, it appears to be fine given @catsby's comment.

[johnrengelman]

@rubbish it needs some work on how to properly model some of the data. From what I remember, I was having issues with validating that a user wasn't providing conflicting data.
This is low on my list and I don't expect to get back to it anytime soon, so if someone wants to take up the mantle, I'm all for it.

[stack72]

Hi @johnrengelman

What is the status of this PR? Is this something that you think you would get back to or is this something we should close off?

Paul

[johnrengelman]

@stack72 - I'm not going to get back around to this. If someone wants to pick up and run with it, that would be awesome.

[stack72]

Closing this out since this particular version of the fix isn't going to be finished - thanks for all the work put in here @johnrengelman

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