-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ipv6 support #16
Comments
Yes, but PR is welcome :) |
As far as I can tell, there is no simple way to make ipv6 optional due to subnet creation argument requirements and the fact that you do not specify your own ipv6 cidr block. Here is the behavior I saw: The ipv6_cidr_block vpc attribute is only created if you enable ipv6 in the aws_vpc definition. Since you must specify the subnet ipv6_cidr_block argument at the time of subnet creation, and because you must use the ipv6_cidr_block vpc attribute in the calculation of the ipv6 subnet cidr, this vpc attribute MUST exist. If it does not exist then terraform (as of 0.10.7) will complain when trying to calculate the subnet ipv6_cidr_block block argument. abbreviated example: resource "aws_vpc" "this" {
cidr_block = "${var.cidr}"
instance_tenancy = "${var.instance_tenancy}"
enable_dns_hostnames = "${var.enable_dns_hostnames}"
enable_dns_support = "${var.enable_dns_support}"
--> assign_generated_ipv6_cidr_block = "${var.enable_ipv6}"
tags = "${merge(var.tags, map("Name", format("%s", var.name)))}"
}
resource "aws_subnet" "public" {
count = "${length(var.public_subnets)}"
vpc_id = "${aws_vpc.this.id}"
cidr_block = "${var.public_subnets[count.index]}"
--> ipv6_cidr_block = "${var.enable_ipv6 ? cidrsubnet(aws_vpc.this.ipv6_cidr_block,8,count.index) : ""}"
availability_zone = "${element(var.azs, count.index)}"
map_public_ip_on_launch = "${var.map_public_ip_on_launch}"
tags = "${merge(var.tags, var.public_subnet_tags, map("Name", format("%s-public-%s", var.name, element(var.azs, count.index))))}"
} This works great if var.enable_ipv6 is set to true. When set to false, terraform apply will throw this: * module.vpc.aws_subnet.public[0]: Resource 'aws_vpc.this' does not have attribute 'ipv6_cidr_block' for variable 'aws_vpc.this.ipv6_cidr_block' Since I don't believe it's currently possible to have a conditional argument based on the existence of an attribute, I believe the only way to do this would be to specify an entirely new resource set based on the condition of ipv6 being enabled. @antonbabenko I'd like to work on this, but would like the team's input on whether or not there is a better implementation than an entire copy/paste set of conditional resources. |
that's an easy one, isnt it? |
Hi Fernando, Just trying to clarify your comment - if you are referring to the vpc attribute, you cannot assign it a value like a variable (that I'm aware of). If you are referring to the ipv6_cidr_block argument in the subnet declaration, the problem is that the ternary operation errors out on the non-existence of the vpc attribute and does not assign a default value. ipv6_cidr_block = "${var.enable_ipv6 ? cidrsubnet(aws_vpc.this.ipv6_cidr_block,8,count.index) : ""}" ^^ this would and probably should assign it a default value of "", but terraform does not get that far because it cannot complete the conditional due to the non-existence of the aws_vpc.this.ipv6_cidr_block attribute (see the exception thrown in my previous comment). The issue I'm running into with a separate set of conditional resource declarations is that having two possible sets of resources messes with the outputs and leaves a number of them empty due to the conditional creation of alternatively named resources. In other words, the following will be empty unless aws_subnet.public exists: output "public_subnets" {
description = "List of IDs of public subnets"
value = ["${aws_subnet.public.*.id}"]
} and I can't (again, to my knowledge) tell terraform to change the value of the output to ${aws_subnet.public_ipv6.*.id} if ipv6 is enabled. This would mean we would need to create another set of ipv6-specifically-named outputs, and again, I'm unsure if this is ideal. I'm not sure if the maintainers would prefer to just split an ipv6-enabled vpc module out into a different repo, or have a different and better implementation plan, but I'll be working on a PR for this repo until I hear otherwise. Please let me know if you've had a different experience with any of the above or need further clarification! |
I see your problem, is evaluating something that doesnt exist. |
FYI #21 is in progress |
https://cloudiamo.com/2017/02/14/enabling-ipv6-on-existing-vpcs-and-subnets/ |
@emvaldes The issue is if I manually add an ipv6 CIDR to my VPC, when I rerun terraform it will show the below ~ module.platform_oregon_v2.module.vpc.aws_vpc.this any ideas around this? |
I have updated this module by adding support for Note, that this adds IPv6 support only to VPC and not to other resources. Adding IPv6 support to |
v2.10.0 has been released (see #317). @FernandoMiguel , it is now done. It took a couple of years :) |
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. |
Are there plans to include IPv6 support to this module?
The text was updated successfully, but these errors were encountered: