Repository: mesos
Updated Branches:
  refs/heads/master b29ec4f11 -> 6e00eddfc


Use character entity references instead of angle brackets

Fixes https://issues.apache.org/jira/browse/MESOS-2237

This closes: #71
Review: https://github.com/apache/mesos/pull/71


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

Branch: refs/heads/master
Commit: 6e00eddfc3af929887ae7f241810795c0984e5df
Parents: b29ec4f
Author: Elsmore <[email protected]>
Authored: Fri Oct 9 15:31:17 2015 +0100
Committer: Dave Lester <[email protected]>
Committed: Fri Oct 9 15:31:17 2015 +0100

----------------------------------------------------------------------
 docs/architecture.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/mesos/blob/6e00eddf/docs/architecture.md
----------------------------------------------------------------------
diff --git a/docs/architecture.md b/docs/architecture.md
index 439a56d..92538b7 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -8,7 +8,7 @@ layout: documentation
 
 The above figure shows the main components of Mesos.  Mesos consists of a 
*master* daemon that manages *slave* daemons running on each cluster node, and 
*mesos applications* (also called *frameworks*) that run *tasks* on these 
slaves.
 
-The master enables fine-grained sharing of resources (cpu, ram, ...) across 
applications by making them *resource offers*. Each resource offer contains a 
list of <slave ID, resource1: amount1, resource2, amount2, ...>.  The master 
decides *how many* resources to offer to each framework according to a given 
organizational policy, such as fair sharing, or strict priority. To support a 
diverse set of policies, the master employs a modular architecture that makes 
it easy to add new allocation modules via a plugin mechanism.
+The master enables fine-grained sharing of resources (cpu, ram, ...) across 
applications by making them *resource offers*. Each resource offer contains a 
list of &lt;slave ID, resource1: amount1, resource2, amount2, ...&gt;.  The 
master decides *how many* resources to offer to each framework according to a 
given organizational policy, such as fair sharing, or strict priority. To 
support a diverse set of policies, the master employs a modular architecture 
that makes it easy to add new allocation modules via a plugin mechanism.
 
 A framework running on top of Mesos consists of two components: a *scheduler* 
that registers with the master to be offered resources, and an *executor* 
process that is launched on slave nodes to run the framework's tasks (see the 
[App/Framework development guide](app-framework-development-guide.md) for more 
details about application schedulers and executors). While the master 
determines **how many** resources are offered to each framework, the 
frameworks' schedulers select **which** of the offered resources to use. When a 
frameworks accepts offered resources, it passes to Mesos a description of the 
tasks it wants to run on them. In turn, Mesos launches the tasks on the 
corresponding slaves.
 

Reply via email to