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