Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase, mail # dev - DISCUSS: Have hbase require at least hadoop 1.0.0 in hbase 0.96.0?


+
Stack 2012-03-02, 19:24
+
Andrew Purtell 2012-03-03, 02:39
+
Ioan Eugen Stan 2012-03-06, 12:04
+
Huanyou Chang 2012-03-06, 10:57
+
Ramkrishna.S.Vasudevan 2012-03-06, 11:22
+
Ted Yu 2012-03-02, 20:50
+
Nicolas Spiegelberg 2012-03-02, 20:57
+
Stack 2012-03-06, 07:59
+
Andrew Purtell 2012-03-06, 17:10
+
Stack 2012-03-06, 17:55
+
Andrew Purtell 2012-03-06, 18:21
+
Arun C Murthy 2012-03-06, 19:57
+
Devaraj Das 2012-03-07, 18:20
+
Mikhail Bautin 2012-03-07, 19:42
+
Ted Yu 2012-03-07, 20:17
+
Andrew Purtell 2012-03-07, 22:39
+
Stack 2012-03-08, 06:09
+
Jonathan Hsieh 2012-03-08, 08:31
+
Stack 2012-03-08, 17:08
+
Mikhail Bautin 2012-03-08, 23:29
+
Andrew Purtell 2012-03-07, 22:32
Copy link to this message
-
Re: DISCUSS: Have hbase require at least hadoop 1.0.0 in hbase 0.96.0?
Gary Helmling 2012-03-07, 09:38
> Andy - could you please start a discussion?
>
> We could, at the very least, mark UGI as LimitedPrivate for HBase and work with you guys to maintain compatibility for the future. Makes sense?
>

That would probably help for internal usage of UGI in the secure RPC
engine.  As Andy points out, we do already encapsulate UGI in our own
org.apache.hadoop.hbase.security.User class (which uses reflection to
account for the API incompatibilities) outside of the RPC engine.  We
do also make direct use of some other Hadoop security classes to
implement secure RPC:

org.apache.hadoop.security.authorize.PolicyProvider
org.apache.hadoop.security.authorize.Service
org.apache.hadoop.security.authorize.ServiceAuthorizationManager
org.apache.hadoop.security.SaslInputStream
org.apache.hadoop.security.SaslOutputStream
org.apache.hadoop.security.token.SecretManager
org.apache.hadoop.security.token.Token
org.apache.hadoop.security.token.TokenIdentifier

If we require Hadoop 1.0.0 then these others should at least be
available, though I don't know the API stability of each.  If we
don't, then the best way towards a single build for release seems
continuing towards modularization so that the security classes can be
built in a separate jar and included in the classpath when enabled.
Handling all of these interactions through reflection does not seem
desirable (or sane) to me.

--gh
+
lars hofhansl 2012-03-02, 19:29
+
Jesse Yates 2012-03-02, 19:32