hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From iwasak...@apache.org
Subject hadoop git commit: YARN-4917. Fix typos in documentation of Capacity Scheduler. (Takashi Ohnishi via iwasakims)
Date Tue, 05 Apr 2016 19:03:54 GMT
Repository: hadoop
Updated Branches:
  refs/heads/branch-2.7 6576fc6cc -> 76e0bb7a1


YARN-4917. Fix typos in documentation of Capacity Scheduler. (Takashi Ohnishi via iwasakims)


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

Branch: refs/heads/branch-2.7
Commit: 76e0bb7a19fbd2c4638a75fc44b4e731e7d536eb
Parents: 6576fc6
Author: Masatake Iwasaki <iwasakims@apache.org>
Authored: Wed Apr 6 04:03:01 2016 +0900
Committer: Masatake Iwasaki <iwasakims@apache.org>
Committed: Wed Apr 6 04:03:01 2016 +0900

----------------------------------------------------------------------
 hadoop-yarn-project/CHANGES.txt                           |  3 +++
 .../src/site/markdown/CapacityScheduler.md                | 10 +++++-----
 2 files changed, 8 insertions(+), 5 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/hadoop/blob/76e0bb7a/hadoop-yarn-project/CHANGES.txt
----------------------------------------------------------------------
diff --git a/hadoop-yarn-project/CHANGES.txt b/hadoop-yarn-project/CHANGES.txt
index 3f0bcaf..03621ac 100644
--- a/hadoop-yarn-project/CHANGES.txt
+++ b/hadoop-yarn-project/CHANGES.txt
@@ -121,6 +121,9 @@ Release 2.7.3 - UNRELEASED
     YARN-4915. Fix typo in YARN Secure Containers documentation
     (Takashi Ohnishi via iwasakims)
 
+    YARN-4917. Fix typos in documentation of Capacity Scheduler.
+    (Takashi Ohnishi via iwasakims)
+
 Release 2.7.2 - 2016-01-25
 
   INCOMPATIBLE CHANGES

http://git-wip-us.apache.org/repos/asf/hadoop/blob/76e0bb7a/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 7b19acd..9d170bb 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
@@ -54,11 +54,11 @@ The `CapacityScheduler` supports the following features:
 
 * **Hierarchical Queues** - Hierarchy of queues is supported to ensure resources are shared
among the sub-queues of an organization before other queues are allowed to use free resources,
there-by providing more control and predictability.
 
-* **Capacity Guarantees** - Queues are allocated a fraction of the capacity of the grid in
the sense that a certain capacity of resources will be at their disposal. All applications
submitted to a queue will have access to the capacity allocated to the queue. Adminstrators
can configure soft limits and optional hard limits on the capacity allocated to each queue.
+* **Capacity Guarantees** - Queues are allocated a fraction of the capacity of the grid in
the sense that a certain capacity of resources will be at their disposal. All applications
submitted to a queue will have access to the capacity allocated to the queue. Administrators
can configure soft limits and optional hard limits on the capacity allocated to each queue.
 
 * **Security** - Each queue has strict ACLs which controls which users can submit applications
to individual queues. Also, there are safe-guards to ensure that users cannot view and/or
modify applications from other users. Also, per-queue and system administrator roles are supported.
 
-* **Elasticity** - Free resources can be allocated to any queue beyond its capacity. When
there is demand for these resources from queues running below capacity at a future point in
time, as tasks scheduled on these resources complete, they will be assigned to applications
on queues running below the capacity (pre-emption is also supported). This ensures that resources
are available in a predictable and elastic manner to queues, thus preventing artifical silos
of resources in the cluster which helps utilization.
+* **Elasticity** - Free resources can be allocated to any queue beyond its capacity. When
there is demand for these resources from queues running below capacity at a future point in
time, as tasks scheduled on these resources complete, they will be assigned to applications
on queues running below the capacity (pre-emption is also supported). This ensures that resources
are available in a predictable and elastic manner to queues, thus preventing artificial silos
of resources in the cluster which helps utilization.
 
 * **Multi-tenancy** - Comprehensive set of limits are provided to prevent a single application,
user and queue from monopolizing resources of the queue or the cluster as a whole to ensure
that the cluster isn't overwhelmed.
 
@@ -66,9 +66,9 @@ The `CapacityScheduler` supports the following features:
 
     * Runtime Configuration - The queue definitions and properties such as capacity, ACLs
can be changed, at runtime, by administrators in a secure manner to minimize disruption to
users. Also, a console is provided for users and administrators to view current allocation
of resources to various queues in the system. Administrators can *add additional queues* at
runtime, but queues cannot be *deleted* at runtime.
 
-    * Drain applications - Administrators can *stop* queues at runtime to ensure that while
existing applications run to completion, no new applications can be submitted. If a queue
is in `STOPPED` state, new applications cannot be submitted to *itself* or *any of its child
queueus*. Existing applications continue to completion, thus the queue can be *drained* gracefully.
Administrators can also *start* the stopped queues.
+    * Drain applications - Administrators can *stop* queues at runtime to ensure that while
existing applications run to completion, no new applications can be submitted. If a queue
is in `STOPPED` state, new applications cannot be submitted to *itself* or *any of its child
queues*. Existing applications continue to completion, thus the queue can be *drained* gracefully.
Administrators can also *start* the stopped queues.
 
-* **Resource-based Scheduling** - Support for resource-intensive applications, where-in a
application can optionally specify higher resource-requirements than the default, there-by
accomodating applications with differing resource requirements. Currently, *memory* is the
resource requirement supported.
+* **Resource-based Scheduling** - Support for resource-intensive applications, where-in a
application can optionally specify higher resource-requirements than the default, there-by
accommodating applications with differing resource requirements. Currently, *memory* is the
resource requirement supported.
 
 * **Queue Mapping based on User or Group** - This feature allows users to map a job to a
specific queue based on the user or group.
 
@@ -160,7 +160,7 @@ Configuration
 
 | Property | Description |
 |:---- |:---- |
-| `yarn.scheduler.capacity.queue-mappings` | This configuration specifies the mapping of
user or group to aspecific queue. You can map a single user or a list of users to queues.
Syntax: `[u or g]:[name]:[queue_name][,next_mapping]*`. Here, *u or g* indicates whether the
mapping is for a user or group. The value is *u* for user and *g* for group. *name* indicates
the user name or group name. To specify the user who has submitted the application, %user
can be used. *queue_name* indicates the queue name for which the application has to be mapped.
To specify queue name same as user name, *%user* can be used. To specify queue name same as
the name of the primary group for which the user belongs to, *%primary_group* can be used.|
+| `yarn.scheduler.capacity.queue-mappings` | This configuration specifies the mapping of
user or group to a specific queue. You can map a single user or a list of users to queues.
Syntax: `[u or g]:[name]:[queue_name][,next_mapping]*`. Here, *u or g* indicates whether the
mapping is for a user or group. The value is *u* for user and *g* for group. *name* indicates
the user name or group name. To specify the user who has submitted the application, %user
can be used. *queue_name* indicates the queue name for which the application has to be mapped.
To specify queue name same as user name, *%user* can be used. To specify queue name same as
the name of the primary group for which the user belongs to, *%primary_group* can be used.|
 | `yarn.scheduler.capacity.queue-mappings-override.enable` | This function is used to specify
whether the user specified queues can be overridden. This is a Boolean value and the default
value is *false*. |
 
 Example:


Mime
View raw message