Re: impersonation and application path

2017-05-30 Thread Pramod Immaneni
Voting has completed and JIRA has been created https://issues.apache.org/jira/browse/APEXCORE-733 Thanks On Mon, May 22, 2017 at 3:12 PM, Sanjay Pujare wrote: > Sounds good. > > Also I would like to work on this so the JIRA can be assigned to me. > > On Mon, May 22, 2017 at 3:06 PM, Pramod Imm

Re: [VOTE] impersonation and application path

2017-05-30 Thread Pramod Immaneni
The vote concludes with 2 for keeping the default behavior same as today and adding a new setting to specify using impersonated user's resources 1 for changing default behavior to using impersonated user's resources and reusing APPLICATION_PATH to specify path for impersonating user Thanks On We

Re: [VOTE] impersonation and application path

2017-05-24 Thread Pramod Immaneni
APPLICATION_PATH will still take priority but it also needs the caller to identify a path, as opposed to a default one chosen by convention by the system for the impersonating or impersonated user. Second, the setting signifies an intent to use resources of the specified user, like I noted in the d

Re: [VOTE] impersonation and application path

2017-05-24 Thread Vlad Rozov
My view is from a different angle. APPLICATION_PATH takes the priority and is used if specified. For me it's odd to use another settings to specify default, when the APPLICATION_PATH can be explicitly set. Thank you, Vlad On 5/24/17 07:07, Pramod Immaneni wrote: The way I see it, based on y

Re: [VOTE] impersonation and application path

2017-05-24 Thread Pramod Immaneni
The way I see it, based on your comments your vote is for option 2. a) which is default to impersonated user and caller uses APPLICATION_PATH to override the path to use impersonating user if needed. Not sure why we would need a separate vote. The new setting in option 1. b would default to imperso

Re: [VOTE] impersonation and application path

2017-05-23 Thread Vlad Rozov
IMO, it should be different vote. In case APPLICATION_PATH is explicitly specified, it should be used. If it is not specified, there are few options to consider. 1. My suggestion was always default to the impersonated user home directory as a starting point for constructing APPLICATION_PATH 2. Y

Re: [VOTE] impersonation and application path

2017-05-23 Thread Pramod Immaneni
I thought it was the mechanism you suggested to specify impersonating user's directory so I listed it here. If I am mistaken and your option is not covered, please include it and since it is early in the voting folks can include it in their voting preference. If not, please provide your choice. Th

Re: [VOTE] impersonation and application path

2017-05-23 Thread Vlad Rozov
I don't see how option a is applicable here. In case APPLICATION_PATH is explicitly specified should not it be used independently of impersonation? It can point to any location, not necessarily to home directory of impersonating or impersonated user. Thank you, Vlad On 5/23/17 10:34, Pramod

Re: [VOTE] impersonation and application path

2017-05-23 Thread Sanjay Pujare
+1 for Option 1, Sub-option b. On Tue, May 23, 2017 at 10:34 AM, Pramod Immaneni wrote: > Based on the discussion on the dev list on this topic, captured here > 4431016024f61703b248ce7bfb@%3Cdev.apex.apache.org%3E>, > a few d

[VOTE] impersonation and application path

2017-05-23 Thread Pramod Immaneni
Based on the discussion on the dev list on this topic, captured here , a few different approaches were discussed including the pros and cons. I would like to put the suggested ap

Re: impersonation and application path

2017-05-22 Thread Sanjay Pujare
Sounds good. Also I would like to work on this so the JIRA can be assigned to me. On Mon, May 22, 2017 at 3:06 PM, Pramod Immaneni wrote: > I see the advantage in having a top level setting that says use > "impersonating user" vs "impersonated user" resources. This can internally > switch the r

Re: impersonation and application path

2017-05-22 Thread Pramod Immaneni
I see the advantage in having a top level setting that says use "impersonating user" vs "impersonated user" resources. This can internally switch the resources, there could be resources other than application path in future and they would also be covered. I would still leave the default to be the i

Re: impersonation and application path

2017-05-19 Thread Sanjay Pujare
I agree. But how do we use APPLICATION_PATH for this purpose since we need a Yes/No flag to specify new vs old behavior? So we have to use a new setting for this (something like USE_RUNTIME_USER_APPLICATION_PATH ?) On Fri, May 19, 2017 at 7:57 AM, Pramod Immaneni wrote: > I wouldn't necessarily

Re: impersonation and application path

2017-05-19 Thread Pramod Immaneni
I wouldn't necessarily consider the current behavior a bug and the default is fine the way it is today, especially because the user launching the app is not the user. APPLICATION_PATH can be used as the setting. On Fri, May 19, 2017 at 7:43 AM, Vlad Rozov wrote: > Do I understand correctly that

Re: impersonation and application path

2017-05-19 Thread Vlad Rozov
Do I understand correctly that the question is regarding DAGContext.APPLICATION_PATH attribute value in case it is not defined? In this case, I would treat the current behavior as a bug and +1 the proposal to set it to the impersonated user B DFS home directory. As APPLICATION_PATH can be expli

Re: impersonation and application path

2017-05-18 Thread Priyanka Gugale
+1 for proposal. Can we make new behaviour of writing to users own directory as default? Most probably users will upgrade gateway with apex-core. If not, they always have option to set the flag and fall back to legacy behaviour. -Priyanka On Fri, May 19, 2017 at 7:52 AM, Chinmay Kolhatkar wrote

Re: impersonation and application path

2017-05-18 Thread Chinmay Kolhatkar
+1 for pramod's proposal. On 19-May-2017 4:51 AM, "Sanjay Pujare" wrote: > +1 for Pramod's proposal for impersonation. > > I have an issue with Sandesh's suggestion about making the new behavior as > the default (or only) behavior. This will introduce incompatibility with > other legacy tools (e

Re: impersonation and application path

2017-05-18 Thread Sanjay Pujare
+1 for Pramod's proposal for impersonation. I have an issue with Sandesh's suggestion about making the new behavior as the default (or only) behavior. This will introduce incompatibility with other legacy tools (e.g. Datatorrent's dtGateway) that assume user A's HDFS path as the application path.

Re: impersonation and application path

2017-05-18 Thread Sandesh Hegde
My vote is to make the new proposal as the default behavior. Is there a use case for the current behavior? If not then no need to add the configuration setting. On Thu, May 18, 2017 at 3:47 PM Pramod Immaneni wrote: > Sorry typo in sentence "as we are not asking for permissions for a lower > pri

Re: impersonation and application path

2017-05-18 Thread Pramod Immaneni
Sorry typo in sentence "as we are not asking for permissions for a lower privilege", please read as "as we are now asking for permissions for a lower privilege". On Thu, May 18, 2017 at 3:44 PM, Pramod Immaneni wrote: > Apex cli supports impersonation in secure mode. With impersonation, the > us

impersonation and application path

2017-05-18 Thread Pramod Immaneni
Apex cli supports impersonation in secure mode. With impersonation, the user running the cli or the user authenticating with hadoop (henceforth referred to as login user) can be different from the effective user with which the actions are performed under hadoop. An example for this is an applicatio