Here's the RC1: it's essentially the same as the RC0 except the pom.xml.versionsBackup files.
git tag: https://github.com/apache/ozone/releases/tag/ozone-2.1.1-RC1 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 diff between RC0 and RC1: https://github.com/apache/ozone/compare/ozone-2.1.1-RC0...ozone-2.1.1-RC1 Source and binary tarball: https://dist.apache.org/repos/dist/dev/ozone/2.1.1-rc1/ Maven artifacts: https://repository.apache.org/content/repositories/orgapacheozone-1064/ My public key 3ED23305D7631918: https://dist.apache.org/repos/dist/release/ozone/KEYS All non-blocker issues found during release task: https://issues.apache.org/jira/browse/HDDS-15418 Build env: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 13 (trixie) Release: 13 Codename: trixie $ java -version openjdk version "1.8.0_492" OpenJDK Runtime Environment (Temurin)(build 1.8.0_492-b09) OpenJDK 64-Bit Server VM (Temurin)(build 25.492-b09, mixed mode) $ mvn -version Apache Maven 3.9.16 (2bdd9fddda4b155ebf8000e807eb73fd829a51d5) Maven home: /home/admin/apache-maven-3.9.16 Java version: 1.8.0_492, vendor: Temurin, runtime: /usr/lib/jvm/temurin-8-jdk-amd64/jre Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "6.12.90+deb13.1-cloud-amd64", arch: "amd64", family: "unix" +1 verified SBOM On Mon, Jun 15, 2026 at 7:59 AM Wei-Chiu Chuang <[email protected]> wrote: > 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 <[email protected]> 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 <[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] >> > >> > >> >
