[
https://issues.apache.org/jira/browse/HADOOP-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623897#action_12623897
]
Hemanth Yamijala commented on HADOOP-3698:
------------------------------------------
bq. We could fold the change queue properties in the admin operation you listed
above.
Yes, this is what I meant by 'configuring a queue'. It means changing queue
properties. In internal discussions, the consensus was that this operation will
be controlled only by administrators of the system itself - and not delegated
to others by setting up access control.
bq. The changeACL is a new operation - the users who are permitted this are
effectively the queue owners.
In the same discussions, it seemed like sysadmins would like to control this
themselves as well. Again, there did not seem a need to set up access control.
That said, it is really simple to add new operations in the design above when
we feel we need it. That's one advantage with this approach.
bq. It seems to me that job operations and file system operations are similar
... Is the analogue right? If yes, we might want to have a similar access
control model as the one in file system.
This was indeed the option we considered at first. There were a couple of
reasons, we chose the model I proposed over the file system ACLs model:
- While it seems easy to map operations like you've said, the problem was more
with the roles: the current ACL model of the file system uses Posix like ACLs,
which have three roles - owner, group and others. For queue administration,
there are the following roles: users, job-administrators, queue-administrators.
Each of these roles could be an individual user or users in a group. In
particular, the user-group who can submit jobs is different from the job or
queue admin groups. Since in the Posix model, there is only one group possible,
it was not flexible enough to set up the ACLs as needed.
- While there is a very good similarity between the file system operations and
queue operations, it seems more logical to model queue administration based on
how it is typically done in other scheduling / resource-management systems. All
of these seem to follow the model I've proposed above.
- As is seen from this comment, it is easy (more flexible) to add more
operations in this model.
bq. I think ADMINISTER_JOBS sounds too general. We might want to divide it into
more specific operations, say DELETE_JOB, SET_JOB_PRIORITY, etc.
Hmm... it seems to me that a person who needs to do one of these, will in a
different situation need to do the other as well. For instance, a job-admin
might be asked to bump up the priority of a job, as it is realized that it
needs to complete before others. This same admin might be asked to delete a job
because it is stuck in front of the queue without progress and impeding the
jobs after it. Can you explain your use-case about why you think these should
be different ?
> Implement access control for submitting jobs to queues in the JobTracker
> ------------------------------------------------------------------------
>
> Key: HADOOP-3698
> URL: https://issues.apache.org/jira/browse/HADOOP-3698
> Project: Hadoop Core
> Issue Type: New Feature
> Components: mapred
> Reporter: Hemanth Yamijala
> Assignee: Hemanth Yamijala
> Fix For: 0.19.0
>
>
> HADOOP-3445 implements multiple queues in the JobTracker as part of the new
> resource manager for Hadoop (HADOOP-3421). There needs to be a mechanism to
> control who can submit jobs to a specified queue. This JIRA is for tracking
> the requirements, approach and implementation for the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
