ec2.Vpc does not work with IPAM

[titanous]

What happened?

VpcArgs has ipv4IpamPoolId and ipv4NetmaskLength fields, but it doesn't look like the code is set up to handle them.

pulumi-awsx/awsx/ec2/vpc.ts

Lines 80 to 83 in dfe6be7

	const cidrBlock = args.cidrBlock ?? "10.0.0.0/16";
	const subnetSpecs = getSubnetSpecs(name, cidrBlock, availabilityZones, args.subnetSpecs);
	validateSubnets(subnetSpecs, getOverlappingSubnets);

This code assumes that a static cidrBlock will be used and applies a default if one is not provided.

Steps to reproduce

Create a Vpc with ipv4IpamPoolId set.

Expected Behavior

The stack deploys.

Actual Behavior

  aws:ec2:Vpc (vpc-primary):
    error: aws:ec2/vpc:Vpc resource 'vpc-primary' has a problem: Conflicting configuration arguments: "ipv4_netmask_length": conflicts with cidr_block. Examine values at 'Vpc.Ipv4NetmaskLength'.
    error: aws:ec2/vpc:Vpc resource 'vpc-primary' has a problem: Conflicting configuration arguments: "cidr_block": conflicts with ipv4_netmask_length. Examine values at 'Vpc.CidrBlock'.

Versions used

CLI          
Version      3.34.1
Go Version   go1.17.11
Go Compiler  gc

Plugins
NAME    VERSION
aws     5.8.0
awsx    1.0.0-beta.8
docker  3.2.0
nodejs  unknown
random  4.8.0

Host     
OS       ubuntu
Version  20.04
Arch     x86_64

This project is written in nodejs: executable='/home/codespace/.nodejs/current/bin/node' version='v16.14.2'

Backend        
Name           codespaces-3c53a8
URL            s3://[REDACTED]
User           codespace
Organizations  

Dependencies:
NAME            VERSION
@pulumi/aws     5.8.0
@pulumi/awsx    1.0.0-beta.8
@pulumi/pulumi  3.34.1
@pulumi/random  4.8.0
@types/node     14.18.21

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[stack72]

Hi @titanous

Thanks so much for the report here - this is a scenario we have not covered so this is very useful for us! Are you able to show us what you think this should work like with the provider and what you'd expect the outputs to be?

Thanks

Paul

[titanous]

If IPAM IDs are specified, I think it should work like this:

• Create VPC with the IPAM IDs specified (v4 and/or v6) instead of a static CIDR, and require the respective netmask_length fields to be set so that subnets can be pre-calculated.
• Define subnets from the subnet specs using .apply() against the output CIDR fields from the VPC with the pre-calculated netmask for the subnet.

Does that make sense?

[stack72]

are there any defaults you feel are a good set here or should they always be required to set a netmask_lenght for a subnet type?

[titanous]

Thinking about it more I'm wondering if the netmask length is actually required, I think the apply function can just calculate the subnet as long as the subnets are sorted properly to binpack the requested subnet sizes. Worst case the function just errors out if the allocated VPC CIDR isn't big enough.

[BongoEADGC6]

@stack72 Having the same issue here. I'd think that the netmask of the VPC would need to be set as you would need to know how big your VPC needs to be as part of the IPAM provisioned CIDR.

@titanous Were you able to work around this?

[BongoEADGC6]

#1014 Starting this PR to attempt to fix this issue.

[ZacHigi]

I see this was briefly merged but then reverted. Any plans to address this soon?

Use case example:

const ipam_14 = new aws.ec2.VpcIpamPoolCidr("ipam-10-216", {
    cidr: "10.216.0.0/14",
    ipamPoolId: ipam_pool.id,
});

const customVpc = new awsx.ec2.Vpc(prefix, {
    numberOfAvailabilityZones: 3,
    subnetStrategy: SubnetAllocationStrategy.Auto,
    ipv4IpamPoolId: ipam_14.id,
    ipv4NetmaskLength: 16,
    subnetSpecs: [
        {
            type: SubnetType.Private,
            name: "Application",
            cidrMask: 19, //8190 hosts
            tags: { ...tags, label: "Application" }
        },
        {
            type: SubnetType.Public,
            name: "DMZ",
            cidrMask: 20, //4094 hosts
            tags: { ...tags, label: "DMZ" }
        },
        {
            type: SubnetType.Isolated,
            name: "TGW", 
            cidrMask: 28, //14 hosts
            tags: { ...tags, label: "TGW" }
        }
    ],
});

In this example the /14 has useable hosts 10.216.0.1 - 10.219.255.254.
I would expect this code would look at the IPAM provisioning and find first available /16.
If 10.216.0.0/16 already has IPs reporting into the IPAM but 10.217.0.0/16 has no conflicts, then this code would arrive at 10.217.0.0/16 for the CIDR block specified on the VPC.

Then all behavior would be the same as if the cidr block for 10.217.0.0/16 was defined directly in code, as far as the underlying subnets, detections for number of hosts being possible, etc.

[flostadler]

Sorry that you're running into this! I'll add it to our backlog.

If you're ok with loosing the dynamic part of IPAM, you could specify the cidrBlock as a workaround and remove the ipv4NetmaskLength. This way you'd at least get the VPC registered in the IPAM and get its reporting capabilities.