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

Switch to Threaded View
MapReduce >> mail # dev >> Re: hadoop.job.ugi backwards compatibility


Copy link to this message
-
Re: hadoop.job.ugi backwards compatibility
On Sep 13, 2010, at 4:23 PM, Todd Lipcon wrote:

> I agree that keeping API compatibility for UGI was probably  
> impossible, and
> respect that. But it would certainly be very easy to do a patch like  
> the
> following:
>
> JobClient(Configuration conf) {
>  if (conf.get("hadoop.job.ugi") != null &&
> UserGroupInformation.isSecurityEnabled()) {
>    LOG.warn("Stop being evil. Don't use hadoop.job.ugi! RAAWR");
>    UserGroupInformation.createRemoteUser(...).doAs() { create proxy }
>  } else {
>    create normal RPC proxy;
>  }
> }

My problem is three fold:
   1. It isn't one or two spots. It is a *lot* of spots. Doing it  
inconsistently would be far worse than useless.
   2. Having two different authentication paths dramatically increases  
the chance for bugs.
   3. The previously mentioned badness where the api semantics  
dramatically change with the value of a config variable that isn't  
there to enable backwards compatibility.

Furthermore, the upside is really small consisting of only the users  
that have:
   1. developed internal servers that handle multiple users.
   2. on hadoop 0.20
   3. never plan on turning on security
   4. are interested in moving to 0.21 or 0.22
   5. aren't willing to do the straightforward fixes to their code.

-- Owen