Skip to content

[oss] Unify the OSS User-Agent format - #10306

Open
sundapeng wants to merge 1 commit into
apache:masterfrom
sundapeng:oss-user-agent
Open

sundapeng wants to merge 1 commit into
apache:masterfrom
sundapeng:oss-user-agent

Conversation

@sundapeng

@sundapeng sundapeng commented Sep 28, 2026 •

Copy link
Copy Markdown
Member

Purpose

OSS requests from paimon-oss carry only the SDK's default User-Agent, aliyun-sdk-java/3.17.4(Linux/...;<java>), Hadoop/3.3.4, so Paimon traffic can't be told apart from other SDK traffic in OSS access logs. The DLF access tracking info (dlf.access-tracking.extended-info) never reaches the User-Agent either.

This gives OSS requests Paimon's unified User-Agent format, <module>(<transport>[;<feature>...])[ <extended>], which the REST client and the Python and Rust clients adopt as well:

  • module Paimon/<version>, transport aliyun-sdk-java/<version>. Both versions are written in at build time by the templating-maven-plugin, so no class loader lookup is involved.
  • module, features and extended come from the catalog options user-agent.module, user-agent.features and user-agent.extended, which REST requests read too ([rest] Unify the REST User-Agent format #10308). fs.oss.user.agent.module/features/extended override the matching part for OSS only.
  • dlf.access-tracking.extended-info, which DLF sends with the data token, is appended after the extended part, so it never replaces a user-set value.
  • OSSFileIO passes the result to hadoop-aliyun as fs.oss.user.agent.prefix, and a user-set prefix still takes precedence.

Examples (hadoop-aliyun appends , Hadoop/<version>):

Options User-Agent
none Paimon/2.2-SNAPSHOT(aliyun-sdk-java/3.17.4), Hadoop/3.3.4
user-agent.features=Flink, user-agent.extended=vvr Paimon/2.2-SNAPSHOT(aliyun-sdk-java/3.17.4;Flink) vvr, Hadoop/3.3.4
the above, on a DLF catalog with access tracking enabled Paimon/2.2-SNAPSHOT(aliyun-sdk-java/3.17.4;Flink) vvr tenantId/<uid> principalType/<type> userName/<name>, Hadoop/3.3.4
the above plus fs.oss.user.agent.features=Spark Paimon/2.2-SNAPSHOT(aliyun-sdk-java/3.17.4;Spark) vvr tenantId/<uid> principalType/<type> userName/<name>, Hadoop/3.3.4
fs.oss.user.agent.prefix=custom custom, Hadoop/3.3.4

Related: #10308 (Java REST), #10321 (Jindo FileIO), #10307 (Python OSS), apache/paimon-rust#991 (Rust object storage).

Tests

OSSUserAgentTest: 8 new cases, 1 of them against a fake OSS endpoint; 32 tests in paimon-oss-impl passed. Also checked on a live DLF catalog with access tracking enabled: the OSS access log shows the tracking info after the configured extended part.

@sundapeng sundapeng changed the title [fs] Align OSS User-Agent with Jindo [fs] Unify the OSS User-Agent format Sep 28, 2026
@sundapeng sundapeng changed the title [fs] Unify the OSS User-Agent format [oss] Unify the OSS User-Agent format Sep 28, 2026
OSS requests from OSSFileIO only carried the SDK's default User-Agent.
They now carry Paimon's unified User-Agent format,
module(transport;features) extended, passed to hadoop-aliyun as
fs.oss.user.agent.prefix. The module defaults to Paimon/<version> and the
transport is aliyun-sdk-java/<version>.

Each part is read from fs.oss.user.agent.<part>, falling back to the
catalog-wide user-agent.<part> keys that REST requests also use, so one
setting covers both. dlf.access-tracking.extended-info is appended after
the extended value. A user-set fs.oss.user.agent.prefix still wins.

Both versions are written into OSSBuildVersions at build time by the
templating-maven-plugin, so reading them needs no class loader lookup.
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.

1 participant