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

Support dynamic backup location #341

Merged
merged 8 commits into from
Dec 10, 2024

Conversation

bevzzz
Copy link
Contributor

@bevzzz bevzzz commented Dec 7, 2024

This PR extends sync/async clients to accept bucket and path parameters in backup operations.

As query parameters: create status, restore status, cancel.
As request body parameters: create, restore.

How is this tested?

New tests case in BackupTestSuite. It's only limitation is that it doesn't verify that the bucket was set correctly, because bucket is irrelevant for "filesystem" backend, which we use in the tests.

We do pass this parameter in all requests.

Copy link

@orca-security-eu orca-security-eu bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Orca Security Scan Summary

Status Check Issues by priority
Passed Passed Infrastructure as Code high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Secrets high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Vulnerabilities high 0   medium 0   low 0   info 0 View in Orca

@bevzzz
Copy link
Contributor Author

bevzzz commented Dec 7, 2024

@antas-marcin atm I am using this pattern for adding query parameters to the request:

String path = String.format("/backups/%s/%s/restore", UrlEncoder.encodePathParam(backend), UrlEncoder.encodePathParam(backupId));
try {
  path = new URIBuilder(path)
    .addParameter("bucket", bucket)
    .addParameter("path", this.path)
    .toString();
} catch (URISyntaxException e) {
}
return sendRequest(path, ...)

Here, if adding these parameters fails we would send the request without them. "It should never happen in practice" is the underlying assumption here and it's true as long as the initial path is a valid URI. Which is an assumption that we make in other places as well.

Still, I think that maybe we should throw a RuntimeException in the catch-block here, so that the users are made aware that the request they wanted to send could not be sent. WDYT?


UPD: moved away from using URIBuilder, so this isn't an issue anymore.

@weaviate-git-bot
Copy link

Great to see you again! Thanks for the contribution.

beep boop - the Weaviate bot 👋🤖

PS:
Are you already a member of the Weaviate Slack channel?

Copy link

@orca-security-eu orca-security-eu bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Orca Security Scan Summary

Status Check Issues by priority
Passed Passed Infrastructure as Code high 0   medium 0   low 0   info 0 View in Orca
Passed Passed SAST high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Secrets high 0   medium 0   low 0   info 0 View in Orca
Passed Passed Vulnerabilities high 0   medium 0   low 0   info 0 View in Orca

@antas-marcin antas-marcin merged commit eca4583 into weaviate:main Dec 10, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants