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