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

Remove non-inclusive terminology from aws_availability_zones data source attribute names #13766

Closed
breathingdust opened this issue Jun 15, 2020 · 10 comments · Fixed by #14134
Closed
Assignees
Labels
breaking-change Introduces a breaking change in current functionality; usually deferred to the next major release. enhancement Requests to existing resources that expand the functionality or scope. service/ec2 Issues and PRs that pertain to the ec2 service.
Milestone

Comments

@breathingdust
Copy link
Member

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Use the next major release as an opportunity to remove non-inclusive terminology in the provider codebase, documentation, and examples. We will be removing words whose meanings, origin, or associations are contrary to our Principles.

New or Affected Resource(s)

  • aws_availability_zones

Potential Terraform Configuration

Before:

data "aws_availability_zones" "test" {
  blacklisted_zone_ids = []
  blacklisted_names = []
}

After:

data "aws_availability_zones" "test" {
  skip_zone_ids = []
  skip_names = []
}

References

@breathingdust breathingdust added enhancement Requests to existing resources that expand the functionality or scope. breaking-change Introduces a breaking change in current functionality; usually deferred to the next major release. service/ec2 Issues and PRs that pertain to the ec2 service. labels Jun 15, 2020
@breathingdust breathingdust added this to the v3.0.0 milestone Jun 15, 2020
bflad added a commit that referenced this issue Jun 16, 2020
Reference: #13766

Changes:

* data-source/aws_availability_zones: Deprecate blacklisted_ arguments for skip_ arguments

Output from acceptance testing:

```
--- PASS: TestAccAWSAvailabilityZones_stateFilter (16.19s)
--- PASS: TestAccAWSAvailabilityZones_AllAvailabilityZones (16.22s)
--- PASS: TestAccAWSAvailabilityZones_Filter (16.33s)
--- PASS: TestAccAWSAvailabilityZones_basic (16.52s)
--- PASS: TestAccAWSAvailabilityZones_SkipZoneIds (17.68s)
--- PASS: TestAccAWSAvailabilityZones_BlacklistedZoneIds (17.75s)
--- PASS: TestAccAWSAvailabilityZones_BlacklistedNames (18.07s)
--- PASS: TestAccAWSAvailabilityZones_SkipNames (18.19s)
```
@bflad
Copy link
Contributor

bflad commented Jun 16, 2020

First pass: #13771

@chrisfowles
Copy link

Ironically exclude is probably better and less ambiguous terminology here.

i.e.

data "aws_availability_zones" "test" {
  exclude_zone_ids = []
  exclude_names = []
}

@myoung34
Copy link
Contributor

skip has some connotations to it about not being evaluated.
exclude makes more sense as a replacment term

@clort81
Copy link

clort81 commented Jun 17, 2020

This offends me.

@chrisfowles
Copy link

chrisfowles commented Jun 17, 2020

@myoung34 - while i agree they're similar, I feel that the intended action inflects different intents on the terms.

skip has some connotations to it about not being evaluated.
exclude makes more sense as a replacement term

in my understanding of common parlance:

skip is something that you do over a single item or set of items in a collection that you are iterating through. The connotations for skip for filtering are usually in terms of a number of records.

e.g. i want to read the this file but skip the first 2 lines.

exclude makes more sense on a data source as a filter.

e.g. i want to read this file but exclude any lines starting with cat.

@paultyng
Copy link
Contributor

@clort81 I edited your comment, the original comment was not in line with our community guidelines

People are free to discuss the technical considerations of this change, but as @breathingdust states in the original post, this is to bring the code in line with our internal standards, not a dicussion of what those standards are.

@lukashin

This comment has been minimized.

@hashicorp hashicorp locked and limited conversation to collaborators Jun 18, 2020
@paultyng
Copy link
Contributor

paultyng commented Jun 18, 2020

@lukashin this is a pretty bad faith reading of everything being discussed. The original post lists the specifics, and the referenced changes are a single data source and NOT upstream AWS API rendering much of your comments here moot.

I've hidden your response as it was also explicitly counter to what I previously said that this issue is not for discussion of the standards. Please refrain from further similar comments elsewhere.

@paultyng paultyng changed the title Remove Non-Inclusive Terminology Remove non-inclusive terminology from aws_availability_zones data source attribute names Jun 18, 2020
@bflad bflad self-assigned this Jul 10, 2020
@bflad
Copy link
Contributor

bflad commented Jul 14, 2020

Removal of the deprecated aws_availabiliity_zones arguments has been merged and will be released with version 3.0.0 of the Terraform AWS Provider, in about two weeks.

@ghost
Copy link

ghost commented Jul 31, 2020

This has been released in version 3.0.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

@ghost ghost unlocked this conversation Jul 31, 2020
@ghost ghost locked and limited conversation to collaborators Jul 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking-change Introduces a breaking change in current functionality; usually deferred to the next major release. enhancement Requests to existing resources that expand the functionality or scope. service/ec2 Issues and PRs that pertain to the ec2 service.
Projects
None yet
7 participants