fix(opensearchservice): access denied when creating a new domain in regions without cognito support#21395
Conversation
|
Update: I've sorted out access to an account for running the integration tests, so I'll run them myself and update the PR (reviewer will no longer need to execute them as indicated in the original PR body). I also found that the documentation currently fails to build a couple of code examples -- dove a bit deeper and noticed that the README is not following the recommendations from the contributions guide. Since I'm adding to the README in this PR anyway, I'm also going to add a commit to update existing code examples to follow the guidelines, and make them all build successfully in the process. |
TheRealAmazonKendra
left a comment
There was a problem hiding this comment.
Thank you for your contribution. Just a few small comments inline.
| import * as iam from '@aws-cdk/aws-iam'; | ||
|
|
||
| class Fixture extends Stack { | ||
| class Fixture extends core.Stack { |
There was a problem hiding this comment.
These updates aren't really necessary.
There was a problem hiding this comment.
While not strictly necessary, I thought it made sense to update it to follow the documentation recommendations in the contribution guidelines. Specifically Types from other modules should be qualified: and Types from the documented module should be un-qualified:
There was a problem hiding this comment.
If you want to change formatting of the documentation, please do it as a separate PR. Large PRs with changes that get lost in formatting changes will not receive the same level of detailed feedback because it's harder to do with so much extra noise. We certainly don't mind better documentation!
Rosetta files, however, should not be manually touched. They have to do with how we translate the documentation into other languages and between v1 and v2.
There was a problem hiding this comment.
Alright, I'll split it out into a new PR, though this does mean that the documentation build will continue to fail (it was failing before I made any changes due inconsistent use of "Domain" vs "opensearch.Domain" added in previous PRs).
That being said, in advance I'm just wondering about this: "Rosetta files, however, should not be manually touched". How is it expected to adjust how imports are represented in the documentation without adjusting the Rosetta file? I'm new to this, so may be missing something, but seems like this is necessary?
There was a problem hiding this comment.
If you're adding new imports it's fine, but the formatting we use for importing from core is consistent across all packages. No lie, I don't know why that's our convention and why we do it that way, but it's consistent and we should keep it that way.
There was a problem hiding this comment.
Also, there's a lot of stuff that we autogenerate in various processes through scripts and JSII. To your point about build failures from previous documentation inconsistency, if it's small, it's fine to include with other stuff but in general I'd just open the PR to make that fix first and then do the code change in a subsequent PR. Doc changes usually get merged pretty fast.
There was a problem hiding this comment.
Makes sense -- thanks for the feedback!
There was a problem hiding this comment.
So, yes, you can actually update the rosetta file, but you shouldn't change the style of imports. I misspoke earlier when I said they shouldn't be touched at all.
| "@aws-cdk/integ-runner": "0.0.0", | ||
| "@aws-cdk/cfn2ts": "0.0.0", | ||
| "@aws-cdk/pkglint": "0.0.0", | ||
| "@aws-cdk/aws-certificatemanager": "0.0.0", |
There was a problem hiding this comment.
Why are all these dependencies now necessary? I'm not seeing a change that would have necessitated it.
There was a problem hiding this comment.
Each of these was causing a build warning -- they're not strictly necessary, but it also seemed odd for the build to produce so many warnings.
| "@aws-cdk/aws-secretsmanager": "0.0.0", | ||
| "@aws-cdk/core": "0.0.0", | ||
| "@aws-cdk/custom-resources": "0.0.0", | ||
| "@aws-cdk/integ-tests": "0.0.0", |
There was a problem hiding this comment.
As far as I can tell, this should be the only additional dependency needed.
| "@aws-cdk/aws-secretsmanager": "0.0.0", | ||
| "@aws-cdk/core": "0.0.0", | ||
| "@aws-cdk/custom-resources": "0.0.0", | ||
| "@aws-cdk/integ-tests": "0.0.0", |
There was a problem hiding this comment.
But not needed here.
There was a problem hiding this comment.
Is there a guideline of how internal dependencies should be added? From what I can see, it seems to be standard to add them as peerDependencies, but if not added as devDependencies as well then the build produces warnings, which doesn't seem right?
There was a problem hiding this comment.
hmm. I'm not actually sure if we have this documented anywhere but basically, if it doesn't produce an error, don't add it.
There was a problem hiding this comment.
Alright, will change this back
There was a problem hiding this comment.
After taking a look, I think the warnings may actually be the result of these being declared as both peer dependencies and normal dependencies. But I'll check that theory in another PR with the documentation updates.
There was a problem hiding this comment.
Keep in mind some of why we do these oddities is that we translate these libraries into a half dozen languages and between v1 and v2 structure/conventions. Some of it might not align with what you've seen elsewhere because of that.
Pull request has been modified.
TheRealAmazonKendra
left a comment
There was a problem hiding this comment.
Additional requested changes still pending.
…egions without cognito support
Pull request has been modified.
TheRealAmazonKendra
left a comment
There was a problem hiding this comment.
Looks good now.
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…ed by the contribution guidelines (#21453) Follow up to #21395, making documentation changes that were split out from that PR. This change updates the README file to make the docs align with the style recommendations in the contribution guidelines. Specifically, the current docs do not follow this guideline: `Types from the documented module should be un-qualified`. ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Closes #21192
Currently the
CognitoOptionsattribute is always populated in the CloudFormation output when creating a new OpenSearch Domain, even ifcognitoDashboardsAuthis not passed into the constructor.Including this attribute, even with just the default body of
{ "Enabled": false }, causes deployments to fail in regions where Cognito isn't supported (e.g.cn-north-1), with the message:You don't have permissions to integrate with Cognito. Contact your admin if you need help. This change fixes this behavior by completely omitting the attribute ifcognitoDashboardsAuthis not passed into the constructor.I also updated the package.json file to fix several build warnings, and the README and default Rosetta fixture to fix a build error and make the docs align with the style recommendations in the contribution guidelines.
NOTE: Current snapshots are updated after running the integration tests, since the existing templates should no longer have
CognitoOptionspopulated. However, the snapshot for the newly added integration test has this attribute populated.All Submissions:
Adding new Unconventional Dependencies:
New Features
yarn integto deploy the infrastructure and generate the snapshot (i.e.yarn integwithout--dry-run)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license