You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mesos.apache.org by al...@apache.org on 2016/07/12 17:39:53 UTC

mesos git commit: Fixed typos in the docs.

Repository: mesos
Updated Branches:
  refs/heads/master 5253531a5 -> 72ec931fc


Fixed typos in the docs.

Review: https://reviews.apache.org/r/49957/


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

Branch: refs/heads/master
Commit: 72ec931fc7c8b82966974af4797ef3c002e38bf3
Parents: 5253531
Author: Neil Conway <ne...@gmail.com>
Authored: Tue Jul 12 19:17:40 2016 +0200
Committer: Alexander Rukletsov <al...@apache.org>
Committed: Tue Jul 12 19:39:31 2016 +0200

----------------------------------------------------------------------
 docs/agent-recovery.md        |  4 ++--
 docs/attributes-resources.md  |  6 +++---
 docs/configuration.md         |  2 +-
 docs/high-availability.md     |  4 ++--
 docs/mesos-containerizer.md   | 20 ++++++++++----------
 docs/monitoring.md            |  4 ++--
 docs/port-mapping-isolator.md |  6 +++---
 docs/testing-patterns.md      |  2 +-
 8 files changed, 24 insertions(+), 24 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/agent-recovery.md
----------------------------------------------------------------------
diff --git a/docs/agent-recovery.md b/docs/agent-recovery.md
index 6d1b402..1b3f2d2 100644
--- a/docs/agent-recovery.md
+++ b/docs/agent-recovery.md
@@ -55,10 +55,10 @@ Three [configuration flags](configuration.md) control the recovery behavior of a
       reconnect to the agent will self-terminate.
 
 > NOTE: If none of the frameworks have enabled checkpointing,
-> the executors and tasks running at a agent die when the agent dies
+> the executors and tasks running at an agent die when the agent dies
 > and are not recovered.
 
