The UserGroupInformation API is incompatible between secure and nonsecure versions **of Hadoop** (among other issues). This leads to two issues:
- Runtime exceptions. We indeed do use reflection to do run time detection of which variant is available. - Compile time errors. We can't do anything about this. Hence the separate profile. And just FYI security has two components: the totally optional coprocessor-based access controller, and the secure RPC engine as a plug in option. If you don't enable either you won't see any runtime errors; however we can't easily build a single artifact because the secure RPC engine, as it interacts with the Hadoop auth framework, must use UserGroupInformation. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) >________________________________ > From: Stack <[email protected]> >To: [email protected] >Sent: Monday, March 5, 2012 11:59 PM >Subject: Re: DISCUSS: Have hbase require at least hadoop 1.0.0 in hbase 0.96.0? > >On Fri, Mar 2, 2012 at 12:57 PM, Nicolas Spiegelberg ><[email protected]> wrote: >> I'm wondering why HDFS security support should be mandatory? Append makes >> sense because there's no way to have a durable system without it. >> Security is currently an optional feature & implemented as an HBase >> co-processor (vs core), correct? Is there a problem (other than minor >> inconvenience) with using introspection APIs for security in the core and >> then warning if security is enabled but the API is unreachable? >> > >We could try and do that. > >The proposal is about pulling up the bottom end on the hadoop's we >will run on going forward. If all hadoop's from 1.0.0 on have >security, and we can depend on that being the case going forward, then >we could do things like ship a single artifact rather than the two we >currently ship; one that does not depend on a secure hadoop and >another that requires it. > >I forgot that 0.22 hadoop doesn't have security. Would suggest that >we drop support for it too in 0.96 hbase. > >St.Ack > > >
