hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From asur...@apache.org
Subject hadoop git commit: YARN-4687. Document Reservation ACLs (Contributed by Sean Po)
Date Thu, 24 Mar 2016 17:42:23 GMT
Repository: hadoop
Updated Branches:
  refs/heads/branch-2.8 2399e1e46 -> 945e3cd55


YARN-4687. Document Reservation ACLs (Contributed by Sean Po)

(cherry picked from commit 2e1d0ff4e901b8313c8d71869735b94ed8bc40a0)


Project: http://git-wip-us.apache.org/repos/asf/hadoop/repo
Commit: http://git-wip-us.apache.org/repos/asf/hadoop/commit/945e3cd5
Tree: http://git-wip-us.apache.org/repos/asf/hadoop/tree/945e3cd5
Diff: http://git-wip-us.apache.org/repos/asf/hadoop/diff/945e3cd5

Branch: refs/heads/branch-2.8
Commit: 945e3cd55ceccbdcffcdb414b997995ff50699dc
Parents: 2399e1e
Author: Arun Suresh <asuresh@apache.org>
Authored: Thu Mar 24 10:40:51 2016 -0700
Committer: Arun Suresh <asuresh@apache.org>
Committed: Thu Mar 24 10:42:07 2016 -0700

----------------------------------------------------------------------
 .../src/site/markdown/CapacityScheduler.md              | 12 ++++++++++++
 .../hadoop-yarn-site/src/site/markdown/FairScheduler.md |  6 +++++-
 2 files changed, 17 insertions(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/hadoop/blob/945e3cd5/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/CapacityScheduler.md
----------------------------------------------------------------------
diff --git a/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/CapacityScheduler.md
b/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/CapacityScheduler.md
index b43a032..e86c4f9 100644
--- a/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/CapacityScheduler.md
+++ b/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/CapacityScheduler.md
@@ -229,6 +229,18 @@ The following configuration parameters can be configured in yarn-site.xml
to con
 |:---- |:---- |
 | `yarn.scheduler.capacity.<queue-path>.disable_preemption` | This configuration can
be set to `true` to selectively disable preemption of application containers submitted to
a given queue. This property applies only when system wide preemption is enabled by configuring
`yarn.resourcemanager.scheduler.monitor.enable` to *true* and `yarn.resourcemanager.scheduler.monitor.policies`
to *ProportionalCapacityPreemptionPolicy*. If this property is not set for a queue, then the
property value is inherited from the queue's parent. Default value is false.
 
+###Reservation Properties
+
+  * Reservation Administration & Permissions
+
+  The `CapacityScheduler` supports the following parameters to control the creation, deletion,
update, and listing of reservations. Note that any user can update, delete, or list their
own reservations. If reservation ACLs are enabled but not defined, everyone will have access.
In the examples below, \<queue\> is the queue name. For example, to set the reservation
ACL to administer reservations on the default queue, use the property `yarn.scheduler.capacity.root.default.acl_administer_reservations`
+
+| Property | Description |
+|:---- |:---- |
+| `yarn.scheduler.capacity.root.<queue>.acl_administer_reservations` | The ACL which
controls who can *administer* reservations to the given queue. If the given user/group has
necessary ACLs on the given queue or they can submit, delete, update and list all reservations.
ACLs for this property *are not* inherited from the parent queue if not specified. |
+| `yarn.scheduler.capacity.root.<queue>.acl_list_reservations` | The ACL which controls
who can *list* reservations to the given queue. If the given user/group has necessary ACLs
on the given queue they can list all applications. ACLs for this property *are not* inherited
from the parent queue if not specified. |
+| `yarn.scheduler.capacity.root.<queue>.acl_submit_reservations` | The ACL which controls
who can *submit* reservations to the given queue. If the given user/group has necessary ACLs
on the given queue they can submit reservations. ACLs for this property *are not* inherited
from the parent queue if not specified. |
+
 ###Other Properties
 
   * Resource Calculator

http://git-wip-us.apache.org/repos/asf/hadoop/blob/945e3cd5/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/FairScheduler.md
----------------------------------------------------------------------
diff --git a/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/FairScheduler.md
b/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/FairScheduler.md
index 01fad34..7694de3 100644
--- a/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/FairScheduler.md
+++ b/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/FairScheduler.md
@@ -195,12 +195,16 @@ The allocation file must be in XML format. The format contains five
types of ele
 
 ###Queue Access Control Lists
 
-Queue Access Control Lists (ACLs) allow administrators to control who may take actions on
particular queues. They are configured with the aclSubmitApps and aclAdministerApps properties,
which can be set per queue. Currently the only supported administrative action is killing
an application. Anybody who may administer a queue may also submit applications to it. These
properties take values in a format like "user1,user2 group1,group2" or " group1,group2". An
action on a queue will be permitted if its user or group is in the ACL of that queue or in
the ACL of any of that queue's ancestors. So if queue2 is inside queue1, and user1 is in queue1's
ACL, and user2 is in queue2's ACL, then both users may submit to queue2.
+Queue Access Control Lists (ACLs) allow administrators to control who may take actions on
particular queues. They are configured with the aclSubmitApps and aclAdministerApps properties,
which can be set per queue. Currently the only supported administrative action is killing
an application. An administrator may also submit applications to it. These properties take
values in a format like "user1,user2 group1,group2" or " group1,group2". Actions on a queue
are permitted if the user/group is a member of the queue ACL or a member of the queue ACL
of any of that queue's ancestors. So if queue2 is inside queue1, and user1 is in queue1's
ACL, and user2 is in queue2's ACL, then both users may submit to queue2.
 
 **Note:** The delimiter is a space character. To specify only ACL groups, begin the value
with a space character.
 
 The root queue's ACLs are "\*" by default which, because ACLs are passed down, means that
everybody may submit to and kill applications from every queue. To start restricting access,
change the root queue's ACLs to something other than "\*".
 
+###Reservation Access Control Lists
+
+Reservation Access Control Lists (ACLs) allow administrators to control who may take reservation
actions on particular queues. They are configured with the aclAdministerReservations, aclListReservations,
and the aclSubmitReservations properties, which can be set per queue. Currently the supported
administrative actions are updating and deleting reservations. An administrator may also submit
and list *all* reservations on the queue. These properties take values in a format like "user1,user2
group1,group2" or " group1,group2". Actions on a queue are permitted if the user/group is
a member of the reservation ACL. Note that any user can update, delete, or list their own
reservations. If reservation ACLs are enabled but not defined, everyone will have access.
+
 ##Administration
 
 The fair scheduler provides support for administration at runtime through a few mechanisms:


Mime
View raw message