+1 (binding)

Thanks Wei-Chiu for cutting RC1.

Verified on my Mac with JDK 8 and Maven 3.9.16:
* Verified GPG signatures and SHA512 checksums for source and binary
tarballs.
* Built from the source tarball with `mvn clean install -DskipTests`.
* Verified `ozone version` from the binary tarball. Reports 2.1.1.
* Verified docs are present in the binary tarball.

RC0 follow-up:
* The extra `pom.xml.versionsBackup` files reported on RC0 are no longer in
the RC1 source tarball.
* Non-blocking: `NOTICE.txt` still says `Copyright 2025`.
* Non-blocking: the Recon Namespace Usage issues tracked in HDDS-15495 are
unchanged in RC1.

-Siyao

On Mon, Jun 15, 2026 at 11:39 PM Wei-Chiu Chuang <[email protected]> wrote:

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

Reply via email to