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 <yuzhih...@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 <j...@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 <ndimi...@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....@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 < > jzh...@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 <apurt...@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 <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 > > // j...@cloudera.com // @jmhsieh > > >