You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ozone.apache.org by Wei-Chiu Chuang <we...@apache.org> on 2026/05/28 21:03:21 UTC
[VOTE] Ozone 2.1.1 RC0
Hi community,
As promised, here's the 2.1.RC0 artifacts are ready; please try them,
review, and report any issues. Let's give it 7 days to vote on this release
candidate.
2.1.1 RC0 git tag:
https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC0
All jiras in the 2.1.1 since 2.1.0:
https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20and%20fixVersion%20%3D%20%222.1.1%22
Commit history:
https://github.com/apache/ozone/compare/ozone-2.1.0...ozone-2.1.1-RC0
Source and binary tarball:
https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
Maven artifacts:
https://repository.apache.org/content/repositories/orgapacheozone-1062/
My public key 3ED23305D7631918:
https://dist.apache.org/repos/dist/release/ozone/KEYS
Please follow the verification steps described in the download page to
verify the release artifacts: https://ozone.apache.org/download#verify
Please review the release notes below (prepared by Cursor)
Critical bug fixes (upgrade strongly recommended)HDDS-14858
<https://issues.apache.org/jira/browse/HDDS-14858> — OM requests fail on
JDK 11 with ClassNotFoundException: java.lang.constant.Constable
Impact: If you run Ozone 2.1.0 on JDK 11 or lower, OM operations such as ozone
sh key put can fail with:
RemoteException: java/lang/constant/Constable
Caused by: java.lang.ClassNotFoundException: java.lang.constant.Constable
Who is affected: Anyone on 2.1.0 + JDK ≤ 11. This is a regression from
AspectJ bytecode generation referencing JDK 12+ APIs.
Action: Upgrade to 2.1.1 if you cannot move to JDK 17+.
------------------------------
HDDS-14778 <https://issues.apache.org/jira/browse/HDDS-14778> —
ozone-filesystem-shaded protobuf corruption breaks ofs:// clients
Impact: With TRACE logging enabled, Ozone filesystem client operations via
ofs:// can fail at class load time:
ExceptionInInitializerError at OzoneManagerProtocolProtos.<clinit>
Caused by: InvalidProtocolBufferException: Protocol message tag had invalid
wire type
Root cause: Over-broad Maven shade relocation rules (io, kotlin, info,
etc.) corrupted protobuf descriptor bytes inside the shaded JAR. The bug is
latent and can reappear after proto changes.
Who is affected: Users of ozone-filesystem-shaded (Hadoop/OFS integration),
especially with debug/trace logging.
Action: Upgrade to 2.1.1 and rebuild/redeploy shaded client JARs.
------------------------------
Security / authorization behavior changesHDDS-14898
<https://issues.apache.org/jira/browse/HDDS-14898> & HDDS-14894
<https://issues.apache.org/jira/browse/HDDS-14894> — Missing ACL checks on
S3 multipart APIs
Impact: Behavior change (tightening). ListParts and
ListMultipartUploads previously
had no ACL checks. They now enforce authorization like other S3 APIs.
Who is affected:
- STS users with narrowly scoped tokens (e.g., PutObject-only) that
previously could call these APIs
- Any workflow that relied on implicit access via multipart upload
ownership
Action: After upgrade, verify multipart upload workflows and STS session
policies. Previously “working” calls may now return 403 Access Denied.
------------------------------
HDDS-15064 <https://issues.apache.org/jira/browse/HDDS-15064> — Ranger/STS
S3 action–aware authorization
Impact: API/authorization model change for STS + Apache Ranger integration.
- Adds s3Action to RequestContext so Ranger can restrict permissions by
specific S3 action (e.g., distinguish s3:PutObjectTagging from
s3:DeleteObjectTagging)
- OzoneGrant now carries a Set<String> of allowed S3 actions for inline
policies
Who is affected: Clusters using STS temporary credentials with Ranger.
Authorization becomes more granular; tokens may grant less access than
before when S3 actions are explicitly scoped.
Action: Coordinate with your Ranger/Ozone plugin team. This was backported
specifically so Ranger can consume it upstream in 2.1.1.
------------------------------
HDDS-14366 <https://issues.apache.org/jira/browse/HDDS-14366> — Log4j2 bump
to 2.25.3 (CVE-2025-68161)
Impact: Fixes TLS hostname verification bypass in Log4j2 Socket Appender (MITM
risk for remote log shipping).
Who is affected: Only if you use Log4j2 Socket Appender over TLS with
hostname verification enabled. Most clusters are unaffected unless they
ship logs this way.
------------------------------
Notable operational fixes (lower severity)HDDS-14368
<https://issues.apache.org/jira/browse/HDDS-14368> — Recon shows wrong
pipelines per container
Impact: Recon UI/API incorrectly showed all pipelines for every container
instead of the container’s actual WRITE pipeline.
Action: Upgrade if you rely on Recon for container/pipeline troubleshooting.
------------------------------
HDDS-13069 <https://issues.apache.org/jira/browse/HDDS-13069> — S3 Gateway
shutdown error
Impact: S3 Gateway logged an IllegalStateException from Weld/Jetty during
admin webserver shutdown. Shutdown could appear to fail even though the
process was stopping.
Action: Cosmetic/operational fix; shutdown now completes cleanly (error is
caught and logged).
Re: [VOTE] Ozone 2.1.1 RC0
Posted by Wei-Chiu Chuang <we...@apache.org>.
Thanks all. I'll push another RC today to resolve the minor issues reported
in this thread.
On Mon, Jun 8, 2026 at 5:26 AM Rich Huang <rc...@gmail.com> wrote:
> +1 (non-binding)
>
> Thanks Wei-Chiu for driving the release.
>
> Verified on macOS, JDK 21 (Temurin), Maven 3.9.9, Docker 28.5.2:
>
> * Verified GPG signature (key 3ED23305D7631918 matches KEYS) and
> SHA512/SHA256 checksums of the source tarball.
> * LICENSE.txt/NOTICE.txt present; version is 2.1.1.
> * Built from the source tarball (mvn clean install -DskipTests -Pdist).
> * Ran compose/ozone smoke tests from the built dist — core suites pass
> (key read/write, Recon API/UI/NSSummary, Freon, GDPR, tokens). Only
> failure was Recon-Taskstatus "Validate Sequence number is updated after
> sync" (1500 != 1522), which looks like a flaky timing assertion.
>
> Minor (already noted, non-blocking): 54 pom.xml.versionsBackup files in
> the
> source tarball, and NOTICE.txt still says "Copyright 2025".
>
> Thanks,
> Rich Huang (Kuan-Hao Huang)
>
> On Sun, Jun 7, 2026 at 1:40 PM Ayush Saxena <ay...@gmail.com> wrote:
>
> > +1 (Binding)
> >
> > * Built from source
> > * Verified Checksums
> > * Verified Signatures
> > * Verified the output of `ozone version`
> > * Ran some basic shell commands
> > * Deployed with Hive on Tez and ran some queries on Iceberg tables.
> > * No code diff b/w the scr tar and git tag [1]
> > * Verified the LICENSE & NOTICE files [2]
> > * Browsed through the UI, OM, SCM, DN, Recon [3]
> > * Skimmed over the contents of maven staging
> >
> > [1] I did notice the pom.xml.versionsBackup file in the src tar, which
> > isn't there in the git tag, Not an ideal thing but I don't think it is
> > a release blocker, I have run this over LEGAL long back when we had
> > kind of similar or little worse situation like this via
> > https://issues.apache.org/jira/browse/LEGAL-683 and it was confirmed
> > to be not a blocker or so.
> >
> > [2] Year is wrong, should have been 2026 here
> > (
> >
> https://github.com/apache/ozone/blob/612e2e150cead0024e2c8b05760a594b0291d405/NOTICE.txt#L2
> > )
> > Lets fix it in the upcoming releases.
> >
> > [3] I tried the Recon UI. Nothing serious, these issues are also
> > present on master.
> > 1. If you are on the Namespace Usage tab and click Old UI, it results
> > in a Not Found page.
> >
> > 2. I am not sure whether this is the intended behavior, but the Reload
> > button does not appear to update the displayed key count. If this is
> > expected, it leads to a poor user experience. My expectation was that
> > clicking Reload would either refresh the data immediately or indicate
> > that the refresh is still in progress. If the UI is displaying stale
> > or cached information, it should clearly show the timestamp of the
> > last refresh or some indication of data freshness.
> >
> > 3. I am also unclear about the purpose of the LIMIT button. When I
> > changed the limit from 10 to a higher value, I expected additional
> > entries to be displayed on the same page. However, I did not observe
> > any change. I did not investigate this further.
> > I created: https://issues.apache.org/jira/browse/HDDS-15495
> >
> >
> > Thanx Wei-Chiu for driving the release. Good Luck!!!
> >
> > -Ayush
> >
> > On Wed, 3 Jun 2026 at 05:15, saketa chalamchala
> > <sa...@gmail.com> wrote:
> > >
> > > Thanks for the RC Wei-Chiu.
> > >
> > > * Have the same observation as Attila when verifying source tarball
> > against
> > > ozone-2.1.1-RC0 tag. Found extra pom.xml.versionsBackup in hadoop-hdds
> > > modules.
> > >
> > > * Verified docs in binary tarball.
> > > * Verified signatures on release artifacts
> > > * Tested `ozone sh` and `ozone fs` commands on secure and unsecure
> docker
> > > compose clusters from binary tarball.
> > > * Verified Recon UI.
> > > * Verified `ozone version`
> > >
> > > Thanks,
> > > Saketa
> > >
> > > On Mon, Jun 1, 2026 at 8:09 AM Ramesh Mani <rm...@apache.org> wrote:
> > >
> > > > +1 for the Ozone 2.1.1 RC0
> > > >
> > > > Thanks
> > > > Ramesh
> > > >
> > > > On 2026/05/28 21:03:21 Wei-Chiu Chuang wrote:
> > > > > Hi community,
> > > > > As promised, here's the 2.1.RC0 artifacts are ready; please try
> them,
> > > > > review, and report any issues. Let's give it 7 days to vote on this
> > > > release
> > > > > candidate.
> > > > >
> > > > > 2.1.1 RC0 git tag:
> > > > > https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC0
> > > > > All jiras in the 2.1.1 since 2.1.0:
> > > > >
> > > >
> >
> https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20and%20fixVersion%20%3D%20%222.1.1%22
> > > > > Commit history:
> > > > >
> > https://github.com/apache/ozone/compare/ozone-2.1.0...ozone-2.1.1-RC0
> > > > > Source and binary tarball:
> > > > > https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
> > > > > Maven artifacts:
> > > > >
> > https://repository.apache.org/content/repositories/orgapacheozone-1062/
> > > > > My public key 3ED23305D7631918:
> > > > > https://dist.apache.org/repos/dist/release/ozone/KEYS
> > > > >
> > > > > Please follow the verification steps described in the download page
> > to
> > > > > verify the release artifacts:
> > https://ozone.apache.org/download#verify
> > > > >
> > > > > Please review the release notes below (prepared by Cursor)
> > > > >
> > > > > Critical bug fixes (upgrade strongly recommended)HDDS-14858
> > > > > <https://issues.apache.org/jira/browse/HDDS-14858> — OM requests
> > fail on
> > > > > JDK 11 with ClassNotFoundException: java.lang.constant.Constable
> > > > >
> > > > > Impact: If you run Ozone 2.1.0 on JDK 11 or lower, OM operations
> > such as
> > > > ozone
> > > > > sh key put can fail with:
> > > > > RemoteException: java/lang/constant/Constable
> > > > > Caused by: java.lang.ClassNotFoundException:
> > java.lang.constant.Constable
> > > > >
> > > > > Who is affected: Anyone on 2.1.0 + JDK ≤ 11. This is a regression
> > from
> > > > > AspectJ bytecode generation referencing JDK 12+ APIs.
> > > > >
> > > > > Action: Upgrade to 2.1.1 if you cannot move to JDK 17+.
> > > > > ------------------------------
> > > > > HDDS-14778 <https://issues.apache.org/jira/browse/HDDS-14778> —
> > > > > ozone-filesystem-shaded protobuf corruption breaks ofs:// clients
> > > > >
> > > > > Impact: With TRACE logging enabled, Ozone filesystem client
> > operations
> > > > via
> > > > > ofs:// can fail at class load time:
> > > > > ExceptionInInitializerError at OzoneManagerProtocolProtos.<clinit>
> > > > > Caused by: InvalidProtocolBufferException: Protocol message tag had
> > > > invalid
> > > > > wire type
> > > > >
> > > > > Root cause: Over-broad Maven shade relocation rules (io, kotlin,
> > info,
> > > > > etc.) corrupted protobuf descriptor bytes inside the shaded JAR.
> The
> > bug
> > > > is
> > > > > latent and can reappear after proto changes.
> > > > >
> > > > > Who is affected: Users of ozone-filesystem-shaded (Hadoop/OFS
> > > > integration),
> > > > > especially with debug/trace logging.
> > > > >
> > > > > Action: Upgrade to 2.1.1 and rebuild/redeploy shaded client JARs.
> > > > > ------------------------------
> > > > > Security / authorization behavior changesHDDS-14898
> > > > > <https://issues.apache.org/jira/browse/HDDS-14898> & HDDS-14894
> > > > > <https://issues.apache.org/jira/browse/HDDS-14894> — Missing ACL
> > checks
> > > > on
> > > > > S3 multipart APIs
> > > > >
> > > > > Impact: Behavior change (tightening). ListParts and
> > > > > ListMultipartUploads previously
> > > > > had no ACL checks. They now enforce authorization like other S3
> APIs.
> > > > >
> > > > > Who is affected:
> > > > >
> > > > > - STS users with narrowly scoped tokens (e.g., PutObject-only)
> > that
> > > > > previously could call these APIs
> > > > > - Any workflow that relied on implicit access via multipart
> upload
> > > > > ownership
> > > > >
> > > > > Action: After upgrade, verify multipart upload workflows and STS
> > session
> > > > > policies. Previously “working” calls may now return 403 Access
> > Denied.
> > > > > ------------------------------
> > > > > HDDS-15064 <https://issues.apache.org/jira/browse/HDDS-15064> —
> > > > Ranger/STS
> > > > > S3 action–aware authorization
> > > > >
> > > > > Impact: API/authorization model change for STS + Apache Ranger
> > > > integration.
> > > > >
> > > > > - Adds s3Action to RequestContext so Ranger can restrict
> > permissions
> > > > by
> > > > > specific S3 action (e.g., distinguish s3:PutObjectTagging from
> > > > > s3:DeleteObjectTagging)
> > > > > - OzoneGrant now carries a Set<String> of allowed S3 actions for
> > > > inline
> > > > > policies
> > > > >
> > > > > Who is affected: Clusters using STS temporary credentials with
> > Ranger.
> > > > > Authorization becomes more granular; tokens may grant less access
> > than
> > > > > before when S3 actions are explicitly scoped.
> > > > >
> > > > > Action: Coordinate with your Ranger/Ozone plugin team. This was
> > > > backported
> > > > > specifically so Ranger can consume it upstream in 2.1.1.
> > > > > ------------------------------
> > > > > HDDS-14366 <https://issues.apache.org/jira/browse/HDDS-14366> —
> > Log4j2
> > > > bump
> > > > > to 2.25.3 (CVE-2025-68161)
> > > > >
> > > > > Impact: Fixes TLS hostname verification bypass in Log4j2 Socket
> > Appender
> > > > (MITM
> > > > > risk for remote log shipping).
> > > > >
> > > > > Who is affected: Only if you use Log4j2 Socket Appender over TLS
> with
> > > > > hostname verification enabled. Most clusters are unaffected unless
> > they
> > > > > ship logs this way.
> > > > > ------------------------------
> > > > > Notable operational fixes (lower severity)HDDS-14368
> > > > > <https://issues.apache.org/jira/browse/HDDS-14368> — Recon shows
> > wrong
> > > > > pipelines per container
> > > > >
> > > > > Impact: Recon UI/API incorrectly showed all pipelines for every
> > container
> > > > > instead of the container’s actual WRITE pipeline.
> > > > >
> > > > > Action: Upgrade if you rely on Recon for container/pipeline
> > > > troubleshooting.
> > > > > ------------------------------
> > > > > HDDS-13069 <https://issues.apache.org/jira/browse/HDDS-13069> — S3
> > > > Gateway
> > > > > shutdown error
> > > > >
> > > > > Impact: S3 Gateway logged an IllegalStateException from Weld/Jetty
> > during
> > > > > admin webserver shutdown. Shutdown could appear to fail even though
> > the
> > > > > process was stopping.
> > > > >
> > > > > Action: Cosmetic/operational fix; shutdown now completes cleanly
> > (error
> > > > is
> > > > > caught and logged).
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > > > For additional commands, e-mail: dev-help@ozone.apache.org
> > > >
> > > >
> > >
> > > --
> > > Thanks,
> > > Saketa Chalamchala
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > For additional commands, e-mail: dev-help@ozone.apache.org
> >
> >
>
Re: [VOTE] Ozone 2.1.1 RC0
Posted by Rich Huang <rc...@gmail.com>.
+1 (non-binding)
Thanks Wei-Chiu for driving the release.
Verified on macOS, JDK 21 (Temurin), Maven 3.9.9, Docker 28.5.2:
* Verified GPG signature (key 3ED23305D7631918 matches KEYS) and
SHA512/SHA256 checksums of the source tarball.
* LICENSE.txt/NOTICE.txt present; version is 2.1.1.
* Built from the source tarball (mvn clean install -DskipTests -Pdist).
* Ran compose/ozone smoke tests from the built dist — core suites pass
(key read/write, Recon API/UI/NSSummary, Freon, GDPR, tokens). Only
failure was Recon-Taskstatus "Validate Sequence number is updated after
sync" (1500 != 1522), which looks like a flaky timing assertion.
Minor (already noted, non-blocking): 54 pom.xml.versionsBackup files in
the
source tarball, and NOTICE.txt still says "Copyright 2025".
Thanks,
Rich Huang (Kuan-Hao Huang)
On Sun, Jun 7, 2026 at 1:40 PM Ayush Saxena <ay...@gmail.com> wrote:
> +1 (Binding)
>
> * Built from source
> * Verified Checksums
> * Verified Signatures
> * Verified the output of `ozone version`
> * Ran some basic shell commands
> * Deployed with Hive on Tez and ran some queries on Iceberg tables.
> * No code diff b/w the scr tar and git tag [1]
> * Verified the LICENSE & NOTICE files [2]
> * Browsed through the UI, OM, SCM, DN, Recon [3]
> * Skimmed over the contents of maven staging
>
> [1] I did notice the pom.xml.versionsBackup file in the src tar, which
> isn't there in the git tag, Not an ideal thing but I don't think it is
> a release blocker, I have run this over LEGAL long back when we had
> kind of similar or little worse situation like this via
> https://issues.apache.org/jira/browse/LEGAL-683 and it was confirmed
> to be not a blocker or so.
>
> [2] Year is wrong, should have been 2026 here
> (
> https://github.com/apache/ozone/blob/612e2e150cead0024e2c8b05760a594b0291d405/NOTICE.txt#L2
> )
> Lets fix it in the upcoming releases.
>
> [3] I tried the Recon UI. Nothing serious, these issues are also
> present on master.
> 1. If you are on the Namespace Usage tab and click Old UI, it results
> in a Not Found page.
>
> 2. I am not sure whether this is the intended behavior, but the Reload
> button does not appear to update the displayed key count. If this is
> expected, it leads to a poor user experience. My expectation was that
> clicking Reload would either refresh the data immediately or indicate
> that the refresh is still in progress. If the UI is displaying stale
> or cached information, it should clearly show the timestamp of the
> last refresh or some indication of data freshness.
>
> 3. I am also unclear about the purpose of the LIMIT button. When I
> changed the limit from 10 to a higher value, I expected additional
> entries to be displayed on the same page. However, I did not observe
> any change. I did not investigate this further.
> I created: https://issues.apache.org/jira/browse/HDDS-15495
>
>
> Thanx Wei-Chiu for driving the release. Good Luck!!!
>
> -Ayush
>
> On Wed, 3 Jun 2026 at 05:15, saketa chalamchala
> <sa...@gmail.com> wrote:
> >
> > Thanks for the RC Wei-Chiu.
> >
> > * Have the same observation as Attila when verifying source tarball
> against
> > ozone-2.1.1-RC0 tag. Found extra pom.xml.versionsBackup in hadoop-hdds
> > modules.
> >
> > * Verified docs in binary tarball.
> > * Verified signatures on release artifacts
> > * Tested `ozone sh` and `ozone fs` commands on secure and unsecure docker
> > compose clusters from binary tarball.
> > * Verified Recon UI.
> > * Verified `ozone version`
> >
> > Thanks,
> > Saketa
> >
> > On Mon, Jun 1, 2026 at 8:09 AM Ramesh Mani <rm...@apache.org> wrote:
> >
> > > +1 for the Ozone 2.1.1 RC0
> > >
> > > Thanks
> > > Ramesh
> > >
> > > On 2026/05/28 21:03:21 Wei-Chiu Chuang wrote:
> > > > Hi community,
> > > > As promised, here's the 2.1.RC0 artifacts are ready; please try them,
> > > > review, and report any issues. Let's give it 7 days to vote on this
> > > release
> > > > candidate.
> > > >
> > > > 2.1.1 RC0 git tag:
> > > > https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC0
> > > > All jiras in the 2.1.1 since 2.1.0:
> > > >
> > >
> https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20and%20fixVersion%20%3D%20%222.1.1%22
> > > > Commit history:
> > > >
> https://github.com/apache/ozone/compare/ozone-2.1.0...ozone-2.1.1-RC0
> > > > Source and binary tarball:
> > > > https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
> > > > Maven artifacts:
> > > >
> https://repository.apache.org/content/repositories/orgapacheozone-1062/
> > > > My public key 3ED23305D7631918:
> > > > https://dist.apache.org/repos/dist/release/ozone/KEYS
> > > >
> > > > Please follow the verification steps described in the download page
> to
> > > > verify the release artifacts:
> https://ozone.apache.org/download#verify
> > > >
> > > > Please review the release notes below (prepared by Cursor)
> > > >
> > > > Critical bug fixes (upgrade strongly recommended)HDDS-14858
> > > > <https://issues.apache.org/jira/browse/HDDS-14858> — OM requests
> fail on
> > > > JDK 11 with ClassNotFoundException: java.lang.constant.Constable
> > > >
> > > > Impact: If you run Ozone 2.1.0 on JDK 11 or lower, OM operations
> such as
> > > ozone
> > > > sh key put can fail with:
> > > > RemoteException: java/lang/constant/Constable
> > > > Caused by: java.lang.ClassNotFoundException:
> java.lang.constant.Constable
> > > >
> > > > Who is affected: Anyone on 2.1.0 + JDK ≤ 11. This is a regression
> from
> > > > AspectJ bytecode generation referencing JDK 12+ APIs.
> > > >
> > > > Action: Upgrade to 2.1.1 if you cannot move to JDK 17+.
> > > > ------------------------------
> > > > HDDS-14778 <https://issues.apache.org/jira/browse/HDDS-14778> —
> > > > ozone-filesystem-shaded protobuf corruption breaks ofs:// clients
> > > >
> > > > Impact: With TRACE logging enabled, Ozone filesystem client
> operations
> > > via
> > > > ofs:// can fail at class load time:
> > > > ExceptionInInitializerError at OzoneManagerProtocolProtos.<clinit>
> > > > Caused by: InvalidProtocolBufferException: Protocol message tag had
> > > invalid
> > > > wire type
> > > >
> > > > Root cause: Over-broad Maven shade relocation rules (io, kotlin,
> info,
> > > > etc.) corrupted protobuf descriptor bytes inside the shaded JAR. The
> bug
> > > is
> > > > latent and can reappear after proto changes.
> > > >
> > > > Who is affected: Users of ozone-filesystem-shaded (Hadoop/OFS
> > > integration),
> > > > especially with debug/trace logging.
> > > >
> > > > Action: Upgrade to 2.1.1 and rebuild/redeploy shaded client JARs.
> > > > ------------------------------
> > > > Security / authorization behavior changesHDDS-14898
> > > > <https://issues.apache.org/jira/browse/HDDS-14898> & HDDS-14894
> > > > <https://issues.apache.org/jira/browse/HDDS-14894> — Missing ACL
> checks
> > > on
> > > > S3 multipart APIs
> > > >
> > > > Impact: Behavior change (tightening). ListParts and
> > > > ListMultipartUploads previously
> > > > had no ACL checks. They now enforce authorization like other S3 APIs.
> > > >
> > > > Who is affected:
> > > >
> > > > - STS users with narrowly scoped tokens (e.g., PutObject-only)
> that
> > > > previously could call these APIs
> > > > - Any workflow that relied on implicit access via multipart upload
> > > > ownership
> > > >
> > > > Action: After upgrade, verify multipart upload workflows and STS
> session
> > > > policies. Previously “working” calls may now return 403 Access
> Denied.
> > > > ------------------------------
> > > > HDDS-15064 <https://issues.apache.org/jira/browse/HDDS-15064> —
> > > Ranger/STS
> > > > S3 action–aware authorization
> > > >
> > > > Impact: API/authorization model change for STS + Apache Ranger
> > > integration.
> > > >
> > > > - Adds s3Action to RequestContext so Ranger can restrict
> permissions
> > > by
> > > > specific S3 action (e.g., distinguish s3:PutObjectTagging from
> > > > s3:DeleteObjectTagging)
> > > > - OzoneGrant now carries a Set<String> of allowed S3 actions for
> > > inline
> > > > policies
> > > >
> > > > Who is affected: Clusters using STS temporary credentials with
> Ranger.
> > > > Authorization becomes more granular; tokens may grant less access
> than
> > > > before when S3 actions are explicitly scoped.
> > > >
> > > > Action: Coordinate with your Ranger/Ozone plugin team. This was
> > > backported
> > > > specifically so Ranger can consume it upstream in 2.1.1.
> > > > ------------------------------
> > > > HDDS-14366 <https://issues.apache.org/jira/browse/HDDS-14366> —
> Log4j2
> > > bump
> > > > to 2.25.3 (CVE-2025-68161)
> > > >
> > > > Impact: Fixes TLS hostname verification bypass in Log4j2 Socket
> Appender
> > > (MITM
> > > > risk for remote log shipping).
> > > >
> > > > Who is affected: Only if you use Log4j2 Socket Appender over TLS with
> > > > hostname verification enabled. Most clusters are unaffected unless
> they
> > > > ship logs this way.
> > > > ------------------------------
> > > > Notable operational fixes (lower severity)HDDS-14368
> > > > <https://issues.apache.org/jira/browse/HDDS-14368> — Recon shows
> wrong
> > > > pipelines per container
> > > >
> > > > Impact: Recon UI/API incorrectly showed all pipelines for every
> container
> > > > instead of the container’s actual WRITE pipeline.
> > > >
> > > > Action: Upgrade if you rely on Recon for container/pipeline
> > > troubleshooting.
> > > > ------------------------------
> > > > HDDS-13069 <https://issues.apache.org/jira/browse/HDDS-13069> — S3
> > > Gateway
> > > > shutdown error
> > > >
> > > > Impact: S3 Gateway logged an IllegalStateException from Weld/Jetty
> during
> > > > admin webserver shutdown. Shutdown could appear to fail even though
> the
> > > > process was stopping.
> > > >
> > > > Action: Cosmetic/operational fix; shutdown now completes cleanly
> (error
> > > is
> > > > caught and logged).
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > > For additional commands, e-mail: dev-help@ozone.apache.org
> > >
> > >
> >
> > --
> > Thanks,
> > Saketa Chalamchala
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
Re: [VOTE] Ozone 2.1.1 RC0
Posted by Ayush Saxena <ay...@gmail.com>.
+1 (Binding)
* Built from source
* Verified Checksums
* Verified Signatures
* Verified the output of `ozone version`
* Ran some basic shell commands
* Deployed with Hive on Tez and ran some queries on Iceberg tables.
* No code diff b/w the scr tar and git tag [1]
* Verified the LICENSE & NOTICE files [2]
* Browsed through the UI, OM, SCM, DN, Recon [3]
* Skimmed over the contents of maven staging
[1] I did notice the pom.xml.versionsBackup file in the src tar, which
isn't there in the git tag, Not an ideal thing but I don't think it is
a release blocker, I have run this over LEGAL long back when we had
kind of similar or little worse situation like this via
https://issues.apache.org/jira/browse/LEGAL-683 and it was confirmed
to be not a blocker or so.
[2] Year is wrong, should have been 2026 here
(https://github.com/apache/ozone/blob/612e2e150cead0024e2c8b05760a594b0291d405/NOTICE.txt#L2)
Lets fix it in the upcoming releases.
[3] I tried the Recon UI. Nothing serious, these issues are also
present on master.
1. If you are on the Namespace Usage tab and click Old UI, it results
in a Not Found page.
2. I am not sure whether this is the intended behavior, but the Reload
button does not appear to update the displayed key count. If this is
expected, it leads to a poor user experience. My expectation was that
clicking Reload would either refresh the data immediately or indicate
that the refresh is still in progress. If the UI is displaying stale
or cached information, it should clearly show the timestamp of the
last refresh or some indication of data freshness.
3. I am also unclear about the purpose of the LIMIT button. When I
changed the limit from 10 to a higher value, I expected additional
entries to be displayed on the same page. However, I did not observe
any change. I did not investigate this further.
I created: https://issues.apache.org/jira/browse/HDDS-15495
Thanx Wei-Chiu for driving the release. Good Luck!!!
-Ayush
On Wed, 3 Jun 2026 at 05:15, saketa chalamchala
<sa...@gmail.com> wrote:
>
> Thanks for the RC Wei-Chiu.
>
> * Have the same observation as Attila when verifying source tarball against
> ozone-2.1.1-RC0 tag. Found extra pom.xml.versionsBackup in hadoop-hdds
> modules.
>
> * Verified docs in binary tarball.
> * Verified signatures on release artifacts
> * Tested `ozone sh` and `ozone fs` commands on secure and unsecure docker
> compose clusters from binary tarball.
> * Verified Recon UI.
> * Verified `ozone version`
>
> Thanks,
> Saketa
>
> On Mon, Jun 1, 2026 at 8:09 AM Ramesh Mani <rm...@apache.org> wrote:
>
> > +1 for the Ozone 2.1.1 RC0
> >
> > Thanks
> > Ramesh
> >
> > On 2026/05/28 21:03:21 Wei-Chiu Chuang wrote:
> > > Hi community,
> > > As promised, here's the 2.1.RC0 artifacts are ready; please try them,
> > > review, and report any issues. Let's give it 7 days to vote on this
> > release
> > > candidate.
> > >
> > > 2.1.1 RC0 git tag:
> > > https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC0
> > > All jiras in the 2.1.1 since 2.1.0:
> > >
> > https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20and%20fixVersion%20%3D%20%222.1.1%22
> > > Commit history:
> > > https://github.com/apache/ozone/compare/ozone-2.1.0...ozone-2.1.1-RC0
> > > Source and binary tarball:
> > > https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
> > > Maven artifacts:
> > > https://repository.apache.org/content/repositories/orgapacheozone-1062/
> > > My public key 3ED23305D7631918:
> > > https://dist.apache.org/repos/dist/release/ozone/KEYS
> > >
> > > Please follow the verification steps described in the download page to
> > > verify the release artifacts: https://ozone.apache.org/download#verify
> > >
> > > Please review the release notes below (prepared by Cursor)
> > >
> > > Critical bug fixes (upgrade strongly recommended)HDDS-14858
> > > <https://issues.apache.org/jira/browse/HDDS-14858> — OM requests fail on
> > > JDK 11 with ClassNotFoundException: java.lang.constant.Constable
> > >
> > > Impact: If you run Ozone 2.1.0 on JDK 11 or lower, OM operations such as
> > ozone
> > > sh key put can fail with:
> > > RemoteException: java/lang/constant/Constable
> > > Caused by: java.lang.ClassNotFoundException: java.lang.constant.Constable
> > >
> > > Who is affected: Anyone on 2.1.0 + JDK ≤ 11. This is a regression from
> > > AspectJ bytecode generation referencing JDK 12+ APIs.
> > >
> > > Action: Upgrade to 2.1.1 if you cannot move to JDK 17+.
> > > ------------------------------
> > > HDDS-14778 <https://issues.apache.org/jira/browse/HDDS-14778> —
> > > ozone-filesystem-shaded protobuf corruption breaks ofs:// clients
> > >
> > > Impact: With TRACE logging enabled, Ozone filesystem client operations
> > via
> > > ofs:// can fail at class load time:
> > > ExceptionInInitializerError at OzoneManagerProtocolProtos.<clinit>
> > > Caused by: InvalidProtocolBufferException: Protocol message tag had
> > invalid
> > > wire type
> > >
> > > Root cause: Over-broad Maven shade relocation rules (io, kotlin, info,
> > > etc.) corrupted protobuf descriptor bytes inside the shaded JAR. The bug
> > is
> > > latent and can reappear after proto changes.
> > >
> > > Who is affected: Users of ozone-filesystem-shaded (Hadoop/OFS
> > integration),
> > > especially with debug/trace logging.
> > >
> > > Action: Upgrade to 2.1.1 and rebuild/redeploy shaded client JARs.
> > > ------------------------------
> > > Security / authorization behavior changesHDDS-14898
> > > <https://issues.apache.org/jira/browse/HDDS-14898> & HDDS-14894
> > > <https://issues.apache.org/jira/browse/HDDS-14894> — Missing ACL checks
> > on
> > > S3 multipart APIs
> > >
> > > Impact: Behavior change (tightening). ListParts and
> > > ListMultipartUploads previously
> > > had no ACL checks. They now enforce authorization like other S3 APIs.
> > >
> > > Who is affected:
> > >
> > > - STS users with narrowly scoped tokens (e.g., PutObject-only) that
> > > previously could call these APIs
> > > - Any workflow that relied on implicit access via multipart upload
> > > ownership
> > >
> > > Action: After upgrade, verify multipart upload workflows and STS session
> > > policies. Previously “working” calls may now return 403 Access Denied.
> > > ------------------------------
> > > HDDS-15064 <https://issues.apache.org/jira/browse/HDDS-15064> —
> > Ranger/STS
> > > S3 action–aware authorization
> > >
> > > Impact: API/authorization model change for STS + Apache Ranger
> > integration.
> > >
> > > - Adds s3Action to RequestContext so Ranger can restrict permissions
> > by
> > > specific S3 action (e.g., distinguish s3:PutObjectTagging from
> > > s3:DeleteObjectTagging)
> > > - OzoneGrant now carries a Set<String> of allowed S3 actions for
> > inline
> > > policies
> > >
> > > Who is affected: Clusters using STS temporary credentials with Ranger.
> > > Authorization becomes more granular; tokens may grant less access than
> > > before when S3 actions are explicitly scoped.
> > >
> > > Action: Coordinate with your Ranger/Ozone plugin team. This was
> > backported
> > > specifically so Ranger can consume it upstream in 2.1.1.
> > > ------------------------------
> > > HDDS-14366 <https://issues.apache.org/jira/browse/HDDS-14366> — Log4j2
> > bump
> > > to 2.25.3 (CVE-2025-68161)
> > >
> > > Impact: Fixes TLS hostname verification bypass in Log4j2 Socket Appender
> > (MITM
> > > risk for remote log shipping).
> > >
> > > Who is affected: Only if you use Log4j2 Socket Appender over TLS with
> > > hostname verification enabled. Most clusters are unaffected unless they
> > > ship logs this way.
> > > ------------------------------
> > > Notable operational fixes (lower severity)HDDS-14368
> > > <https://issues.apache.org/jira/browse/HDDS-14368> — Recon shows wrong
> > > pipelines per container
> > >
> > > Impact: Recon UI/API incorrectly showed all pipelines for every container
> > > instead of the container’s actual WRITE pipeline.
> > >
> > > Action: Upgrade if you rely on Recon for container/pipeline
> > troubleshooting.
> > > ------------------------------
> > > HDDS-13069 <https://issues.apache.org/jira/browse/HDDS-13069> — S3
> > Gateway
> > > shutdown error
> > >
> > > Impact: S3 Gateway logged an IllegalStateException from Weld/Jetty during
> > > admin webserver shutdown. Shutdown could appear to fail even though the
> > > process was stopping.
> > >
> > > Action: Cosmetic/operational fix; shutdown now completes cleanly (error
> > is
> > > caught and logged).
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > For additional commands, e-mail: dev-help@ozone.apache.org
> >
> >
>
> --
> Thanks,
> Saketa Chalamchala
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [VOTE] Ozone 2.1.1 RC0
Posted by saketa chalamchala <sa...@gmail.com>.
Thanks for the RC Wei-Chiu.
* Have the same observation as Attila when verifying source tarball against
ozone-2.1.1-RC0 tag. Found extra pom.xml.versionsBackup in hadoop-hdds
modules.
* Verified docs in binary tarball.
* Verified signatures on release artifacts
* Tested `ozone sh` and `ozone fs` commands on secure and unsecure docker
compose clusters from binary tarball.
* Verified Recon UI.
* Verified `ozone version`
Thanks,
Saketa
On Mon, Jun 1, 2026 at 8:09 AM Ramesh Mani <rm...@apache.org> wrote:
> +1 for the Ozone 2.1.1 RC0
>
> Thanks
> Ramesh
>
> On 2026/05/28 21:03:21 Wei-Chiu Chuang wrote:
> > Hi community,
> > As promised, here's the 2.1.RC0 artifacts are ready; please try them,
> > review, and report any issues. Let's give it 7 days to vote on this
> release
> > candidate.
> >
> > 2.1.1 RC0 git tag:
> > https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC0
> > All jiras in the 2.1.1 since 2.1.0:
> >
> https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20and%20fixVersion%20%3D%20%222.1.1%22
> > Commit history:
> > https://github.com/apache/ozone/compare/ozone-2.1.0...ozone-2.1.1-RC0
> > Source and binary tarball:
> > https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
> > Maven artifacts:
> > https://repository.apache.org/content/repositories/orgapacheozone-1062/
> > My public key 3ED23305D7631918:
> > https://dist.apache.org/repos/dist/release/ozone/KEYS
> >
> > Please follow the verification steps described in the download page to
> > verify the release artifacts: https://ozone.apache.org/download#verify
> >
> > Please review the release notes below (prepared by Cursor)
> >
> > Critical bug fixes (upgrade strongly recommended)HDDS-14858
> > <https://issues.apache.org/jira/browse/HDDS-14858> — OM requests fail on
> > JDK 11 with ClassNotFoundException: java.lang.constant.Constable
> >
> > Impact: If you run Ozone 2.1.0 on JDK 11 or lower, OM operations such as
> ozone
> > sh key put can fail with:
> > RemoteException: java/lang/constant/Constable
> > Caused by: java.lang.ClassNotFoundException: java.lang.constant.Constable
> >
> > Who is affected: Anyone on 2.1.0 + JDK ≤ 11. This is a regression from
> > AspectJ bytecode generation referencing JDK 12+ APIs.
> >
> > Action: Upgrade to 2.1.1 if you cannot move to JDK 17+.
> > ------------------------------
> > HDDS-14778 <https://issues.apache.org/jira/browse/HDDS-14778> —
> > ozone-filesystem-shaded protobuf corruption breaks ofs:// clients
> >
> > Impact: With TRACE logging enabled, Ozone filesystem client operations
> via
> > ofs:// can fail at class load time:
> > ExceptionInInitializerError at OzoneManagerProtocolProtos.<clinit>
> > Caused by: InvalidProtocolBufferException: Protocol message tag had
> invalid
> > wire type
> >
> > Root cause: Over-broad Maven shade relocation rules (io, kotlin, info,
> > etc.) corrupted protobuf descriptor bytes inside the shaded JAR. The bug
> is
> > latent and can reappear after proto changes.
> >
> > Who is affected: Users of ozone-filesystem-shaded (Hadoop/OFS
> integration),
> > especially with debug/trace logging.
> >
> > Action: Upgrade to 2.1.1 and rebuild/redeploy shaded client JARs.
> > ------------------------------
> > Security / authorization behavior changesHDDS-14898
> > <https://issues.apache.org/jira/browse/HDDS-14898> & HDDS-14894
> > <https://issues.apache.org/jira/browse/HDDS-14894> — Missing ACL checks
> on
> > S3 multipart APIs
> >
> > Impact: Behavior change (tightening). ListParts and
> > ListMultipartUploads previously
> > had no ACL checks. They now enforce authorization like other S3 APIs.
> >
> > Who is affected:
> >
> > - STS users with narrowly scoped tokens (e.g., PutObject-only) that
> > previously could call these APIs
> > - Any workflow that relied on implicit access via multipart upload
> > ownership
> >
> > Action: After upgrade, verify multipart upload workflows and STS session
> > policies. Previously “working” calls may now return 403 Access Denied.
> > ------------------------------
> > HDDS-15064 <https://issues.apache.org/jira/browse/HDDS-15064> —
> Ranger/STS
> > S3 action–aware authorization
> >
> > Impact: API/authorization model change for STS + Apache Ranger
> integration.
> >
> > - Adds s3Action to RequestContext so Ranger can restrict permissions
> by
> > specific S3 action (e.g., distinguish s3:PutObjectTagging from
> > s3:DeleteObjectTagging)
> > - OzoneGrant now carries a Set<String> of allowed S3 actions for
> inline
> > policies
> >
> > Who is affected: Clusters using STS temporary credentials with Ranger.
> > Authorization becomes more granular; tokens may grant less access than
> > before when S3 actions are explicitly scoped.
> >
> > Action: Coordinate with your Ranger/Ozone plugin team. This was
> backported
> > specifically so Ranger can consume it upstream in 2.1.1.
> > ------------------------------
> > HDDS-14366 <https://issues.apache.org/jira/browse/HDDS-14366> — Log4j2
> bump
> > to 2.25.3 (CVE-2025-68161)
> >
> > Impact: Fixes TLS hostname verification bypass in Log4j2 Socket Appender
> (MITM
> > risk for remote log shipping).
> >
> > Who is affected: Only if you use Log4j2 Socket Appender over TLS with
> > hostname verification enabled. Most clusters are unaffected unless they
> > ship logs this way.
> > ------------------------------
> > Notable operational fixes (lower severity)HDDS-14368
> > <https://issues.apache.org/jira/browse/HDDS-14368> — Recon shows wrong
> > pipelines per container
> >
> > Impact: Recon UI/API incorrectly showed all pipelines for every container
> > instead of the container’s actual WRITE pipeline.
> >
> > Action: Upgrade if you rely on Recon for container/pipeline
> troubleshooting.
> > ------------------------------
> > HDDS-13069 <https://issues.apache.org/jira/browse/HDDS-13069> — S3
> Gateway
> > shutdown error
> >
> > Impact: S3 Gateway logged an IllegalStateException from Weld/Jetty during
> > admin webserver shutdown. Shutdown could appear to fail even though the
> > process was stopping.
> >
> > Action: Cosmetic/operational fix; shutdown now completes cleanly (error
> is
> > caught and logged).
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
--
Thanks,
Saketa Chalamchala
Re: [VOTE] Ozone 2.1.1 RC0
Posted by Ramesh Mani <rm...@apache.org>.
+1 for the Ozone 2.1.1 RC0
Thanks
Ramesh
On 2026/05/28 21:03:21 Wei-Chiu Chuang wrote:
> Hi community,
> As promised, here's the 2.1.RC0 artifacts are ready; please try them,
> review, and report any issues. Let's give it 7 days to vote on this release
> candidate.
>
> 2.1.1 RC0 git tag:
> https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC0
> All jiras in the 2.1.1 since 2.1.0:
> https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20and%20fixVersion%20%3D%20%222.1.1%22
> Commit history:
> https://github.com/apache/ozone/compare/ozone-2.1.0...ozone-2.1.1-RC0
> Source and binary tarball:
> https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapacheozone-1062/
> My public key 3ED23305D7631918:
> https://dist.apache.org/repos/dist/release/ozone/KEYS
>
> Please follow the verification steps described in the download page to
> verify the release artifacts: https://ozone.apache.org/download#verify
>
> Please review the release notes below (prepared by Cursor)
>
> Critical bug fixes (upgrade strongly recommended)HDDS-14858
> <https://issues.apache.org/jira/browse/HDDS-14858> — OM requests fail on
> JDK 11 with ClassNotFoundException: java.lang.constant.Constable
>
> Impact: If you run Ozone 2.1.0 on JDK 11 or lower, OM operations such as ozone
> sh key put can fail with:
> RemoteException: java/lang/constant/Constable
> Caused by: java.lang.ClassNotFoundException: java.lang.constant.Constable
>
> Who is affected: Anyone on 2.1.0 + JDK ≤ 11. This is a regression from
> AspectJ bytecode generation referencing JDK 12+ APIs.
>
> Action: Upgrade to 2.1.1 if you cannot move to JDK 17+.
> ------------------------------
> HDDS-14778 <https://issues.apache.org/jira/browse/HDDS-14778> —
> ozone-filesystem-shaded protobuf corruption breaks ofs:// clients
>
> Impact: With TRACE logging enabled, Ozone filesystem client operations via
> ofs:// can fail at class load time:
> ExceptionInInitializerError at OzoneManagerProtocolProtos.<clinit>
> Caused by: InvalidProtocolBufferException: Protocol message tag had invalid
> wire type
>
> Root cause: Over-broad Maven shade relocation rules (io, kotlin, info,
> etc.) corrupted protobuf descriptor bytes inside the shaded JAR. The bug is
> latent and can reappear after proto changes.
>
> Who is affected: Users of ozone-filesystem-shaded (Hadoop/OFS integration),
> especially with debug/trace logging.
>
> Action: Upgrade to 2.1.1 and rebuild/redeploy shaded client JARs.
> ------------------------------
> Security / authorization behavior changesHDDS-14898
> <https://issues.apache.org/jira/browse/HDDS-14898> & HDDS-14894
> <https://issues.apache.org/jira/browse/HDDS-14894> — Missing ACL checks on
> S3 multipart APIs
>
> Impact: Behavior change (tightening). ListParts and
> ListMultipartUploads previously
> had no ACL checks. They now enforce authorization like other S3 APIs.
>
> Who is affected:
>
> - STS users with narrowly scoped tokens (e.g., PutObject-only) that
> previously could call these APIs
> - Any workflow that relied on implicit access via multipart upload
> ownership
>
> Action: After upgrade, verify multipart upload workflows and STS session
> policies. Previously “working” calls may now return 403 Access Denied.
> ------------------------------
> HDDS-15064 <https://issues.apache.org/jira/browse/HDDS-15064> — Ranger/STS
> S3 action–aware authorization
>
> Impact: API/authorization model change for STS + Apache Ranger integration.
>
> - Adds s3Action to RequestContext so Ranger can restrict permissions by
> specific S3 action (e.g., distinguish s3:PutObjectTagging from
> s3:DeleteObjectTagging)
> - OzoneGrant now carries a Set<String> of allowed S3 actions for inline
> policies
>
> Who is affected: Clusters using STS temporary credentials with Ranger.
> Authorization becomes more granular; tokens may grant less access than
> before when S3 actions are explicitly scoped.
>
> Action: Coordinate with your Ranger/Ozone plugin team. This was backported
> specifically so Ranger can consume it upstream in 2.1.1.
> ------------------------------
> HDDS-14366 <https://issues.apache.org/jira/browse/HDDS-14366> — Log4j2 bump
> to 2.25.3 (CVE-2025-68161)
>
> Impact: Fixes TLS hostname verification bypass in Log4j2 Socket Appender (MITM
> risk for remote log shipping).
>
> Who is affected: Only if you use Log4j2 Socket Appender over TLS with
> hostname verification enabled. Most clusters are unaffected unless they
> ship logs this way.
> ------------------------------
> Notable operational fixes (lower severity)HDDS-14368
> <https://issues.apache.org/jira/browse/HDDS-14368> — Recon shows wrong
> pipelines per container
>
> Impact: Recon UI/API incorrectly showed all pipelines for every container
> instead of the container’s actual WRITE pipeline.
>
> Action: Upgrade if you rely on Recon for container/pipeline troubleshooting.
> ------------------------------
> HDDS-13069 <https://issues.apache.org/jira/browse/HDDS-13069> — S3 Gateway
> shutdown error
>
> Impact: S3 Gateway logged an IllegalStateException from Weld/Jetty during
> admin webserver shutdown. Shutdown could appear to fail even though the
> process was stopping.
>
> Action: Cosmetic/operational fix; shutdown now completes cleanly (error is
> caught and logged).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [VOTE] Ozone 2.1.1 RC0
Posted by Siyao Meng <si...@apache.org>.
+1 (binding)
Thanks Wei-Chiu for cutting the 2.1.1 RC0.
* Verified signatures and SHA512 checksums for source and binary
tarballs (signed with Wei-Chiu's key 3ED23305D7631918)
* Verified source tarball matches ozone-2.1.1-RC0 tag
* Verified LICENSE.txt and NOTICE.txt in both tarballs
* Built from the source tarball with `mvn clean install -DskipTests` on JDK
8
* Verified `ozone version` reports 2.1.1 on JDK 8 and JDK 11
* Verified docs present in binary tarball
* Started docker-compose cluster from the binary tarball. Ran basic `ozone
sh` volume/bucket/key operations. Browsed the OM, SCM, and Recon UIs
* Skimmed Maven staging repo for 2.1.1 artifacts. jars, poms, and .asc
signatures present
-Siyao
On Thu, May 28, 2026 at 2:03 PM Wei-Chiu Chuang <we...@apache.org> wrote:
> Hi community,
> As promised, here's the 2.1.RC0 artifacts are ready; please try them,
> review, and report any issues. Let's give it 7 days to vote on this release
> candidate.
>
> 2.1.1 RC0 git tag:
> https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC0
> All jiras in the 2.1.1 since 2.1.0:
>
> https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20and%20fixVersion%20%3D%20%222.1.1%22
> Commit history:
> https://github.com/apache/ozone/compare/ozone-2.1.0...ozone-2.1.1-RC0
> Source and binary tarball:
> https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapacheozone-1062/
> My public key 3ED23305D7631918:
> https://dist.apache.org/repos/dist/release/ozone/KEYS
>
> Please follow the verification steps described in the download page to
> verify the release artifacts: https://ozone.apache.org/download#verify
>
> Please review the release notes below (prepared by Cursor)
>
> Critical bug fixes (upgrade strongly recommended)HDDS-14858
> <https://issues.apache.org/jira/browse/HDDS-14858> — OM requests fail on
> JDK 11 with ClassNotFoundException: java.lang.constant.Constable
>
> Impact: If you run Ozone 2.1.0 on JDK 11 or lower, OM operations such as
> ozone
> sh key put can fail with:
> RemoteException: java/lang/constant/Constable
> Caused by: java.lang.ClassNotFoundException: java.lang.constant.Constable
>
> Who is affected: Anyone on 2.1.0 + JDK ≤ 11. This is a regression from
> AspectJ bytecode generation referencing JDK 12+ APIs.
>
> Action: Upgrade to 2.1.1 if you cannot move to JDK 17+.
> ------------------------------
> HDDS-14778 <https://issues.apache.org/jira/browse/HDDS-14778> —
> ozone-filesystem-shaded protobuf corruption breaks ofs:// clients
>
> Impact: With TRACE logging enabled, Ozone filesystem client operations via
> ofs:// can fail at class load time:
> ExceptionInInitializerError at OzoneManagerProtocolProtos.<clinit>
> Caused by: InvalidProtocolBufferException: Protocol message tag had invalid
> wire type
>
> Root cause: Over-broad Maven shade relocation rules (io, kotlin, info,
> etc.) corrupted protobuf descriptor bytes inside the shaded JAR. The bug is
> latent and can reappear after proto changes.
>
> Who is affected: Users of ozone-filesystem-shaded (Hadoop/OFS integration),
> especially with debug/trace logging.
>
> Action: Upgrade to 2.1.1 and rebuild/redeploy shaded client JARs.
> ------------------------------
> Security / authorization behavior changesHDDS-14898
> <https://issues.apache.org/jira/browse/HDDS-14898> & HDDS-14894
> <https://issues.apache.org/jira/browse/HDDS-14894> — Missing ACL checks on
> S3 multipart APIs
>
> Impact: Behavior change (tightening). ListParts and
> ListMultipartUploads previously
> had no ACL checks. They now enforce authorization like other S3 APIs.
>
> Who is affected:
>
> - STS users with narrowly scoped tokens (e.g., PutObject-only) that
> previously could call these APIs
> - Any workflow that relied on implicit access via multipart upload
> ownership
>
> Action: After upgrade, verify multipart upload workflows and STS session
> policies. Previously “working” calls may now return 403 Access Denied.
> ------------------------------
> HDDS-15064 <https://issues.apache.org/jira/browse/HDDS-15064> — Ranger/STS
> S3 action–aware authorization
>
> Impact: API/authorization model change for STS + Apache Ranger integration.
>
> - Adds s3Action to RequestContext so Ranger can restrict permissions by
> specific S3 action (e.g., distinguish s3:PutObjectTagging from
> s3:DeleteObjectTagging)
> - OzoneGrant now carries a Set<String> of allowed S3 actions for inline
> policies
>
> Who is affected: Clusters using STS temporary credentials with Ranger.
> Authorization becomes more granular; tokens may grant less access than
> before when S3 actions are explicitly scoped.
>
> Action: Coordinate with your Ranger/Ozone plugin team. This was backported
> specifically so Ranger can consume it upstream in 2.1.1.
> ------------------------------
> HDDS-14366 <https://issues.apache.org/jira/browse/HDDS-14366> — Log4j2
> bump
> to 2.25.3 (CVE-2025-68161)
>
> Impact: Fixes TLS hostname verification bypass in Log4j2 Socket Appender
> (MITM
> risk for remote log shipping).
>
> Who is affected: Only if you use Log4j2 Socket Appender over TLS with
> hostname verification enabled. Most clusters are unaffected unless they
> ship logs this way.
> ------------------------------
> Notable operational fixes (lower severity)HDDS-14368
> <https://issues.apache.org/jira/browse/HDDS-14368> — Recon shows wrong
> pipelines per container
>
> Impact: Recon UI/API incorrectly showed all pipelines for every container
> instead of the container’s actual WRITE pipeline.
>
> Action: Upgrade if you rely on Recon for container/pipeline
> troubleshooting.
> ------------------------------
> HDDS-13069 <https://issues.apache.org/jira/browse/HDDS-13069> — S3 Gateway
> shutdown error
>
> Impact: S3 Gateway logged an IllegalStateException from Weld/Jetty during
> admin webserver shutdown. Shutdown could appear to fail even though the
> process was stopping.
>
> Action: Cosmetic/operational fix; shutdown now completes cleanly (error is
> caught and logged).
>
Re: [VOTE] Ozone 2.1.1 RC0
Posted by Attila Doroszlai <ad...@apache.org>.
Thanks Wei-Chiu for the RC.
> https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc0/
* Verified signatures, checksums
* Verified docs in binary tarball
* Verified `ozone version`
However:
* When verifying against ozone-2.1.1-RC0 tag, found that source
tarball unexpectedly contains pom.xml.versionsBackup files
-Attila
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org