HDDS-15087. S3 Gateway and Local S3 UX - #10759
Open
henrybear327 wants to merge 2 commits into
Open
Conversation
henrybear327
marked this pull request as draft
July 14, 2026 11:07
henrybear327
force-pushed
the
HDDS-15087
branch
2 times, most recently
from
July 14, 2026 22:15
6df13aa to
d2a6ff8
Compare
henrybear327
force-pushed
the
HDDS-15087
branch
6 times, most recently
from
July 22, 2026 11:55
4314efb to
0a904d9
Compare
henrybear327
marked this pull request as ready for review
July 22, 2026 11:57
henrybear327
marked this pull request as draft
July 22, 2026 11:58
henrybear327
force-pushed
the
HDDS-15087
branch
4 times, most recently
from
August 5, 2026 07:51
ebcf543 to
dc433dc
Compare
henrybear327
marked this pull request as ready for review
August 5, 2026 07:52
Contributor
Author
|
@chungen0126 PTAL, thanks |
rich7420
reviewed
Aug 5, 2026
|
|
||
| conf.set(OZONE_S3G_HTTP_ADDRESS_KEY, | ||
| address(config.getHost(), s3gHttpPort)); | ||
| conf.set(OZONE_S3G_HTTP_BIND_HOST_KEY, config.getBindHost()); |
Contributor
There was a problem hiding this comment.
Binds to config.getBindHost(), 0.0.0.0 by default. With S3G on by default + the fixed admin/admin123, ozone local run ends up serving a writable S3 endpoint on all interfaces (checked locally: reachable from a non-loopback IP, createBucket works with the default creds, though the summary says 127.0.0.1). Default to loopback and make 0.0.0.0 opt-in via --bind-host?
Contributor
Author
There was a problem hiding this comment.
Attempted the implementation. Can you see if this is what you are expecting?
Thank you!
henrybear327
force-pushed
the
HDDS-15087
branch
from
August 5, 2026 18:53
dc433dc to
f9216c7
Compare
Contributor
Author
|
@peterxcli please also take a look, thank you! |
henrybear327
force-pushed
the
HDDS-15087
branch
from
August 5, 2026 19:00
f9216c7 to
2b2c78d
Compare
chungen0126
reviewed
Aug 6, 2026
chungen0126
left a comment
chungen0126
left a comment
Contributor
There was a problem hiding this comment.
Thanks @henrybear327 for working on this.
Comment on lines
+753
to
+763
| /** | ||
| * Stores the recommended local credentials in OM so S3 clients can sign requests without a | ||
| * separate {@code ozone s3 getsecret} bootstrap step. The write goes to the secret store | ||
| * directly rather than through the OM request pipeline: the local runtime is single-node and | ||
| * non-HA, the same fixed credentials are re-provisioned on every start, and a dev-only | ||
| * bootstrap credential needs neither Ratis replication nor an audit trail. | ||
| */ | ||
| private void provisionS3Credentials() throws IOException { | ||
| om.getS3SecretManager().storeSecret(config.getS3AccessKey(), | ||
| S3SecretValue.of(config.getS3AccessKey(), config.getS3SecretKey())); | ||
| } |
Contributor
There was a problem hiding this comment.
Currently, ozone local is not yet secure. At this stage, we should first design for the default Ozone scenario. In this non-secure mode, authentication is bypassed, meaning any access key and secret key combination will be accepted. Therefore, I don't think we need to explicitly specify the access/secret keys here.
Comment on lines
183
to
191
| @Option(names = "--s3-access-key", | ||
| defaultValue = DEFAULT_S3_ACCESS_KEY_VALUE, | ||
| description = "Suggested local AWS access key to print on startup") | ||
| private String s3AccessKey; | ||
|
|
||
| @Option(names = "--s3-secret-key", | ||
| defaultValue = DEFAULT_S3_SECRET_KEY_VALUE, | ||
| description = "Suggested local AWS secret key to print on startup") | ||
| private String s3SecretKey; |
Contributor
There was a problem hiding this comment.
For S3-related configurations, we should directly use the standard AWS environment variables, such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
`ozone local run` swallowed every failure it hit: shutdown and start() rollback errors went to IOUtils.closeQuietly with a null logger, the readiness wait collapsed its conditions into a single boolean, and the CLI converters rejected a value without naming it. The launcher sets OZONE_LOGLEVEL=OFF for ozone-tools, so logging on its own would stay invisible. A failed start now reports a message the user can act on, pointing at `ozone --loglevel INFO local run` for the service logs and --verbose for the stack trace. Local defaults that replace a user-configured value are now recorded and repeated on stderr by the CLI, so a discarded override stays visible even when it is the very setting the user is debugging. The datanode-count limit is checked before the format step so that format mode ALWAYS cannot delete the data dir for a run that can never start. Naming the unmet safe mode rules reads them as commons-lang3 Pair values, a use that leaves no import behind, so ozone-tools declares commons-lang3 for the dependency analyzer.
`ozone local run` starts an in-process S3 Gateway next to SCM, OM, and the datanodes, so S3 clients can target a local cluster without a separate gateway process or credential bootstrap. The runtime reserves and persists ports for the gateway's HTTP, HTTPS, and web-admin endpoints, provisions the fixed local credentials in OM (no `ozone s3 getsecret` step), and prints the endpoint plus the AWS settings a local client needs, including path-style addressing. --no-s3g turns the gateway off. Listeners bind loopback by default. The provisioned credentials are fixed and well known, so the previous wildcard default served a remotely writable S3 endpoint on every interface while the summary printed 127.0.0.1. --bind-host 0.0.0.0 is the opt-in for wider exposure. The gateway starts through call() rather than execute(): GenericCli's execution-exception handler reduces a startup failure to a bare exit code and can System.exit the JVM. call() returns only once Jetty serves requests, so no readiness poll follows; the call runs under the configured startup timeout so a hung startup rolls the cluster back instead of blocking forever. A timed-out attempt can ignore the interrupt and still finish late, so its cleanup is queued behind it on the startup thread as that attempt's only stopper.
henrybear327
force-pushed
the
HDDS-15087
branch
from
August 6, 2026 13:48
2b2c78d to
c463eac
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-15087
How was this patch tested?
https://github.com/apache/ozone/actions/runs/29327794616