You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Ted Yu <yu...@gmail.com> on 2014/03/03 05:54:15 UTC
Re: DISCUSSION: 1.0.0
The following thread brought attention to HBASE-9206 'namespace permissions'
:
http://search-hadoop.com/m/DHED49RMDk/enable%252Fdisable+table+permission&subj=enable+disable+table+permission
This would help user implement multi-tenancy in a shared cluster.
Cheers
On Tue, Feb 11, 2014 at 12:43 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> Lily's indexer uses hbase private apis in the replication portion of code.
> we may want to expose and make promises on the replication api/wire to
> make their lives easier and to enable cross version replication for future
> hbases.
>
> Jon.
>
>
> On Tue, Feb 11, 2014 at 11:21 AM, Nick Dimiduk <nd...@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 <en...@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" <la...@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 <ap...@apache.org>
> > > > >To: "dev@hbase.apache.org" <de...@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 <la...@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.
> > > >
> > >
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>
Re: DISCUSSION: 1.0.0
Posted by Enis Söztutar <en...@gmail.com>.
Thanks Ted.
It makes sense to fix it before 1.0 if we can.
Enis
On Sun, Mar 2, 2014 at 8:54 PM, Ted Yu <yu...@gmail.com> wrote:
> The following thread brought attention to HBASE-9206 'namespace
> permissions'
> :
>
>
> http://search-hadoop.com/m/DHED49RMDk/enable%252Fdisable+table+permission&subj=enable+disable+table+permission
>
> This would help user implement multi-tenancy in a shared cluster.
>
> Cheers
>
>
> On Tue, Feb 11, 2014 at 12:43 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> > Lily's indexer uses hbase private apis in the replication portion of
> code.
> > we may want to expose and make promises on the replication api/wire to
> > make their lives easier and to enable cross version replication for
> future
> > hbases.
> >
> > Jon.
> >
> >
> > On Tue, Feb 11, 2014 at 11:21 AM, Nick Dimiduk <nd...@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 <en...@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" <la...@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 <ap...@apache.org>
> > > > > >To: "dev@hbase.apache.org" <de...@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 <la...@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.
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Tech Lead, Software Engineer, Cloudera
> > // jon@cloudera.com // @jmhsieh
> >
>