-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
provider/aws: aws_iam_policy_document data source #6881
Conversation
such as the `aws_iam_policy` resource. | ||
|
||
``` | ||
resource "aws_iam_policy_document" "example" { |
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.
This should say data
instead of resource
now. 😀
Apart from that docs nit this LGTM, though I suppose I'm kinda reviewing my own code here. 😀 |
Apart from the outstanding docs tweak and test issue, this PR LGTM! |
7b1aa59
to
2c32037
Compare
Thanks - I reviewed the code as I ported it and it looked fine. I'll push another commit that more accurately reflects the provenance of this work though since it's almost entirely unaltered from @apparentlymart's original PR! The docs have been updated - I think we should add a giant note at the top about the differing native interpolation syntax though. |
There is stil the issue of the failing acceptance test which I believe is exposing a core bug in destroy:
|
During accpeptance tests of some of the first data sources (see hashicorp#6881 and hashicorp#6911), "unknown resource type" errors were coming up. It looks like DataSourcesMap was not being taken into account in *schema.Provider.Apply(), causing this error. Also, added a skip in *schema.Resource.Apply() if *schema.Resource.Destroy() is not defined, as data sources do not define this, fixing the first error resulted in a nil pointer dereference.
During accpeptance tests of some of the first data sources (see hashicorp#6881 and hashicorp#6911), "unknown resource type" errors were coming up. It looks like DataSourcesMap was not being taken into account in *schema.Provider.Apply(), causing this error. Also, added a skip in *schema.Resource.Apply() if *schema.Resource.Destroy() is not defined, as data sources do not define this, fixing the first error resulted in a nil pointer dereference.
During accpeptance tests of some of the first data sources (see hashicorp#6881 and hashicorp#6911), "unknown resource type" errors have been coming up. Traced it down to the ResourceCountTransformer, which transforms destroy nodes to a graphNodeExpandedResourceDestroy node. This node's EvalTree() was still indiscriminately using EvalApply for all resource types, versus EvalReadDataApply. This accounts for both cases via EvalIf.
Just mentioned one thing in #4278 and I think I see one more too:
Looking forward to this one too as it's one less branch I need to maintain on my side! |
Just gave this a whirl, gist below has the diff from the S3 bucket policy: https://gist.github.com/vancluever/526e9c1d8153436e58244847b8fb20f1 Few things probably need to be done here:
|
Hey guys, here's what I got for now: Still gotta work on fixing the tests, will probably grab a couple from the policy generator and toss them in. |
Hmm, okay, the policy generator is generating policies that are not what the API would give back either. I'm just going to adjust the test, maybe if we get some people trying this out and send in any feedback if they get a diff that would be good. |
Updated the commit with the updated test. Removed the blank element from |
This brings over the work done by @apparentlymart and @radeksimko in PR #3124, and converts it into a data source for the AWS provider: This commit adds a helper to construct IAM policy documents using familiar Terraform concepts. It makes Terraform-style interpolations easier and resolves the syntax conflict between Terraform interpolations and IAM policy variables by changing the latter to use &{...} for its interpolations. Its use is completely optional and users are free to go on using literal heredocs, file interpolations or whatever else; this just adds another option that fits more naturally into a Terraform config.
2c32037
to
c91d62f
Compare
@jen20 If you drop the |
Tests now passing:
|
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
This brings over the work done by @apparentlymart and @radeksimko in PR #3124, and converts it into a data source for the AWS provider.
It adds a helper to construct IAM policy documents using familiar Terraform concepts. It makes Terraform-style interpolations easier and resolves the syntax conflict between Terraform interpolations and IAM policy variables by changing the latter to use &{...} for its interpolations.
Its use is completely optional and users are free to go on using literal heredocs, file interpolations or whatever else; this just adds another option that fits more naturally into a Terraform config.
Currently the tests are failing, which needs investigation.