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.

Sign up for GitHub

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

Jump to bottom

all: Migrate AWS SDK to V2 #3458

Open
Maldris opened this issue Aug 4, 2024 · 3 comments
Open

all: Migrate AWS SDK to V2 #3458

Maldris opened this issue Aug 4, 2024 · 3 comments

Comments

@Maldris
Copy link

Maldris commented Aug 4, 2024

Is your feature request related to a problem? Please describe.

The V1 AWS SDK has officially entered maintenance mode (31st July 2024).
In addition, the vendor specific constructors for AWS are inconsistent between using the V1 and V2 SDK.

Describe the solution you'd like

I propose migrating all modules to use the V2 SDK both for consistency when using the vendor specific constructors, but also to address future maintenance considerations as the V1 SDK continues to be deprecated and diverges from V2.

Describe alternatives you've considered

The V1 support could be retained for some time, as the V1 SDK is flagged as receiving maintenance for another year.
But this seems the kind of edit likely to accumulate in the amount of effort needed to make the migration over time.

Additional context

I've created a fork and will be investigating the necessary changes there. My intent is to try and keep any necessary changes as minimal as feasible, and created this issue for discussion of anything I find along the way needing input, and to provide advance warning for a future PR.
@Maldris
Copy link
Author

Maldris commented Aug 4, 2024

I realised in retrospect that in trying to set this up between calls I omitted some critical details.

My initial plan is to ensure a consistent V2 constructor for each package as seen in s3blob.
Then (once the above is demonstrable and testable) I'd consider inverting the "UseV2" behaviour to instead be "UseV1" so the new SDK is the default behaviour.
Then as V1 gets sunset it would be worth removing it's support entirely, simplifying the packages again.

Thoughts on this roadmap?

@vangent
Copy link
Contributor

vangent commented Aug 5, 2024

Doesn't this exist already? E.g., for s3blob, see https://pkg.go.dev/gocloud.dev/blob/s3blob#OpenBucketV2, pubsub https://pkg.go.dev/[email protected]/pubsub/awssnssqs#OpenSNSTopicV2, etc.

@Maldris
Copy link
Author

Maldris commented Aug 5, 2024

Sorry, I'm being far too reductive with a few things this morning, I'll blame it on a case of the Mondays sorry.

Most of the packages do, and some of the recent PRs have fixed issues my team flagged.

docstore is the main one without V2 support, which is my immediate focus (and going to be a non-trivial change to keep the "usev2" strategy looking at the package structure)

The secondary goal, which I completely failed to state explicitly because the docstore element was front of mind for an upcoming project was to discuss a strategy for what happens when V1 is completely deprecated and may need to be removed from the package.
This was mainly a consideration around the general attempt to keep Go packages as backwards compatible as possible, but persisting its support, particularly as the default behaviour could cause the package to cease working in some aspects over time.

In hindsight I should have split these into two issues, one discussing the docstore change and the other regarding the V1 sunset plan. Which I can do now if you'd prefer?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Maldris @vangent