fix: Addresses persistent diff with manage_default_network_acl

[lorengordon]

As noted in the terraform docs, subnets using the default network acl
will generate a persistent diff if they are not specified to the aws_default_network_acl
resource. This module was handling subnets created by the module, but
of course is not aware of subnets created externally to the module.

The docs suggest using lifecycle ignore_changes as an option to avoid
the persistent diff, which is the approach implemented in this patch.

Fixes #736

Breaking Changes

None

How Has This Been Tested?

• I have tested and validated these changes using one or more of the provided examples/* projects

1. cd examples/network-acls
2. run terraform apply
3. manually create a new subnet in the vpc
4. run terraform apply
5. view that no changes are planned

[antonbabenko]

LGTM.

@bryantbiggs What do you think?

[antonbabenko]

Could you also fix the issue introduced by #742 here? :)

[lorengordon]

Could you also fix the issue introduced by #742 here? :)

Haha, sure, on my phone, gimme 30 min too get back to a computer

[lorengordon]

@antonbabenko Ok, should be good now!

[lorengordon]

Also, not sure if you are tracking this already, but there is some kind of issue going on with the cidr_blocks outputs for unused features. After first apply, they are lists of nulls, but the second apply they are reported as a planned change, becoming lists of empty strings...

Changes to Outputs:
  ~ database_subnets_ipv6_cidr_blocks    = [
      - null,
      - null,
      - null,
      + "",
      + "",
      + "",
    ]
  ~ elasticache_subnets_ipv6_cidr_blocks = [
      - null,
      - null,
      - null,
      + "",
      + "",
      + "",
    ]
  ~ intra_subnets_ipv6_cidr_blocks       = [
      - null,
      - null,
      - null,
      + "",
      + "",
      + "",
    ]
  ~ private_subnets_ipv6_cidr_blocks     = [
      - null,
      - null,
      - null,
      + "",
      + "",
      + "",
    ]
  ~ public_subnets_ipv6_cidr_blocks      = [
      - null,
      - null,
      - null,
      + "",
      + "",
      + "",
    ]
  ~ redshift_subnets_ipv6_cidr_blocks    = [
      - null,
      - null,
      - null,
      + "",
      + "",
      + "",
    ]

You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure.

[antonbabenko]

This PR is included in version 3.11.5 🎉

[antonbabenko]

Regarding the issue with outputs you are seeing, I don't think we have seen such behavior before.

[lorengordon]

Regarding the issue with outputs you are seeing, I don't think we have seen such behavior before.

Roger, I'll create a separate issue for that and see if I can track it down.

[bryantbiggs]

oy, this is still wrong! it should be

Suggested change

	values = [module.vpc.vpc_id]
	values = [data.aws_vpc_endpoint.dynamodb.id]

because the condition is "source VPC endpoint" not "source VPC"

[lorengordon]

That's what it was before #742 (attempted to) change it to the vpc id! Oi! Revert and revert and revert!

[bryantbiggs]

we can leave it as is now, but the condition is wrong - should be "aws:SourceVpc"

[lorengordon]

Looking at it again now, the data source is a race condition. The comment makes no sense. This whole thing is confusing to me. Why not just get the vpce id from an output of the vpc endpoint module?

[github-actions]

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.