Return-Path: X-Original-To: apmail-hadoop-common-user-archive@www.apache.org Delivered-To: apmail-hadoop-common-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EC540DF32 for ; Fri, 14 Sep 2012 05:39:26 +0000 (UTC) Received: (qmail 38435 invoked by uid 500); 14 Sep 2012 05:39:21 -0000 Delivered-To: apmail-hadoop-common-user-archive@hadoop.apache.org Received: (qmail 38172 invoked by uid 500); 14 Sep 2012 05:39:20 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 38144 invoked by uid 99); 14 Sep 2012 05:39:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Sep 2012 05:39:19 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dechouxb@gmail.com designates 209.85.216.176 as permitted sender) Received: from [209.85.216.176] (HELO mail-qc0-f176.google.com) (209.85.216.176) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Sep 2012 05:39:15 +0000 Received: by qcsc21 with SMTP id c21so3339687qcs.35 for ; Thu, 13 Sep 2012 22:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MxpX7hpUZNnDX/w6JdqVB72UuDrK9Lj+tKB1M/4zAJs=; b=wc1TQy2+MaYr6uhelf9c96bVisAIhEpmogZAwThZuGIrrGt6x7ZyB2EIRaRFoCVqhl 7ZkUVxFjcFGxFXOnvE3xkGkuBi9njKUW4Y9RxUPCPFyFPbV7J9pRYRYfXoh9Jt5gi4vx BrEPeCSkze5V8bDW6+Hj1pluFjI+FwzuCU1jAbaUTLy1XaHMWUQAhdBMR+ncP5MXrBJK l8+nOGO3TyUJgx6R35KIYsdsY1VGNrb3odiyDfWLNbBBy7Yc3echYY2vlfRKOCGfNU17 Ifyl/Aq5F0vFv//kWXEDSloGl+7lB9rkBXyfl3K9sNKKJZAXhaOfcku/9KsGhCAwDU7g f3og== MIME-Version: 1.0 Received: by 10.229.135.75 with SMTP id m11mr1055259qct.66.1347601134256; Thu, 13 Sep 2012 22:38:54 -0700 (PDT) Received: by 10.49.71.231 with HTTP; Thu, 13 Sep 2012 22:38:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 07:38:54 +0200 Message-ID: Subject: Re: Configuration of hadoop.job.history.user.location on a user basis From: Bertrand Dechoux To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=00248c6a66c2e803fd04c9a2d6bd X-Virus-Checked: Checked by ClamAV on apache.org --00248c6a66c2e803fd04c9a2d6bd Content-Type: text/plain; charset=ISO-8859-1 Hi Hemanth, I thought of that but I didn't test it because I need the same for the job id. Of course, I could generate my own id but I don't like that solution. I will look at hadoop.tmp.dir to see if it can solve my issue differently. Regards Bertrand On Fri, Sep 14, 2012 at 5:54 AM, Hemanth Yamijala wrote: > Hi Bretrand, > > Could you try using user.name as a property in the value of the config > item ? Something like /user/${user.name}/history ? > > Thanks > hemanth > > > On Thu, Sep 13, 2012 at 5:46 PM, Bertrand Dechoux wrote: > >> Hi, >> >> I would like to be able to fully isolate the quota of each user. >> That is, I would like to put everything related to a user into her/his >> home directory /user/. >> >> Among other points of configuration, I would like to be able to configure >> hadoop.job.history.user.location. >> But I can't see how it could be done. >> >> How can I have a different path for each user? >> How do I make sure that each job will still have its own directory? (Even >> when no output dir is defined for the job.) >> >> Other question, slightly related. If I deactivate those logs using the >> "none" configuration, it should only impact the copy of the user, should it >> not? >> The user should still be able to browse the logs using the version >> provided through the jobtracker web interface, should it not? >> >> Regards >> >> Bertrand >> > > -- Bertrand Dechoux --00248c6a66c2e803fd04c9a2d6bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi=A0Hemanth,

I thought of that but I didn't t= est it because I need the same for the job id. Of course, I could generate = my own id but I don't like that solution. I will look at hadoop.tmp.dir= to see if it can solve my issue differently.

Regards

Bertrand

On Fri, Sep 14, 2012 at 5:54 AM, Hemanth Yamijala <yhemanth@thoughtworks.com> wrote:
Hi Bretrand,

Could you tr= y using user.name as a p= roperty in the value of the config item ? Something like /user/${user.name}/history ?

Thanks
hemanth


On Thu, Sep 13, 2012 at 5:46 PM, Bertrand Dechoux <dechouxb@gmail= .com> wrote:
Hi,

I would like to be able to fully = isolate the quota of each user.
That is, I would like to put everything = related to a user into her/his home directory /user/<user>.

Among other points of configuration, I would like to be able to configu= re hadoop.job.history.user.location.
But I can't see how it could be done.

How can I have a different= path for each user?
How do I make sure that each job will still have it= s own directory? (Even when no output dir is defined for the job.)

Other question, slightly related. If I deactivate those logs using the &quo= t;none" configuration, it should only impact the copy of the user, sho= uld it not?
The user should still be able to browse the logs using the v= ersion provided through the jobtracker web interface, should it not?

Regards

Bertrand




--
Bertrand Dec= houx
--00248c6a66c2e803fd04c9a2d6bd--