+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]
