hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: DISCUSSION: 1.0.0
Date Tue, 11 Feb 2014 21:06:28 GMT
> (Sigh....If only we had a RM for 1.0.0...)

Thanks Stack for bringing this up. I actually want to volunteer as an RM
for 1.0 release. We can do a 0.99 release first as a dev release, then turn
0.99.x into 1.0 as we did in 0.95 -> 0.96 releases.

As for timing, we can start by filing some jiras for the discussion items
and setting the target versions for those to see where we are at. 0.98 will
be out soon, and we want to make 1.0 sooner rather than later. Also if we
can nail the release before HBaseCon that would be good with users.

Enis


On Tue, Feb 11, 2014 at 12:46 PM, Stack <stack@duboce.net> wrote:

> A few us have gotten the "We need a Replication Interface defined" along
> another channel.
>
> Agree this is a good discussion.  I'll file issues to catch the above
> against the 0.99 label.
>
> (Sigh....If only we had a RM for 1.0.0...)
>
> St.Ack
>
>
> On Tue, Feb 11, 2014 at 11:21 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
>
> > FYI, Lily's Indexer [0] also makes use of this level of integration into
> > HBase. Others?
> >
> > [0]: https://github.com/NGDATA/hbase-indexer
> >
> >
> > On Tue, Feb 11, 2014 at 12:09 PM, Enis Söztutar <enis.soz@gmail.com>
> > wrote:
> >
> > > This is good discussion,
> > >
> > > I mentioned this in phoenix-dev that we need to repurpose coprocessors,
> > and
> > > just give them put / get kind of injection points, but not allow
> > > co-processors to tap into log / compaction, etc. Those will be better
> > > served by explicitly defined plugins (like the recent StorageEngine,
> > HLog,
> > > etc) that we explicitly allow injecting code with some API stability
> > > (though probably still evolving at a fast pace).
> > >
> > > It would be good to have an idea of what classes / methods, phoenix and
> > > similar depend on HBase right now.
> > >
> > > Enis
> > >
> > >
> > > On Mon, Feb 10, 2014 at 6:04 PM, Jeffrey Zhong <jzhong@hortonworks.com
> > > >wrote:
> > >
> > > >
> > > > We need to revisit which interfaces should be marked as real
> "private"
> > > > because coprocessors allow custom applications to accesses internal
> > > > states. Current private interface such as KeyValue, WALEdit, Hregion,
> > > > HLogKey, Store etc is may used by custom coprocessor applications so
> > any
> > > > public method signature change in those "private" interfaces
> possibliy
> > > > breaks custom coprocessor implementations.
> > > >
> > > > -Jeffrey
> > > >
> > > > On 2/10/14 4:59 PM, "lars hofhansl" <larsh@apache.org> wrote:
> > > >
> > > > >True. But we can clearly annotate what is public and what is not.
> > > > >In HRegion we'd have to do it per method. It's probably easier to
> > > extract
> > > > >the public interface out into a Interface. (similar to Store and
> > HStore)
> > > > >HBASE-4207 solves a slightly different problem. Here I want to have
> > > > >access to some HBase internals for performance, but I want to know
> > what
> > > > >is public and stable and what I should not touch (thinking about
> > things
> > > > >like Phoenix).
> > > > >
> > > > >
> > > > >-- Lars
> > > > >
> > > > >
> > > > >
> > > > >________________________________
> > > > > From: Andrew Purtell <apurtell@apache.org>
> > > > >To: "dev@hbase.apache.org" <dev@hbase.apache.org>
> > > > >Sent: Monday, February 10, 2014 4:46 PM
> > > > >Subject: Re: DISCUSSION: 1.0.0
> > > > >
> > > > >
> > > > >On Mon, Feb 10, 2014 at 4:42 PM, lars hofhansl <larsh@apache.org>
> > > wrote:
> > > > >
> > > > >
> > > > >> + known coprocessor interfaces. For example right now a
> coprocessor
> > > can
> > > > >> use everything on HRegion. We need to distill what's useful into
> an
> > > > >> interface.
> > > > >
> > > > >
> > > > >We started this with Environment and the HTable wrapper as an
> example
> > of
> > > > >how to wrap an interface for CPs. At the end of the day we can't
> stop
> > a
> > > > >coprocessor from accessing internal objects and calling their
> methods
> > > > >directly until HBASE-4047. (Maybe that makes the 1.0 list?)
> > > > >
> > > > >Related, paring down the coprocessor interfaces to only intercept
> RPC
> > > > >based
> > > > >actions and move everything else to plugins.
> > > > >
> > > > >
> > > > >
> > > > >--
> > > > >Best regards,
> > > > >
> > > > >   - Andy
> > > > >
> > > > >Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > >(via Tom White)
> > > >
> > > >
> > > >
> > > > --
> > > > CONFIDENTIALITY NOTICE
> > > > NOTICE: This message is intended for the use of the individual or
> > entity
> > > to
> > > > which it is addressed and may contain information that is
> confidential,
> > > > privileged and exempt from disclosure under applicable law. If the
> > reader
> > > > of this message is not the intended recipient, you are hereby
> notified
> > > that
> > > > any printing, copying, dissemination, distribution, disclosure or
> > > > forwarding of this communication is strictly prohibited. If you have
> > > > received this communication in error, please contact the sender
> > > immediately
> > > > and delete it from your system. Thank You.
> > > >
> > >
> >
>

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