Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Tue, 18 Mar 2014 20:50:50 +0000 (UTC)
From: "Chris Li (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12691153.1390605580968.99995.1395175850022@arcas>
In-Reply-To: <JIRA.12691153.1390605580968@arcas>
References: <JIRA.12691153.1390605580968@arcas>
Subject: [jira] [Commented] (HADOOP-10280) Make Schedulables return a
 configurable identity of user or group
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939764#comment-13939764 ] 

Chris Li commented on HADOOP-10280:
-----------------------------------

Haven't quite figured how to do that cleanly yet. If the information is available in the Call class somewhere, we could make it public and then specify an adapter class to handle forming an identity string.

We'd be making most of the members of Call public, but this approach would be most flexible. Let me know if that sounds reasonable.

> Make Schedulables return a configurable identity of user or group
> -----------------------------------------------------------------
>
>                 Key: HADOOP-10280
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10280
>             Project: Hadoop Common
>          Issue Type: Sub-task
>            Reporter: Chris Li
>            Assignee: Chris Li
>         Attachments: HADOOP-10280.patch, HADOOP-10280.patch
>
>
> In order to intelligently schedule incoming calls, we need to know what identity it falls under.
> We do this by defining the Schedulable interface, which has one method, getIdentity(IdentityType idType)
> The scheduler can then query a Schedulable object for its identity, depending on what idType is. 
> For example:
> Call 1: Made by user=Alice, group=admins
> Call 2: Made by user=Bob, group=admins
> Call 3: Made by user=Carlos, group=users
> Call 4: Made by user=Alice, group=admins
> Depending on what the identity is, we would treat these requests differently. If we query on Username, we can bucket these 4 requests into 3 sets for Alice, Bob, and Carlos. If we query on Groupname, we can bucket these 4 requests into 2 sets for admins and users.
> In this initial version, idType can be username or primary group. In future versions, it could be jobID, request class (read or write), or some explicit QoS field. These are user-defined, and will be reloaded on callqueue refresh.


--
This message was sent by Atlassian JIRA
(v6.2#6252)