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

Make service config just contain a FrozenLayer in the orchestrator mode #2762

Merged
merged 19 commits into from
Jun 16, 2023

Conversation

ysaito1001
Copy link
Contributor

@ysaito1001 ysaito1001 commented Jun 12, 2023

Motivation and Context

Service config structs now only contain a aws_smithy_types::config_bag::FrozenLayer in the orchestrator mode (no changes for the middleware mode).

Description

This PR reduces the individual fields of service configs to contain just FrozenLayer. This makes service configs work more seamlessly with runtime plugins in the orchestrator mode.

Note that service config builder s still contain individual fields. We're planning to make them just contain aws_smithy_types::config_bag::Layer. To do that, though, we need to make Layer cloneable and that will be handled in a separate PR. For builders, the only change you will in the PR is that their build method will put fields into a Layer, freeze it, and pass it to service configs.

This PR is marked as a breaking change because it's based on another PR that's also breaking change.

Testing

  • Passed tests in CI

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

This commit updates service configs to contain only a single field
`FrozenLayer` and remove individual fields. Note that their builders
still contain individual fields instead of just containing a `Layer`
because `Layer` is currently not `Clone`able.
@github-actions
Copy link

This commit modifies a Kotlin test for verifying dependencies brought in
by an inlineable module. Prior to the commit, the test used an
idempotency token, but with smithy-rs#2762, `IdempotencyTokenProvider`
will bring in `aws_smithy_types` due to that provider being defined in an
inlineable module. The test needed to be bifurcated between middleware
and orchestrator but that was not possible because the test was in
codegen-core and bifurcation was only possible in codegen-client. For
this reason, this commit switches the test to use another inlineable
module.
@ysaito1001 ysaito1001 marked this pull request as ready for review June 12, 2023 19:15
@ysaito1001 ysaito1001 requested review from a team as code owners June 12, 2023 19:15
@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

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.

Overall I really like the direction here.

Some things we should think about:

  1. In a RuntimePlugin world, I don't think we need to set defaults in the service config do we? We might want a separate plugin that sets defaults and keep the fields on service config optional...

  2. Some more thought about how we handle identity resolvers / interceptors is required I think

  3. In a RuntimePlugin world, I guess service config only needs to handle fields we aren't taking care of elsewhere, maybe eventually, it just holds onto the SdkConfig in it's runtime plugin state?

…egen/client/smithy/generators/config/ServiceConfigGeneratorTest.kt

Co-authored-by: Zelda Hessler <[email protected]>
@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@ysaito1001
Copy link
Contributor Author

Overall I really like the direction here.

Some things we should think about:

1. In a RuntimePlugin world, I don't think we need to set defaults in the service config do we? We might want a separate plugin that sets defaults and keep the fields on service config optional...

2. Some more thought about how we handle identity resolvers / interceptors is required I think

3. In a RuntimePlugin world, I guess service config **only** needs to handle fields we aren't taking care of elsewhere, maybe eventually, it just holds onto the SdkConfig in it's runtime plugin state?

Shared with Russell off-line that this PR is meant to be as dumb and mechanical as possible, simply translating what we currently have into the new way. We'll address provided feedback in a series of upcoming PRs (especially 1 and 3 above).

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

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.

Would it be simpler to use a ConfigBag in both middleware and orchestrator mode, and just change middleware code to call accessor methods instead?

@ysaito1001 ysaito1001 added the breaking-change This will require a breaking change label Jun 15, 2023
@ysaito1001
Copy link
Contributor Author

Would it be simpler to use a ConfigBag in both middleware and orchestrator mode, and just change middleware code to call accessor methods instead?

It's true that using ConfigBag in the middleware mode as well makes code changes simpler (since there's no need to bifurcate between two runtime modes), we should leave the middleware mode untouched in case there is a potential bug in ConfigBag we're not aware of.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@jdisanti
Copy link
Collaborator

We should add a changelog entry for the make_token rename

Renaming `make_token` to `idempotency_token_provider` will be handled in
a separate PR.
@ysaito1001
Copy link
Contributor Author

We should add a changelog entry for the make_token rename

Will do that as part of the next PR. Thanks for the suggestion.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@jdisanti jdisanti enabled auto-merge June 15, 2023 23:43
@jdisanti jdisanti added this pull request to the merge queue Jun 15, 2023
@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

Merged via the queue into main with commit 2e472d0 Jun 16, 2023
@jdisanti jdisanti deleted the ysaito/frozen-layer-backed-service-config branch June 16, 2023 00:09
ysaito1001 added a commit that referenced this pull request Jun 16, 2023
ysaito1001 added a commit that referenced this pull request Jun 16, 2023
## Motivation and Context
Incorporates suggestion made in
#2762 (comment)

## Description
This PR renames `make_token` to `idempotency_token_provider` for clarity
wherever it is referred to in the fields and API in service configs and
their builders.

## Testing
Existing tests in CI

## 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
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK 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._

---------

Co-authored-by: Yuki Saito <[email protected]>
ysaito1001 added a commit that referenced this pull request Jun 16, 2023
github-merge-queue bot pushed a commit that referenced this pull request Jun 21, 2023
## Motivation and Context
This PR will reduce fields in service config builders to contain only
`CloneableLayer` (except for `interceptors` and `identity_resolvers`).

## Description
This is the third PR in a series of config refactoring in the
orchestrator mode. Just like #2762, this PR reduces fields in service
config builders to contain `CloneableLayer`.

The code changes follow a straightforward pattern where builders'
setters are implemented via a config layer.

## Testing
Relies on the existing tests in CI

----

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

---------

Co-authored-by: Yuki Saito <[email protected]>
Co-authored-by: Zelda Hessler <[email protected]>
aws-sdk-rust-ci pushed a commit to awslabs/aws-sdk-rust that referenced this pull request Aug 3, 2023
## Motivation and Context
Incorporates suggestion made in
smithy-lang/smithy-rs#2762 (comment)

## Description
This PR renames `make_token` to `idempotency_token_provider` for clarity
wherever it is referred to in the fields and API in service configs and
their builders.

## Testing
Existing tests in CI

## 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
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK 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._

---------

Co-authored-by: Yuki Saito <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change This will require a breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants