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:37 GMT
Repository: hadoop
Updated Branches:
  refs/heads/branch-2.8 90adda5da -> deef54b26


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

(cherry picked from commit 500e5a5952f8f34bf0e1e2653fa01b357d68cc8f)


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

Branch: refs/heads/branch-2.8
Commit: deef54b2619e28e7e2199e1f4ebda269a30cba7d
Parents: 90adda5
Author: Masatake Iwasaki <iwasakims@apache.org>
Authored: Wed Apr 6 04:00:31 2016 +0900
Committer: Masatake Iwasaki <iwasakims@apache.org>
Committed: Wed Apr 6 04:01:48 2016 +0900

----------------------------------------------------------------------
 .../src/site/markdown/CapacityScheduler.md                | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/hadoop/blob/deef54b2/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 e86c4f9..8c0b8c8 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
@@ -55,11 +55,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.
 
@@ -67,9 +67,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.
 
@@ -163,7 +163,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