Skip to content
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

Would be good to sort data_aws_subnet_ids by availability zone #3471

Closed
foreverblue62 opened this issue Feb 21, 2018 · 6 comments
Closed

Would be good to sort data_aws_subnet_ids by availability zone #3471

foreverblue62 opened this issue Feb 21, 2018 · 6 comments
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/ec2 Issues and PRs that pertain to the ec2 service. stale Old or inactive issues managed by automation, if no further action taken these will get closed.

Comments

@foreverblue62
Copy link

We are in the process of rebuilding our accounts in AWS and one of the key components is building private and public subnets. As such the private subnets connect out to 0.0.0.0/0 via the a nat gateway. I have something similar to:

data "aws_subnet_ids" "selected_be" {
vpc_id = "${module.mainvpc.vpc_id}"
tags {
Location = "be"
}
}

Which will return three subnets tagged as "backend" - however it appears that these are return sorted by the subnet id. What I'd like to be able to do is get consistency that ${data.aws_subnet_ids.selected_be.ids[0] always returns the same az regardless of the subnetid ordering. So something like:

data "aws_subnet_ids" "selected_be" {
vpc_id = "${module.mainvpc.vpc_id}"
tags {
Location = "be"
}
sort_by = "AZ"
}

where sort_by is optional and will default to the existing behaviour.

@bflad bflad added enhancement Requests to existing resources that expand the functionality or scope. service/ec2 Issues and PRs that pertain to the ec2 service. labels Feb 22, 2018
@kl4w
Copy link
Contributor

kl4w commented Mar 5, 2018

Would it make sense to add a new field that allows you to filter the subnets by zone? This would also mean that you would have to create separate data resources for each zone though.

Something like this? https://github.com/kl4w/terraform-provider-aws/tree/filter-subnets-by-az

@TylerBrock
Copy link

I think the sort is more critical, IMHO. Getting this list order to be stable actually makes it useful downstream. Right now you wind up building subnet lists over and over again in anything remotely complicated to ensure that generated plans are consistent.

@pranj
Copy link

pranj commented Aug 9, 2018

Here is a quick and dirty workaround that I was able to use

data "aws_subnet" "private" {
  count = "${length(data.aws_subnet_ids.private.ids)}"
  id    = "${data.aws_subnet_ids.private.ids[count.index]}"
}

locals {
  subnet_az_to_id   = "${zipmap(data.aws_subnet.private.*.availability_zone, data.aws_subnet.private.*.id)}"
  subnet_az_to_cidr = "${zipmap(data.aws_subnet.private.*.availability_zone, data.aws_subnet.private.*.cidr_block)}"
  sorted_subnet_azs = "${sort(data.aws_subnet.private.*.availability_zone)}"
}

resource "null_resource" "sorted_subnet" {
  count = "${length(data.aws_subnet_ids.private.ids)}"

  triggers {
    id         = "${lookup(local.subnet_az_to_id, local.sorted_subnet_azs[count.index])}"
    cidr_block = "${lookup(local.subnet_az_to_cidr, local.sorted_subnet_azs[count.index])}"
  }
}

@b-luu
Copy link

b-luu commented Oct 16, 2018

Slight simplification: based on the idea that values() returns the values in the matching order to keys() which returns the keys lexically sorted.

data "aws_subnet" "private" {
  count = "${length(data.aws_subnet_ids.private.ids)}"
  id    = "${data.aws_subnet_ids.private.ids[count.index]}"
}

locals {
  ids_sorted_by_az   = "${values(zipmap(data.aws_subnet.private.*.availability_zone, data.aws_subnet.private.*.id))}"
  cidr_sorted_by_az = "${values(zipmap(data.aws_subnet.private.*.availability_zone, data.aws_subnet.private.*.cidr_block))}"
}

@github-actions
Copy link

github-actions bot commented Jan 7, 2021

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

@github-actions github-actions bot added the stale Old or inactive issues managed by automation, if no further action taken these will get closed. label Jan 7, 2021
@github-actions github-actions bot closed this as completed Feb 7, 2021
@ghost
Copy link

ghost commented Mar 10, 2021

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!

@ghost ghost locked as resolved and limited conversation to collaborators Mar 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/ec2 Issues and PRs that pertain to the ec2 service. stale Old or inactive issues managed by automation, if no further action taken these will get closed.
Projects
None yet
Development

No branches or pull requests

6 participants