-A restarted agent should re-register with master within a timeout (75 seconds by default: see the `--max_agent_ping_timeouts` and `--agent_ping_timeout` [configuration flags](configuration.md)). If the agent takes longer than this timeout to re-register, the master shuts down the agent, which in turn will shutdown any live executors/tasks.  Therefore, it is highly recommended to automate the process of restarting a agent (e.g., using a process supervisor such as [monit](http://mmonit.com/monit/) or `systemd`).
+A restarted agent should re-register with master within a timeout (75 seconds by default: see the `--max_agent_ping_timeouts` and `--agent_ping_timeout` [configuration flags](configuration.md)). If the agent takes longer than this timeout to re-register, the master shuts down the agent, which in turn will shutdown any live executors/tasks. Therefore, it is highly recommended to automate the process of restarting an agent (e.g., using a process supervisor such as [monit](http://mmonit.com/monit/) or `systemd`).
 
 ## Known issues with `systemd` and process lifetime
 

http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/attributes-resources.md
----------------------------------------------------------------------
diff --git a/docs/attributes-resources.md b/docs/attributes-resources.md
index 98fabfb..2caa449 100644
--- a/docs/attributes-resources.md
+++ b/docs/attributes-resources.md
@@ -37,7 +37,7 @@ Attributes are key-value pairs (where value is optional) that Mesos passes along
 
 ## Resources
 
-Mesos can manage three different *types* of resources: scalars, ranges, and sets.  These are used to represent the different resources that a Mesos agent has to offer.  For example, a scalar resource type could be used to represent the amount of memory on a agent. Scalar resources are represented using floating point numbers to allow fractional values to be specified (e.g., "1.5 CPUs"). Mesos only supports three decimal digits of precision for scalar resources (e.g., reserving "1.5123 CPUs" is considered equivalent to reserving "1.512 CPUs"). For GPUs, Mesos only supports whole number values.
+Mesos can manage three different *types* of resources: scalars, ranges, and sets.  These are used to represent the different resources that a Mesos agent has to offer.  For example, a scalar resource type could be used to represent the amount of memory on an agent. Scalar resources are represented using floating point numbers to allow fractional values to be specified (e.g., "1.5 CPUs"). Mesos only supports three decimal digits of precision for scalar resources (e.g., reserving "1.5123 CPUs" is considered equivalent to reserving "1.512 CPUs"). For GPUs, Mesos only supports whole number values.
 
 Resources can be specified either with a JSON array or a semicolon-delimited string of key-value pairs.  If, after examining the examples below, you have questions about the format of the JSON, inspect the `Resource` protobuf message definition in `include/mesos/mesos.proto`.
 
@@ -102,11 +102,11 @@ There are several kinds of resources that have predefined behavior:
 
 Note that `disk` and `mem` resources are specified in megabytes. The master's user interface will convert resource values into a more human-readable format: for example, the value `15000` will be displayed as `14.65GB`.
 
-A agent without `cpus` and `mem` resources will not have its resources advertised to any frameworks.
+An agent without `cpus` and `mem` resources will not have its resources advertised to any frameworks.
 
 ## Examples
 
-By default, Mesos will try to autodetect the resources available at the local machine when `mesos-agent` starts up. Alternatively, you can explicitly configure which resources a agent should make available.
+By default, Mesos will try to autodetect the resources available at the local machine when `mesos-agent` starts up. Alternatively, you can explicitly configure which resources an agent should make available.
 
 Here are some examples of how to configure the resources at a Mesos agent:
 

http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/configuration.md
----------------------------------------------------------------------
diff --git a/docs/configuration.md b/docs/configuration.md
index 526308a..68bd4d3 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -680,7 +680,7 @@ conjunction with <code>--zk</code>. Must be used in conjunction with
     --max_slave_ping_timeouts=VALUE
   </td>
   <td>
-The number of times a agent can fail to respond to a
+The number of times an agent can fail to respond to a
 ping from the master. Agents that do not respond within
 <code>max_agent_ping_timeouts</code> ping retries will be asked to shutdown.
 (default: 5)

http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/high-availability.md
----------------------------------------------------------------------
diff --git a/docs/high-availability.md b/docs/high-availability.md
index e467a0e..46bd789 100644
--- a/docs/high-availability.md
+++ b/docs/high-availability.md
@@ -35,7 +35,7 @@ Refer to the [Scheduler API](app-framework-development-guide.md) for how to deal
 ## Component Disconnection Handling
 When a network partition disconnects a component (master, agent, or scheduler driver) from ZooKeeper, the component's Master Detector induces a timeout event. This notifies the component that it has no leading master. Depending on the component, the following happens. (Note that while a component is disconnected from ZooKeeper, a master may still be in communication with agents or schedulers and vice versa.)
 
-* Agents disconnected from ZooKeeper no longer know which master is the leader. They ignore messages from masters to ensure they don't act on a non-leader's decisions. When a agent reconnects to ZooKeeper, ZooKeeper informs it of the current leader and the agent stops ignoring messages from the leader.
+* Agents disconnected from ZooKeeper no longer know which master is the leader. They ignore messages from masters to ensure they don't act on a non-leader's decisions. When an agent reconnects to ZooKeeper, ZooKeeper informs it of the current leader and the agent stops ignoring messages from the leader.
 
 * Masters enter leaderless state irrespective of whether they are a leader or not before the disconnection.
 
@@ -46,7 +46,7 @@ When a network partition disconnects a component (master, agent, or scheduler dr
 
 * Scheduler drivers disconnected from the leading master notify the scheduler about their disconnection from the leader.
 
-When a network partition disconnects a agent from the leader:
+When a network partition disconnects an agent from the leader:
 
 * The agent fails health checks from the leader.
 

http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/mesos-containerizer.md
----------------------------------------------------------------------
diff --git a/docs/mesos-containerizer.md b/docs/mesos-containerizer.md
index 94144c7..7654462 100644
--- a/docs/mesos-containerizer.md
+++ b/docs/mesos-containerizer.md
@@ -137,21 +137,21 @@ The Docker Runtime isolator is used for supporting runtime
 configurations from the docker image (e.g., Entrypoint/Cmd, Env,
 etc.). This isolator is tied with `--image_providers=docker`. If
 `--image_providers` contains `docker`, this isolator must be used.
-Otherwise, agent will refuse to start.
+Otherwise, the agent will refuse to start.
 
 To enable the Docker Runtime isolator, append `docker/runtime` to the
 `--isolation` flag when starting the agent.
 
-Currently, docker image default `Entrypoint`, `Cmd`, `Env` and
-`WorkingDir` are supported with docker runtime isolator. Users can
-specify `CommandInfo` to override the default `Entrypoint` and `Cmd`
-in the image (see below for details). The `CommandInfo` should be
-inside of either `TaskInfo` or `ExecutorInfo` (depending on running
-command task or custom executor respectively).
+Currently, docker image default `Entrypoint`, `Cmd`, `Env`, and `WorkingDir` are
+supported with docker runtime isolator. Users can specify `CommandInfo` to
+override the default `Entrypoint` and `Cmd` in the image (see below for
+details). The `CommandInfo` should be inside of either `TaskInfo` or
+`ExecutorInfo` (depending on whether the task is a command task or uses a custom
+executor, respectively).
 
 #### Determine the Launch Command
 
-If user specifies a command in `CommandInfo`, that will override the
+If the user specifies a command in `CommandInfo`, that will override the
 default Entrypoint/Cmd in the docker image. Otherwise, we will use the
 default Entrypoint/Cmd and append arguments specified in `CommandInfo`
 accordingly. The details are explained in the following table.
@@ -260,14 +260,14 @@ handle 0xBBBB. You can read more about the use cases for the primary
 and secondary handles in the [Linux kernel documentation for
 net_cls](https://www.kernel.org/doc/Documentation/cgroup-v1/net_cls.txt).
 
-By default the cgroups/net_cls isolator does not manage the net_cls
+By default, the cgroups/net_cls isolator does not manage the net_cls
 handles, and assumes the operator is going to manage/assign these
 handles. To enable the management of net_cls handles by the
 cgroups/net_cls isolator you need to specify a 16-bit primary handle,
 of the form 0xAAAA, using the `--cgroups_net_cls_primary_handle` flag at
 agent startup.
 
-Once a primary handle has been specified for a agent, for each
+Once a primary handle has been specified for an agent, for each
 container the cgroups/net_cls isolator allocates a 16-bit secondary
 handle. It then assigns the 32-bit combination of the primary and
 secondary handle to the net_cls cgroup associated with the container

http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/monitoring.md
----------------------------------------------------------------------
diff --git a/docs/monitoring.md b/docs/monitoring.md
index dff337d..e19ecd0 100644
--- a/docs/monitoring.md
+++ b/docs/monitoring.md
@@ -360,7 +360,7 @@ unhealthy or that they are not able to connect to the elected master.
   <code>master/slave_shutdowns_canceled</code>
   </td>
   <td>Number of cancelled agent shutdowns. This happens when the agent removal
-      rate limit allows for a agent to reconnect and send a <code>PONG</code>
+      rate limit allows for an agent to reconnect and send a <code>PONG</code>
       to the master before being removed.</td>
   <td>Counter</td>
 </tr>
@@ -1312,7 +1312,7 @@ the agent and their current usage.
 
 #### Agent
 
-The following metrics provide information about whether a agent is currently
+The following metrics provide information about whether an agent is currently
 registered with a master and for how long it has been running.
 
 <table class="table table-striped">

http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/port-mapping-isolator.md
----------------------------------------------------------------------
diff --git a/docs/port-mapping-isolator.md b/docs/port-mapping-isolator.md
index 6a6bab9..9b9869b 100644
--- a/docs/port-mapping-isolator.md
+++ b/docs/port-mapping-isolator.md
@@ -14,7 +14,7 @@ for others. Network statistics for each active container are published
 through the
 [/monitor/statistics](endpoints/slave/monitor/statistics.md) endpoint
 on the agent. The port mapping network isolator is transparent for the
-majority of tasks running on a agent (those that bind to port 0 and
+majority of tasks running on an agent (those that bind to port 0 and
 let the kernel allocate their port).
 
 ## Installation
@@ -125,7 +125,7 @@ number of containers on the agent will therefore be limited to approximately:
     number of ephemeral_ports / ephemeral_ports_per_container
 
 The master `--max_executors_per_agent` flag is be used to prevent allocation of
-more executors on a agent when the ephemeral port range has been exhausted.
+more executors on an agent when the ephemeral port range has been exhausted.
 
 It is recommended (but not required) that `ephemeral_ports_per_container` be set
 to a power of 2 (e.g., 512, 1024) and the lower bound of the ephemeral port
@@ -296,7 +296,7 @@ for each of these elements includes:
 
 [3] Currently always reported as 0 by the underlying Traffic Control element.
 
-For example, these are the statistics you will get by hitting the `/monitor/statistics` endpoint on a agent with network monitoring turned on:
+For example, these are the statistics you will get by hitting the `/monitor/statistics` endpoint on an agent with network monitoring turned on:
 
     $ curl -s http://localhost:5051/monitor/statistics | python2.6 -mjson.tool
     [

http://git-wip-us.apache.org/repos/asf/mesos/blob/72ec931f/docs/testing-patterns.md
----------------------------------------------------------------------
diff --git a/docs/testing-patterns.md b/docs/testing-patterns.md
index df11e91..d6519f3 100644
--- a/docs/testing-patterns.md
+++ b/docs/testing-patterns.md
@@ -115,7 +115,7 @@ Future<SlaveReregisteredMessage> slaveReregisteredMessage =
 AWAIT_READY(slaveReregisteredMessage);
 ~~~
 
-However, this won't work if we want to intercept a message sent to an actor (technically a `UPID`) that lives in another OS process. For example, `CommandExecutor` spawned by a agent will live in a separate OS process, though master and agent instances live in the same OS process together with our test (see `mesos/src/tests/cluster.hpp`). The wait in this code will fail:
+However, this won't work if we want to intercept a message sent to an actor (technically a `UPID`) that lives in another OS process. For example, `CommandExecutor` spawned by an agent will live in a separate OS process, though master and agent instances live in the same OS process together with our test (see `mesos/src/tests/cluster.hpp`). The wait in this code will fail:
 
 ~~~{.cpp}
 Future<ExecutorRegisteredMessage> executorRegisteredMessage =