CORS-4078: centralize v2 aws client constructions #9882
CORS-4078: centralize v2 aws client constructions #9882openshift-merge-bot[bot] merged 3 commits intoopenshift:mainfrom
Conversation
|
@tthvo: This pull request references CORS-4078 which is a valid jira issue. DetailsIn response to this:
Instructions 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 openshift-eng/jira-lifecycle-plugin repository. |
|
@tthvo: This pull request references CORS-4078 which is a valid jira issue. DetailsIn response to this:
Instructions 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 openshift-eng/jira-lifecycle-plugin repository. |
|
/label platform/aws Hold for thoroughly reviewing and checking these changes 😅 as they tend to break... |
|
/cc @barbacbd |
|
/unhold The changes seem OK from the results of CI jobs... |
Following session pattern in v1 sdk, we centralize the construction of v2 sdk aws.Config and API clients for better reusability. To remain backwards compatible, the following is in place: - New config and client constructs are in sessionv2.go while we gradually migrate parts of the installer code. - EndpointResolver v1 is kept around to resolve partition ID of a region. - Service ID in v1 is converted to v2 equivalent internally. The user can continue to use existing values while we migrate the sdk. Notes: - Default service endpoints for CN regions are not handled by the v2 endpoint resolver.
The following services are added: - github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 - github.com/aws/aws-sdk-go-v2/service/elasticloadbalancing - github.com/aws/aws-sdk-go-v2/service/resourcegroupstaggingapi
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: barbacbd 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 |
|
/test e2e-aws-ovn |
|
/lgtm |
|
@tthvo: The following tests failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
565c043
into
openshift:main
|
[ART PR BUILD NOTIFIER] Distgit: ose-baremetal-installer |
|
[ART PR BUILD NOTIFIER] Distgit: ose-installer |
|
[ART PR BUILD NOTIFIER] Distgit: ose-installer-artifacts |
patrickdillon
left a comment
There was a problem hiding this comment.
Left a suggestion for the future implementation, also I notice that the endpoint options contains configuration for FIPS endpoints. Good find. We will need to make sure that is set accordingly
| ec2Client, err := awsconfig.NewEC2Client(ctx, awsconfig.EndpointOptions{ | ||
| Region: installConfig.Config.Platform.AWS.Region, | ||
| Endpoints: installConfig.Config.Platform.AWS.ServiceEndpoints, | ||
| }) |
There was a problem hiding this comment.
You mentioned that you were still open to suggestions despite this having merged: I would suggest creating a function on metadata that can create or get a client without passing EndpointOptions. Similar to the current getSession:
we would have something that is just:
ec2Client, err := meta.EC2Client(ctx)
This will be beneficial whenever we need to construct new clients in the asset package (which is the most common use case), we know it will be correct, and users don't need to worry about correctly configuring endpoints or fips
There was a problem hiding this comment.
Oh right, sounds good! We do actually already have that function (but I am not using it here).
installer/pkg/asset/installconfig/aws/metadata.go
Lines 67 to 79 in 3b1baa0
I think what I am going to do is to create a "client set" in the metadata with all AWS clients, not just EC2 for easy use. Thanks!
There was a problem hiding this comment.
And I will replace these separately-created clients with the call to metadata in a follow-up PR.
Notes: I realized the changes are becoming way too large for review so I will split into them into 2 parts. This PR focuses on the config and client constructs.
CORS-4078 Part 1
Following session pattern in v1 sdk, we centralize the construction of v2 sdk aws.Config and API clients for better reusability.
To remain backwards compatible, I included the following:
sessionv2.gowhile we gradually migrate parts of the installer code.CORS-4078 Part 2
The following will be done in part 2 (in a follow-up PR):