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

feat: sdkv3 upgrade for CLI (wip) #31624

Closed

Conversation

TheRealAmazonKendra
Copy link
Contributor

Issue # (if applicable)

Closes #.

Reason for this change

Description of changes

Description of how you validated changes

Checklist


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@github-actions github-actions bot added the p2 label Oct 2, 2024
@aws-cdk-automation aws-cdk-automation requested a review from a team October 2, 2024 17:30
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Oct 2, 2024
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

@aws-cdk-automation aws-cdk-automation added the pr/needs-cli-test-run This PR needs CLI tests run against it. label Oct 2, 2024
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from 78798f5 to fd34c5c Compare October 3, 2024 10:14
packages/aws-cdk/lib/api/aws-auth/sdk-provider.ts Outdated Show resolved Hide resolved
// ECS and EKS instances also run on EC2 boxes but the creds represent something different.
// Same behavior as upstream code.
sources.push(() => new AWS.EC2MetadataCredentials());
return fromIni({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, SSO has precedence over process, but in fromIni, it's the other way around. It's highly unlikely that someone mistakenly configures both, but I think we should keep the current behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, fromIni actually covers SSO in v3. It didn't work with V2, which is why we manually put it ahead of Ini.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but we are changing the behavior now. If someone has both credential_process and sso_* set in their config file, the current version of the CLI will use the SSO credentials. With this change, after they upgrade, the CLI will start using the process credentials. Maybe this is ok, but but we need at least to document this somewhere.

Comment on lines +86 to +89
return shouldPrioritizeEnv()
? createCredentialChain(fromEnv(), nodeProviderChain).expireAfter(60 * 60_000)
: nodeProviderChain;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[feedback on readability] when I was reviewing this, I found it a bit hard to follow how the env variables fit into the chain. It's surprising to see a method whose name starts with "should" that modifies environment variables, that then gets picked up by fromEnv() (or not).

I suggest we implement our own provider that reads from both AWS_* and AMAZON_* sets of variables. And this provider is always put at the beginning of the chain. Up to you.

try {
await sdk.forceCredentialRetrieval();
// Force retrieval here
Copy link
Contributor

@otaviomacedo otaviomacedo Oct 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove this whole try-catch now, can't we?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Removing it.

packages/aws-cdk/lib/api/aws-auth/sdk.ts Outdated Show resolved Hide resolved
config: {
'profile ecs': { role_arn: 'arn:aws:iam::12356789012:role/Assumable', credential_source: 'EcsContainer', $account: '22222' },
// GIVEN
const calls = jest.spyOn(console, 'debug');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we be using the mocked metadata service?

@@ -35,15 +36,16 @@ interface AssumedRole {
* Instead, we want to validate how we're setting up credentials for the
* SDK, so we pretend to be the STS server and have an in-memory database
* of users and roles.
*
* With the v3 upgrade, this is only now half way being used as
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

being used as?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I died half way though writing this comment. There is no way of knowing the ending.

But also, the "as" is that the mock sdk client made some of it unnecessary. I'll fix this comment to clarify.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of deleting these tests, can't we keep them and use a mocked STS and a mocked token file?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why it's outdated, but the question still applies.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I deleted these instead of trying to rewrite them is that previously we wrote our own functionality for whether or not to call these, now we're just using the credential provider that the sdk provides so we'd essentially be unit testing their code, not ours.

packages/@aws-cdk/integ-runner/package.json Outdated Show resolved Hide resolved

const env = {
account: '123456789012',
region: 'us-east-1',
name: 'mock',
};

const templateBody = toYAML(deserializeStructure(serializeStructure(legacyBootstrapTemplate({}), true)));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference between this and:

const templateBody = serializeStructure(legacyBootstrapTemplate({}), false);

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is silly looking but unfortunately necessary. If we only serialize it, the template body isn't formatted correctly due to the escape characters that get added in. If we skip the deserialization/serialization part and just do toYAML, we get the same output.

Copy link
Contributor

@otaviomacedo otaviomacedo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also add some CLI integration tests for the credential loading scenarios.

@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from 66ed30f to 723afa7 Compare October 4, 2024 18:57
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from 723afa7 to f56fe7f Compare October 4, 2024 22:33
mergify bot pushed a commit that referenced this pull request Oct 7, 2024
…ns (#31658)

#31624 is too big so I'm splitting out the parts that I can without causing type conflicts. This upgrades all sdk v3 versions to the most recent version used in every region by lambda's node18 and node20 runtime bundle.

Closes #<issue number here>.

### Reason for this change



### Description of changes



### Description of how you validated changes



### Checklist
- [ ] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from f56fe7f to 4acc721 Compare October 7, 2024 19:55
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from 16ffad3 to 714b314 Compare October 8, 2024 09:05
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from 714b314 to de3c43d Compare October 8, 2024 09:09
@TheRealAmazonKendra TheRealAmazonKendra changed the title WIP: temp commit for sdkv3 upgrade feat: sdkv3 upgrade for CLI (wip) Oct 8, 2024
@TheRealAmazonKendra TheRealAmazonKendra added the pr-linter/exempt-readme The PR linter will not require README changes label Oct 8, 2024
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from de3c43d to 9b9c312 Compare October 8, 2024 09:26
@TheRealAmazonKendra TheRealAmazonKendra force-pushed the TheRealAmazonKendra/sdkv3-for-aws-cdk branch from 9b9c312 to c36eb47 Compare October 8, 2024 18:46
@TheRealAmazonKendra
Copy link
Contributor Author

This is succeeding in our build pipeline but not in the PR Build. What in the world is going on.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 28a5722
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

@TheRealAmazonKendra
Copy link
Contributor Author

We should also add some CLI integration tests for the credential loading scenarios.

Working on it!

@aws-cdk-automation
Copy link
Collaborator

The pull request linter fails with the following errors:

❌ CLI code has changed. A maintainer must run the code through the testing pipeline (git fetch origin pull/31624/head && git push -f origin FETCH_HEAD:test-main-pipeline), then add the 'pr-linter/cli-integ-tested' label when the pipeline succeeds.

PRs must pass status checks before we can provide a meaningful review.

If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing Exemption Request and/or Clarification Request.

@rix0rrr rix0rrr closed this Nov 20, 2024
@rix0rrr rix0rrr deleted the TheRealAmazonKendra/sdkv3-for-aws-cdk branch November 20, 2024 12:47
Copy link

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 20, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
contribution/core This is a PR that came from AWS. p2 pr/needs-cli-test-run This PR needs CLI tests run against it. pr-linter/exempt-readme The PR linter will not require README changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants