From 4634a4b7034deaf3e08f1e3be623a5874a5a6ca1 Mon Sep 17 00:00:00 2001 From: ankurshukla Date: Fri, 23 Sep 2016 12:50:42 -0700 Subject: [PATCH] added Nuage Network to partner section Signed-off-by: YuPengZTE --- docs/user-guide/jobs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index 59e09e7bcd..a6baa6223f 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -238,11 +238,11 @@ considering one set of work items that the user wants to manage together — There are several different patterns for parallel computation, each with strengths and weaknesses. The tradeoffs are: -- One Job object for each work item, vs a single Job object for all work items. The latter is +- One Job object for each work item, vs. a single Job object for all work items. The latter is better for large numbers of work items. The former creates some overhead for the user and for the system to manage large numbers of Job objects. Also, with the latter, the resource usage of the job (number of concurrently running pods) can be easily adjusted using the `kubectl scale` command. -- Number of pods created equals number of work items, vs each pod can process multiple work items. +- Number of pods created equals number of work items, vs. each pod can process multiple work items. The former typically requires less modification to existing code and containers. The latter is better for large numbers of work items, for similar reasons to the previous bullet. - Several approaches use a work queue. This requires running a queue service,