+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 <[email protected]> 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
> <[email protected]> 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 <[email protected]> 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: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> > >
> >
> > --
> > Thanks,
> > Saketa Chalamchala
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
