-
-
Notifications
You must be signed in to change notification settings - Fork 317
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
Add "tenant", "labels_as_tags", and "descriptors" #132
Conversation
/test all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, a few nitpicks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I've added minor changes to language in both the README and the new tenant
variable. Not a must, but I think it would be nice.
Co-authored-by: Andriy Knysh <[email protected]> Co-authored-by: Yonatan Koren <[email protected]>
/test all |
/test all |
/test all |
main.tf
Outdated
} | ||
|
||
default_labels_as_tags = keys(local.tags_context) | ||
# Unlike other inputs, the first setting of `labels_as_tags` cannot be later overridden | ||
# We have to cover 2 cases. 1) context does not have a labels_as_tags key, 2) it is present and set to ["default"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a little confused about "default" and "unset" in labels_as_tags
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully clearer now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, please see comments
/test all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
The only change requested here is for a typo in README.yaml
.
The rest are either nitpicks or suggestions for better documentation — both inline in the code and in README.yaml
.
README.yaml
Outdated
becomes the new default for downstream modules. Also, collections are not overwritten, they are merged, | ||
so once a tag is added, it will remain in the tag set and cannot be removed, although its value can | ||
be overwritten. | ||
|
||
Because the purpose of `labels_as_tags` is primarily to prevent tags from being generated | ||
that would conflict with the AWS provider's `default_flags`, it is an exception to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default_flags
is a nonexistent AWS Provider argument — I'm sure you meant default_tags
.
that would conflict with the AWS provider's `default_flags`, it is an exception to the | |
that would conflict with the AWS provider's `default_tags`, it is an exception to the |
Secondly, "conflict with" might suggest that the AWS Provider would somehow error out if the tags exist in two places. At the very least, it doesn't explain which of these two — the AWS Provider or null-label
— takes precedent. Consider writing the following, which explains the situation a little more specifically:
that would conflict with the AWS provider's `default_flags`, it is an exception to the | |
that would override tags specified in the AWS provider's `default_tags` argument, it is an exception to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the AWS provider errors out if the same tag is set in two places.
/test all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
what
id
component:tenant
labels_as_tags
controls which labels are exported as tagsdescriptor_formats
generates new outputdescriptors
terraform-terraform-label
why
null-label
tenant
,labels_as_tags
,descriptor_formats
, add additional clarification, stop promoting obsolete module