yandrey321 opened a new pull request, #11477:
URL: https://github.com/apache/ozone/pull/11477
## What changes were proposed in this pull request?
`BasicRootedOzoneClientAdapterImpl.listStatus` calls `getBucket()` (an
`InfoBucket` RPC, plus `InfoVolume` +
`InfoBucket` for a link bucket) before every listing, so a client doing N
listings sends 2N OM requests. The fetch
does two jobs; this PR moves both off the success path, following HDDS-15925
(getFileStatus) and HDDS-15951
(getFileChecksum).
**Layout check, moved into OM behind an opt-in request field.** Unlike
`getFileStatus` and `lookupFile`, the list
status RPCs have object store callers: `OzoneBucket.listKeys(...,
shallow=true)` on an OBJECT_STORE or LEGACY bucket
uses `ListStatusLight`, and the S3 Gateway uses that shallow listing for
`ListObjects` with `delimiter=/`
(`ozone.s3g.list-keys.shallow.enabled` is true by default). OM's trash
handling also lists OBJECT_STORE buckets.
So OM cannot reject OBJECT_STORE for every caller. Instead:
- `ListStatusRequest`, shared by `ListStatus` and `ListStatusLight`, gets
`optional bool requireFileSystemLayout = 7`.
- When it is set, `OmMetadataReader.listStatus` and `listStatusLight` reject
an OBJECT_STORE bucket with
`NOT_SUPPORTED_OPERATION`, using the link-resolved layout already in
`ResolvedBucket`, before the ACL check. Callers
that do not set it (S3 Gateway, OM trash, other Java clients) are
unaffected.
- The field travels in `OmKeyArgs` (like `listPrefix`), so
`IOmMetadataReader` and snapshot reads need no signature
change.
- The layout check block that `getFileStatus` and `lookupFile` already had
is now one private helper,
`validateFileSystemLayout`, used by all four.
- Client side: `ListStatusLightOptions` gets `setRequireFileSystemLayout`,
and `ClientProtocol` gets a
`listStatus(ListStatusLightOptions)` overload, because the non-lite
variant only had positional overloads.
**Orphan link bucket check, moved to the error path.** `isSourcePathExist()`
makes `listStatus` return an empty list
for a link bucket whose source was deleted. OM already fails that listing
with `BUCKET_NOT_FOUND` /
`VOLUME_NOT_FOUND`, because `resolveBucketLink` does not allow dangling
buckets. The client now lists first, and only
on those two codes calls `getBucket()` to tell an orphan link (empty list,
same warning as before) from a missing
bucket (the exception from `getBucket()`, as before). `getBucket()` is
called unchanged, so an orphan link that is
itself OBJECT_STORE still fails client-side with `IllegalArgumentException`,
as before.
**Version gate.** The new path is used when the OM version is at least the
new
`OzoneManagerVersion.LIST_STATUS_REJECTS_OBS (16)`; an older OM ignores the
new field, so against it the client keeps
the current `getBucket()` path. `NOT_SUPPORTED_OPERATION` is mapped to
`IllegalArgumentException`, the exception type
the client-side check throws. `TestOMVersionManager` and
`TestOMUpgradeFinalization` pin the last pre-ZDU version and
are updated to the new constant.
Compatibility: one new optional proto field, no new result code, no new
configuration. Old clients never set the
field, so OM behaves as before for them.
Generated-by: Claude Code (claude-opus-5-5)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-16760
## How was this patch tested?
CI:
Unit and integration tests.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
