-
Notifications
You must be signed in to change notification settings - Fork 132
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
Skip late initialization for several duplicate resource policy fields #1213
Skip late initialization for several duplicate resource policy fields #1213
Conversation
91042c7
to
68c8964
Compare
/test-examples="examples/sns/v1beta1/topic.yaml" |
Signed-off-by: Matt Bush <mbbush@gmail.com>
Signed-off-by: Matt Bush <mbbush@gmail.com>
Signed-off-by: Matt Bush <mbbush@gmail.com>
Signed-off-by: Matt Bush <mbbush@gmail.com>
Signed-off-by: Matt Bush <mbbush@gmail.com>
Signed-off-by: Matt Bush <mbbush@gmail.com>
Signed-off-by: Matt Bush <mbbush@gmail.com>
2b9a651
to
7d447bf
Compare
/test-examples="examples/sns/v1beta1/topic.yaml" |
/test-examples="examples/iam/v1beta1/role.yaml,examples/iam/v1beta1/role-with-inline-policy.yaml,examples/iam/v1beta1/rolepolicy.yaml" |
/test-examples="examples/sqs/v1beta1/queue.yaml,examples/sqs/v1beta1/queuepolicy.yaml" |
/test-examples="examples/kms/v1beta1/key.yaml" |
/test-examples="examples/kms/v1beta1/key.yaml" |
/test-examples="examples/iam/v1beta1/user.yaml" Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8445029595 |
/test-examples="examples/iam/v1beta1/role.yaml" Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8445085712 |
/test-examples="examples/iam/v1beta1/usergroupmembership.yaml" Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8445097629 |
/test-examples="examples/sns/v1beta1/topicsubscription.yaml" Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8445107700 |
/test-examples="examples/sqs/v1beta1/queue.yaml" Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8445120881 |
Not blocker: If possible and if not take much time, could you please make uptesable the InstanceProfile.iam.aws.upbound.io/v1beta1 resource with this PR? |
Signed-off-by: Matt Bush <mbbush@gmail.com>
/test-examples="examples/iam/v1beta1/instanceprofile.yaml" Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8457149351 |
/test-examples="examples/s3/v1beta1/bucketnotification.yaml" Uptest run: https://github.com/crossplane-contrib/provider-upjet-aws/actions/runs/8458801047 |
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.
Thank you for your effort in this PR @mbbush 🙌
Description of your changes
In several places in the terraform aws provider, there are two ways to specify a resource policy: a field named "policy" on the "foo" resource, and a separate resource named "foo_policy".
If we'd realized this before we'd committed to a stable API, perhaps the best option would have been to only provide one of those options, but it's too late for that now.
This PR removes conflicts between the resource policy managed on the parent resource, and the resource policy managed on the Policy resource, by skipping Late Initialization of the
policy
field on the parent resource, for the following resources:Key.kmsVpcEndpoint.ec2I made a semi-manual pass through the terraform aws provider docs, and these were the only examples I found, although I was not systematic and may have missed something. It seems like the resources with this behavior are the older resources, added to the terraform aws provider before they adopted more uniform best practices.
I initially included the VPC endpoint and KMS key, which both have a
spec.forProvider.policy
field, and a separate resource in terraform provider aws that sets that policy. However, neither theaws_kms_key_policy
noraws_vpc_endpoint_policy
resources exist in this provider yet. I'm undecided about whether it's better to skip late init for these parameters because we may someday implement the corresponding policy resource, whether we should avoid implementing those resources because the field already exists on the parent resource, or whether we should leave them be and defer the decision to the future. For now I've backed those commits out, but left them in the git history so they can be easily restored if desireable.While I was going through I updated the config files to the latest standards as well.
Fixes #1207
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
Running uptest on this PR.
I verified by looking at the uptest logs that the policy parameter was set in the status.atProvider and unset in the spec.forProvider, when that was expected, for:
SQS queues have a default policy of
""
, and IAM roles have a defaultinlinePolicies
that is null/empty array, so there's nothing to verify in the default case for those resources.