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

rfc: change default identity cache and partitioning #3544

Merged

Conversation

aajtodd
Copy link
Contributor

@aajtodd aajtodd commented Apr 2, 2024

Motivation and Context

Original issue: #3427

See the motivation section of the RFC.

Description

Proposes a new RFC that changes the default behavior of SdkConfig and SharedCredentialsProvider/SharedTokenProvider w.r.t caching and cache partitions.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@aajtodd aajtodd requested review from a team as code owners April 2, 2024 16:40
Copy link
Collaborator

@rcoh rcoh left a comment

Choose a reason for hiding this comment

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

design LGTM. I think this is missing a change checklist item for actually using the cache partition in the identity cache. It may be helpful to also add some color about how the goal of the identity cache partitions was to create a concept of pointer equality for identity providers so that we could decouple the identity resolver themselves from the cache implementation.

May be helpful to answer the question of how we will create new partitions etc.

@rcoh
Copy link
Collaborator

rcoh commented Apr 2, 2024

I think the RFC may also want to discuss the alternatives to address this issue

@ysaito1001
Copy link
Contributor

I think this is missing a change checklist item for actually using the cache partition in the identity cache

My understanding is that the cache partition is already used? and it's just that a SharedCredentialsProvider previously returned None, forcing a new partition to be created. After implementing checklist items things should be wired up automatically, I think.

@aajtodd
Copy link
Contributor Author

aajtodd commented Apr 2, 2024

I think this is missing a change checklist item for actually using the cache partition in the identity cache

My understanding is that the cache partition is already used? and it's just that a SharedCredentialsProvider previously returned None, forcing a new partition to be created. After implementing checklist items things should be wired up automatically, I think.

That is coming from SharedIdentityResolver, I'll make it more explicit but we will need to wire it up in SharedIdentityResolver::new and see if the given resolver.cache_partition() is set.

@aajtodd aajtodd added this pull request to the merge queue Apr 5, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 5, 2024
@aajtodd aajtodd added this pull request to the merge queue Apr 5, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 5, 2024

```rust,ignore
let config = aws_config::defaults(BehaviorVersion::latest())
.set_identity_cache(None)
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 apparently doesn't exist on ConfigLoader, it only exists on the explicit client config. We'll probably instead need something like no_identity_cache() to match no_credentials()

@aajtodd aajtodd force-pushed the atodd/rfc-identity-cache-partition branch from e63895f to 4a8757c Compare April 5, 2024 20:44
@aajtodd aajtodd enabled auto-merge April 5, 2024 20:45
@aajtodd aajtodd mentioned this pull request Apr 5, 2024
1 task
Copy link
Collaborator

@jdisanti jdisanti left a comment

Choose a reason for hiding this comment

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

Nicely written RFC!

each time a client is created.
* More specifically this happens every time a `SharedIdentityResolver` is [created](https://github.com/smithy-lang/smithy-rs/blob/release-2024-03-25/rust-runtime/aws-smithy-runtime-api/src/client/identity.rs#L197). The conversion from [`From<SdkConfig>`](https://github.com/awslabs/aws-sdk-rust/blob/release-2024-04-01/sdk/sts/src/config.rs#L1207)
sets the credentials provider which [associates](https://github.com/awslabs/aws-sdk-rust/blob/release-2024-04-01/sdk/sts/src/config.rs#L960) it as
the identity resolver for the auth scheme. Internally this is [converted](https://github.com/awslabs/aws-sdk-rust/blob/release-2024-04-01/sdk/aws-smithy-runtime-api/src/client/runtime_components.rs#L663) to `SharedIdentityResolver` which creates the new partition. The end result is the credentials
Copy link
Collaborator

Choose a reason for hiding this comment

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

If it were already a SharedIdentityResolver, then the IntoShared implementation should detect that and wouldn't create a new instance. So that means it must be a SharedCredentialsProvider that's getting converted into a SharedIdentityResolver. This could be made clearer here.


```

Additionally a new behavior version must be introduced that conditionally creates a default `IdentityCache` on `SdkConfig`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Most of the defaults are provided by runtime plugins later on. Why would this one get a default at this stage?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we don't then each client gets their own identity cache rather than sharing one. Even if we fix the cache partitioning the default behavior will still end up being that multiple clients created from SdkConfig don't actually share cached results.

This can be worked around of course by explicitly providing a cache to SdkConfig but if the default behavior we want is to enable caching it probably makes sense to just make it so.

@aajtodd aajtodd force-pushed the atodd/rfc-identity-cache-partition branch from 4a8757c to 16799c0 Compare April 8, 2024 14:53
@aajtodd aajtodd force-pushed the atodd/rfc-identity-cache-partition branch from 16799c0 to 0922240 Compare April 9, 2024 17:42
@aajtodd aajtodd added this pull request to the merge queue Apr 9, 2024
Merged via the queue into smithy-lang:main with commit 8040cce Apr 9, 2024
41 of 42 checks passed
@aajtodd aajtodd deleted the atodd/rfc-identity-cache-partition branch April 9, 2024 18:38
github-merge-queue bot pushed a commit that referenced this pull request Apr 10, 2024
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Original issue: #3427
RFC: #3544

## Description
<!--- Describe your changes in detail -->

Fixes the `SharedCredentialsProvider` and `SharedTokenProvider` to
re-use a consistent cache partition by default.
`SdkConfig` does not create an identity cache by default still, that
will need to be a follow on PR that gates it behind a new behavior
version. Ideally we do that with the stalled stream protection work in
#3527


## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
Added new unit and integration tests.

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [X] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates


----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants