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
