Yes, we’ll use reflection to make use of APIs introduced in newer HDFS
versions than the stated dependency until the stated dependency finally
catches up.

On Mon, 9 Sep 2024 at 19:55, Wei-Chiu Chuang <weic...@apache.org> wrote:

> Reflection is probably the way to go to ensure maximum compatibility TBH
>
> On Mon, Sep 9, 2024 at 10:40 AM Istvan Toth <st...@cloudera.com.invalid>
> wrote:
>
> > Stephen Wu has kindly sent me the link for the previous email thread:
> > https://lists.apache.org/thread/2k4tvz3wpg06sgkynkhgvxrodmj86vsj
> >
> > Reading it, I cannot see anything there that would contraindicate
> upgrading
> > to 3.3.6 from 3.3.5, at least on the branches that already default to
> > 3.3.5, i.e. 2.6+.
> >
> > At first glance, the new logic in HBASE-27769 could also be implemented
> > with the usual reflection hacks, while preserving the old logic for
> Hadoop
> > 3.3.5 and earlier.
> >
> > Thanks,
> > Istvan
> >
> >
> >
> > On Mon, Sep 9, 2024 at 1:42 PM Istvan Toth <st...@cloudera.com> wrote:
> >
> > > Thanks for your reply, Nick.
> > >
> > > There are no listed direct CVEs in either Hadoop 3.2.4 or 3.3.5, but
> > there
> > > are CVEs in their transitive dependencies.
> > >
> > > My impression is that rather than shipping the oldest 'safe' version,
> > > HBase does seem to update the default Hadoop version to the latest-ish
> at
> > > the time of the start
> > > of the release process, otherwise 2.6 would still default to 3.2.4.
> > (HBase
> > > 2.6 release was already underway when Hadoop 3.4.0 was released)
> > >
> > > For now, we (Phoenix) have resorted to dependency managing transitive
> > > dependencies coming in (only) via Hadoop in Phoenix,
> > > but that is a slippery slope, and adds a layer of uncertainty, as it
> may
> > > introduce incompatibilities in Hadoop that we don't have tests for.
> > >
> > > Our situation is similar to that of the HBase shaded artifacts, where
> we
> > > ship a huge uberjar that includes much of both HBase and Hadoop on top
> of
> > > (or rather below) Phoenix,
> > > similar to the hbase-client-shaded jar.
> > >
> > > I will look into to hadoop check CI tests that you've mentioned, then I
> > > will try to resurrect HBASE-27931, and if I don't find any issues, and
> > > there are no objections, then
> > > I will put a PR to update the unreleased version to default to 3.4.0.
> > >
> > > Istvan
> > >
> > > On Mon, Sep 9, 2024 at 11:06 AM Nick Dimiduk <ndimi...@apache.org>
> > wrote:
> > >
> > >> My understanding of our hadoop dependency policy is that we ship poms
> > with
> > >> hadoop versions pinned to the oldest compatible, "safe" version that
> is
> > >> supported. Our test infrastructure has a "hadoop check" procedure that
> > >> does
> > >> some validation against other patch release versions.
> > >>
> > >> I don't know if anyone has done a CVE sweep recently. If there are new
> > >> CVEs, we do bump the minimum supported version specified in the pom as
> > >> part
> > >> of patch releases. These changes need to include a pretty thorough
> > >> compatibility check so that we can include release notes about any
> > >> introduced incompatibilities.
> > >>
> > >> I am in favor of a dependency bump so as to address known CVEs as best
> > as
> > >> we reasonably can.
> > >>
> > >> Thanks,
> > >> Nick
> > >>
> > >> On Mon, Sep 9, 2024 at 10:59 AM Istvan Toth <st...@apache.org> wrote:
> > >>
> > >> > Hi!
> > >> >
> > >> > I'm working on building the Phoenix uberjars with newer Hadoop
> > versions
> > >> by
> > >> > default to improve its CVE stance, and I realized that HBase itself
> > does
> > >> > not use the latest releases.
> > >> >
> > >> > branch-2.5 defaults to 3.2.4
> > >> > branch-2.6 and later defaults to 3.3.5
> > >> >
> > >> > I can kind of understand that we don't want to bump the minor
> version
> > >> for
> > >> > branch-2.5 from the one it was released with.
> > >> >
> > >> > However, I don't see the rationale for not upgrading branch-2.6 to
> at
> > >> least
> > >> > 3.3.6, and the unreleased branches (branch-2, branch-3, master) to
> > >> 3.4.0.
> > >> >
> > >> > I found a mention of wanting to stay off the latest patch release
> > >> > HBASE-27931, but I could not figure if it has a technical reason, or
> > if
> > >> > this is a written (or unwritten) policy.
> > >> >
> > >> > best regards
> > >> > Istvan
> > >> >
> > >>
> > >
> > >
> > > --
> > > *István Tóth* | Sr. Staff Software Engineer
> > > *Email*: st...@cloudera.com
> > > cloudera.com <https://www.cloudera.com>
> > > [image: Cloudera] <https://www.cloudera.com/>
> > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image:
> > > Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera>
> > > ------------------------------
> > > ------------------------------
> > >
> >
> >
> > --
> > *István Tóth* | Sr. Staff Software Engineer
> > *Email*: st...@cloudera.com
> > cloudera.com <https://www.cloudera.com>
> > [image: Cloudera] <https://www.cloudera.com/>
> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image:
> Cloudera
> > on LinkedIn] <https://www.linkedin.com/company/cloudera>
> > ------------------------------
> > ------------------------------
> >
>

Reply via email to