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

provider/aws: aws_iam_policy_document data source #6881

Merged
merged 1 commit into from May 31, 2016

Conversation

jen20
Copy link
Contributor

@jen20 jen20 commented May 25, 2016

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.

such as the `aws_iam_policy` resource.

```
resource "aws_iam_policy_document" "example" {
Copy link
Member

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. 😀

@apparentlymart
Copy link
Member

Apart from that docs nit this LGTM, though I suppose I'm kinda reviewing my own code here. 😀

@phinze
Copy link
Contributor

phinze commented May 26, 2016

Apart from the outstanding docs tweak and test issue, this PR LGTM!

@jen20
Copy link
Contributor Author

jen20 commented May 27, 2016

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.

@jen20
Copy link
Contributor Author

jen20 commented May 27, 2016

There is stil the issue of the failing acceptance test which I believe is exposing a core bug in destroy:

    testing.go:300: Error destroying resource! WARNING: Dangling resources
        may exist. The full state and error is shown below.

        Error: Error applying: 1 error(s) occurred:

        * data.aws_iam_policy_document.test: unknown resource type: aws_iam_policy_document

        State: <no state>

vancluever pushed a commit to paybyphone/terraform that referenced this pull request May 28, 2016
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.
vancluever pushed a commit to paybyphone/terraform that referenced this pull request May 28, 2016
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.
vancluever pushed a commit to paybyphone/terraform that referenced this pull request May 29, 2016
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.
@vancluever
Copy link
Contributor

vancluever commented May 30, 2016

Just mentioned one thing in #4278 and I think I see one more too:

  • There needs to be some logic to ensure that array items like Actions get converted to strings instead of []strings if there is only one element (this was one of the things that was causing recurring diffs in unchanged policies). So those elements probably need to be interface{} and then handled accordingly.
  • Looks like some elements might be misspelled - at least according to the AWS docs and what I've always used (ie: Actions versus Action) I'll annotate the code. Scratch that - forgot to look at the struct tags :P

Looking forward to this one too as it's one less branch I need to maintain on my side!

@vancluever
Copy link
Contributor

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:

  • omitempty needs to be removed from Sid
  • We have to sort arrays, in reverse alphabetical order
  • Anything that takes a list value needs to be able to take a string value as well, which will be used in place of single element lists.

@vancluever
Copy link
Contributor

vancluever commented May 30, 2016

Hey guys, here's what I got for now:

paybyphone@7d4c122

Still gotta work on fixing the tests, will probably grab a couple from the policy generator and toss them in.

@vancluever
Copy link
Contributor

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.

@vancluever
Copy link
Contributor

Updated the commit with the updated test. Removed the blank element from condition, not too sure if that's a condition that we really need to handle, hopefully people won't be putting blank values in their document, however I'm not too sure if this might come up in interpolation?

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.
@phinze
Copy link
Contributor

phinze commented May 31, 2016

@jen20 If you drop the [WIP] and comment w/ the passing test this LGTM!

@jen20 jen20 changed the title [WIP]: provider/aws: aws_iam_policy_document data source provider/aws: aws_iam_policy_document data source May 31, 2016
@jen20
Copy link
Contributor Author

jen20 commented May 31, 2016

Tests now passing:

make testacc TEST=./builtin/providers/aws TESTARGS="-run TestAccAWSIAMPolicyDocument"
==> Checking that code complies with gofmt requirements...
/Users/James/Code/go/bin/stringer
go generate $(go list ./... | grep -v /vendor/)
2016/05/31 12:49:58 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run TestAccAWSIAMPolicyDocument -timeout 120m
=== RUN   TestAccAWSIAMPolicyDocument
--- PASS: TestAccAWSIAMPolicyDocument (6.40s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/aws    6.416s

@ghost
Copy link

ghost commented Apr 25, 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 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.

@hashicorp hashicorp locked and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants