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

resource/aws_security_group: Set SchemaConfigModeAttr on egress and ingress configuration block attributes #8187

Merged
merged 2 commits into from Apr 5, 2019

Conversation

bflad
Copy link
Member

@bflad bflad commented Apr 4, 2019

Community Note

  • Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
  • Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

References:

In Terraform 0.12, behaviors with configuration blocks are more explicit to allow configuration language improvements and remove ambiguities that required various undocumented workarounds in Terraform 0.11 and prior. As a consequence, configuration blocks that are marked Optional: true and Computed: true will no longer support explicitly zero-ing out the configuration without special implementation.

The ConfigMode schema parameter on the configuration block attribute allows the schema to override certain behaviors. In particular, setting ConfigMode: schema.SchemaConfigModeAttr will allow practitioners to continue setting the configuration block attribute to an empty list (in the semantic sense, e.g. attr = []), keeping this prior behavior in Terraform 0.12. This parameter does not have any effect with Terraform 0.11. This solution may be temporary or revisited in the future.

Previous output from Terraform 0.11:

--- PASS: TestAccAWSSecurityGroup_Egress_ConfigMode (50.28s)
--- PASS: TestAccAWSSecurityGroup_Ingress_ConfigMode (49.85s)

Previous output from Terraform 0.12:

--- FAIL: TestAccAWSSecurityGroup_Egress_ConfigMode (31.74s)
    testing.go:568: Step 2 error: config is invalid: Unsupported argument: An argument named "egress" is not expected here. Did you mean to define a block of type "egress"?

--- FAIL: TestAccAWSSecurityGroup_Ingress_ConfigMode (31.94s)
    testing.go:568: Step 2 error: config is invalid: Unsupported argument: An argument named "ingress" is not expected here. Did you mean to define a block of type "ingress"?

Output from Terraform 0.11:

--- PASS: TestAccAWSSecurityGroup_Egress_ConfigMode (52.27s)
--- PASS: TestAccAWSSecurityGroup_Ingress_ConfigMode (53.55s)

Output from Terraform 0.12:

--- PASS: TestAccAWSSecurityGroup_Egress_ConfigMode (57.20s)
--- PASS: TestAccAWSSecurityGroup_Ingress_ConfigMode (55.80s)

…ngress configuration block attributes

References:

* hashicorp/terraform#20505
* hashicorp/terraform#20626

In Terraform 0.12, behaviors with configuration blocks are more explicit to allow configuration language improvements and remove ambiguities that required various undocumented workarounds in Terraform 0.11 and prior. As a consequence, configuration blocks that are marked `Optional: true` and `Computed: true` will no longer support explicitly zero-ing out the configuration without special implementation.

The `ConfigMode` schema parameter on the configuration block attribute allows the schema to override certain behaviors. In particular, setting `ConfigMode: schema.SchemaConfigModeAttr` will allow practitioners to continue setting the configuration block attribute to an empty list (in the semantic sense, e.g. `attr = []`), keeping this prior behavior in Terraform 0.12. This parameter does not have any effect with Terraform 0.11. This solution may be temporary or revisited in the future.

Previous output from Terraform 0.11:

```
--- PASS: TestAccAWSSecurityGroup_Egress_ConfigMode (50.28s)
--- PASS: TestAccAWSSecurityGroup_Ingress_ConfigMode (49.85s)
```

Previous output from Terraform 0.12:

```
--- FAIL: TestAccAWSSecurityGroup_Egress_ConfigMode (31.74s)
    testing.go:568: Step 2 error: config is invalid: Unsupported argument: An argument named "egress" is not expected here. Did you mean to define a block of type "egress"?

--- FAIL: TestAccAWSSecurityGroup_Ingress_ConfigMode (31.94s)
    testing.go:568: Step 2 error: config is invalid: Unsupported argument: An argument named "ingress" is not expected here. Did you mean to define a block of type "ingress"?
```

Output from Terraform 0.11:

```
--- PASS: TestAccAWSSecurityGroup_Egress_ConfigMode (52.27s)
--- PASS: TestAccAWSSecurityGroup_Ingress_ConfigMode (53.55s)
```

Output from Terraform 0.12:

```
--- PASS: TestAccAWSSecurityGroup_Egress_ConfigMode (57.20s)
--- PASS: TestAccAWSSecurityGroup_Ingress_ConfigMode (55.80s)
```
@bflad bflad added service/ec2 Issues and PRs that pertain to the ec2 service. technical-debt Addresses areas of the codebase that need refactoring or redesign. terraform-0.12 labels Apr 4, 2019
@bflad bflad added this to the 0.12-support milestone Apr 4, 2019
@bflad bflad requested a review from a team April 4, 2019 13:29
@ghost ghost added size/L Managed by automation to categorize the size of a PR. tests PRs: expanded test coverage. Issues: expanded coverage, enhancements to test infrastructure. labels Apr 4, 2019
@ghost ghost added the documentation Introduces or discusses updates to documentation. label Apr 4, 2019
Copy link
Member

@nywilken nywilken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@bflad bflad merged commit 4ad5f91 into master Apr 5, 2019
@bflad bflad deleted the td-aws_security_group-ConfigMode branch April 5, 2019 04:17
minamijoyo added a commit to minamijoyo/tfschema that referenced this pull request May 21, 2019
Fixes #9

Terraform v0.12 introduced a new `SchemaConfigModeAttr` feature.
Most attributes have simple types, but if `SchemaConfigModeAttr` is set for
an attribute, it is syntactically NestedBlock but semantically interpreted
as an Attribute. In this case, Attribute has a complex data type. It is
reasonable to use the same notation as the type annotation in HCL2 to
represent the correct data type. However, it seems that HCL2 has a type
annotation parser but no writer, so we implement it by ourselves.

See also:
- #9
- hashicorp/terraform-provider-aws#8187
- hashicorp/terraform#20626
- https://www.terraform.io/docs/configuration/types.html

This is a breaking change caused by the upstream,
so I think it is impossible to maintain tfschema backward compatibility.
I tried to be as consistent as possible.
@ghost
Copy link

ghost commented Mar 30, 2020

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!

@hashicorp hashicorp locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Introduces or discusses updates to documentation. service/ec2 Issues and PRs that pertain to the ec2 service. size/L Managed by automation to categorize the size of a PR. technical-debt Addresses areas of the codebase that need refactoring or redesign. tests PRs: expanded test coverage. Issues: expanded coverage, enhancements to test infrastructure.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants