add support for s3 compatible storages#792
Conversation
klaudworks
force-pushed
the
support-s3-compatible-storages
branch
3 times, most recently
from
6bab25e to
3d339b8
Compare
klaudworks
force-pushed
the
support-s3-compatible-storages
branch
from
3d339b8 to
ac22457
Compare
| - `--service.s3.bucket`: (Required) AWS S3 Bucket name. | ||
| - `--service.s3.region`: (Required) AWS S3 Region name. | ||
| - `--service.s3.endpoint`: (Optional) Custom S3 endpoint URL. | ||
| - `--service.s3.force-path-style`: (Optional, defaults to `false`) Enable path-style S3 URLs. |
There was a problem hiding this comment.
Would be nice to mention here what the default behaviour with false is. From reading this up, I guess it's hosted-style URLs?
There was a problem hiding this comment.
It's a setting that you only enable when you know what you are doing. The default, nowadays, is to have URLs as follows:
https://bucket-name.s3.region-code.amazonaws.com
However, there are still buckets on AWS and other providers that use the path style pattern:
https://s3.region-code.amazonaws.com/bucket-name/key-name
I.e. the the default is 'false' anyways. Previously it was just not explicit. Would you still like to add an explaination? If so, do you have a suggestion?
|
Thank you so much @2start ! 💙 |
|
Thanks for answering & merging this so promptly! 💙 |
3 participants
Hey! I recently stumbled over your operator. While it doesn't seem to be developed with other users in mind it would save us the headache of writing a lot of bash.
However, I have to upload the backups to on-prem s3 compatible storages. The changes required were quite minor. Would be cool if we could release them so we don't have to maintain a custom fork.