hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Liochon <nkey...@gmail.com>
Subject Re: [DISCUSS] Dependency compatibility
Date Fri, 13 Mar 2015 16:54:17 GMT
>There's no reason our HDFS usage should be exposed in the HBase client code
I did look at this in the past, IIRC, our dependency was we use
hadoop-common code to read our XML configuration files....
I would +1 a code duplication to remove the dependency.

I also think it is important for the end user.

On Fri, Mar 13, 2015 at 5:43 PM, Sean Busbey <busbey@cloudera.com> wrote:

> On Fri, Mar 13, 2015 at 11:18 AM, Andrew Purtell <apurtell@apache.org>
> wrote:
> > > I'm -1 (non-binding) on weakening our compatibility promises. The more
> > we can
> > isolate our users from the impact of changes upstream the better.
> >
> > We can't though in general. Making compatibility promises we can't keep
> > because our upstreams don't (see the dependencies section of Hadoop's
> > compatibility guidelines) is ultimately an untenable position. *If* we
> had
> > some complete dependency isolation for MapReduce and coprocessors
> committed
> > then this could be a different conversation. Am I misstating this?
> >
> > ‚ÄčIn this specific instance we do have another option, so we could defer
> > this to a later time when a really unavoidable dependency change
> happens...
> > like a Guava update affecting HDFS. (We had one of those before.) We can
> > document the Jackson classpath issue with Hadoop >= 2.6 and provide
> > remediation advice in the troubleshooting section of the manual.
> >
> >
> I think we can solve this generally for Hadoop 2.6.0+. There's no reason
> our HDFS usage should be exposed in the HBase client code, and I think the
> application classpath feature for YARN in that version can isolate us on
> the MR side. I am willing to do this work in time for 1.1. Realistically I
> don't know the timeline for that version yet. If it turns out the work is
> more involved or my time is more constrained then I think, I'm willing to
> accept promise weakening as a practical matter.
> I'd be much more comfortable weakening our dependency promises for
> coprocessor than doing it in general. Folks running coprocessors should
> already be more risk tolerant and familiar with our internals.
> For upstreams that don't have the leverage on us of Hadoop, we solve this
> problem simply by not updating dependencies that we can't trust to not
> break our downstreams.
> > I would be disappointed to see a VOTE thread. That means we failed to
> reach
> > consensus and needed to fall back to process to resolve differences.
> >
> >
> That's fair. What about the wider audience issue on user@? There's no
> reason our DISCUSS threads couldn't go there as well.
> > Why don't we do the doc update and call it a day?
> >
> I've been burned by dependency changes in projects I rely on many times in
> the past, usually over changes in code sections that folks didn't think
> were likely to be used. So I'm very willing to do work now to save
> downstream users of HBase that same headache.
> --
> Sean

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message