-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Consume AWS SDK v2 #8896
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
Consume AWS SDK v2 #8896
Conversation
Updates cloudprovider/aws to use the new aws-sdk-go-v2. Notably, the v2 sdk is not vendored as the v1 sdk was. The individual servcies are now independent modules, vs using a large single monolithic version as the previous SDK did. The changes from the v1 SDK are generally as follows: * API types and methods are now split into distinct packages * Many API types changed to no longer use pointers to data * New API to innitiate an API (session.NewSession dropped) * Use of aws/smithy-go for configuring API middleware * Updates to override endpoint resolution
|
Hi @domenicbozzuto. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/cc @jackfrancis Tagging you as you have context on the other PR and discussed this with me in the sig-autoscaling meeting this week 👍 |
|
/ok-to-test |
|
@domenicbozzuto thank you for this, looks good! Are you willing to make a few housekeeping changes to the brightbox cloudprovider usage of the archived v1 SDK? It looks to me that once we remove those references, we can remove the v1 sdk from the core go.mod entirely, which would be a significant win IMO. |
The brightbox provider was the last remaining package that still consumed the v1 sdk. The code to generate the mocks in this SDK is not present here, so a small adapter struct was introduced to provide compatibility with the v2 sdk.
|
Thanks! 💯 Housekeeping has been taken care of; it looks like the most recent release of https://github.com/brightbox/k8ssdk (where I presume the vendored code here is from) still depends on the v1 SDK, so I introduced a small adapter to the v2 sdk to keep the interfaces the same (the go.mod should no longer contains any direct dependencies on the v1 sdk |
|
@domenicbozzuto that's a thing of beauty, thank you cc @NeilW |
jackfrancis
left a comment
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.
/lgtm
/approve
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: domenicbozzuto, jackfrancis The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/release-note-edit |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Updates cloudprovider/aws to use the new aws-sdk-go-v2. Notably, the v2 sdk is not vendored as the v1 sdk was. The individual servcies are now independent modules, vs using a large single monolithic version as the previous SDK did. The original aws-sdk-go package is officially deprecated, and the repo is now archived.
The changes from the v1 SDK are generally as follows:
I can formally remove the old vendored aws-sdk-go package in a subsequent PR, but didn't want to obscure the diff with the removal of 2000+ files.
Which issue(s) this PR fixes:
Fixes # #8671
Special notes for your reviewer:
There is some context in other PRs. I originally planned to vendor the aws-sdk-go-v2 as the v1 sdk was vendored; this work was done in #8265, and planned to consumed the vendored package with #8269.
However:
From the discussion on that PR, it was suggested it might make more sense to not vendor the package and use it directly; this is similar to how the new azure SDK for go is being handled.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: