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

Velero AWS plugin: S3 compatibility broken with Qumulo in recent versions #8312

Closed
Mise opened this issue Oct 16, 2024 · 13 comments
Closed

Velero AWS plugin: S3 compatibility broken with Qumulo in recent versions #8312

Mise opened this issue Oct 16, 2024 · 13 comments

Comments

@Mise
Copy link

Mise commented Oct 16, 2024

Hello,

We are attempting to integrate Velero and Velero plugin for AWS with Qumulo storage, which the vendor claims is fully compatible with AWS S3.

However, it seems that the requests made by the Velero AWS plugin to our storage include parameters that it does not recognize. For example, some requests fail due to the inclusion of the x-id parameter, for example:

GET https://storage.domain.tld:443/bucketname/backups/test-backup-qumulo/test-backup-qumulo-volumeinfo.json.gz?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=blablaaws4_request&X-Amz-Date=20241015T093024Z&X-Amz-Expires=600&X-Amz-SignedHeaders=host&x-id=GetObject&X-Amz-Signature=blabla"

Other requests, such as PutObject requests, fail similarly. The storage vendor asserts that x-id parameter is not part of the S3 specification, and I could not find any information about it in the S3 API reference.

We tried Velero versions 1.13.2 and 1.14.1 and AWS plugin versions 1.9.0 and 1.10, which exhibit the same behavior, and a combination of older Velero v1.12.4 with AWS plugin v1.8.2, which work correctly.

Could you please advise why newer Velero and plugin versions are including the x-id parameter in their S3 requests, and whether there is a way to configure Velero to omit this parameter when communicating with our S3 storage?

Thank you!

@kaovilai
Copy link
Member

dupe of #8265

@kaovilai
Copy link
Member

bump to aws-sdk-go-v2 forced addition of some headers and drop usage of older "legacy" (as aws determined) apis.

Everyone who claims S3 compatible are only via testing/replicating functionality, which can get out of date and eventually incompatible with what aws uses overtime.

@kaovilai
Copy link
Member

"x-id" is an expected part of requests made by aws-sdk-go-v2
https://github.com/aws/aws-sdk-go-v2/blob/04e7aca073a0a7ed479aa37cad88a1cf58a979a1/service/s3/internal/customizations/presign_test.go#L35-L41

@blackpiglet
Copy link
Contributor

/assign @kaovilai

@kzakhark
Copy link

"x-id" is an expected part of requests made by aws-sdk-go-v2 https://github.com/aws/aws-sdk-go-v2/blob/04e7aca073a0a7ed479aa37cad88a1cf58a979a1/service/s3/internal/customizations/presign_test.go#L35-L41

Is there any indication of why it is an expected part, as there's no mention of this parameter in the API reference?

@kaovilai
Copy link
Member

Ask aws sdk go v2 team. We don't know.

@kaovilai
Copy link
Member

kaovilai commented Oct 17, 2024

aws-sdk-go v1 is expected to go into unsupported state in mid 2025. You should ask Qumulo if they would eventually implement support for aws-sdk-go-v2 or they have an alternative SDK they prefer us to use.

@kaovilai
Copy link
Member

@blackpiglet this should be labeled Area/Storage/s3-compatible not aws :)

@kaovilai
Copy link
Member

I'm assuming it's for debugging with customers where aws only have to ask for request URL, and not method.

More people understand URL than HTTP request methods (PUT/GET)

@reasonerjt
Copy link
Contributor

reasonerjt commented Oct 21, 2024

@Mise

which the vendor claims is fully compatible with AWS S3.
So it seems it's not b/c the AWS SDK does not work with it.

Could you test using the velero with the v1.8.x version of velero-plugin-for-s3?

@Mise
Copy link
Author

Mise commented Oct 21, 2024

@reasonerjt Yes, we did test v1.12.4 with AWS plugin v1.8.2 which works correctly (per above).

Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. If a Velero team member has requested log or more information, please provide the output of the shared commands.

Copy link

github-actions bot commented Jan 5, 2025

This issue was closed because it has been stalled for 14 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants