From ac8827ced59960f3f28be406e28ed46486fa167e Mon Sep 17 00:00:00 2001 From: Pierre Tardy Date: Sat, 25 Jun 2016 19:24:53 +0200 Subject: [PATCH] fix spelling mistakes --- master/docs/manual/concepts.rst | 8 ++++---- master/docs/spelling_wordlist.txt | 10 ++++++++++ 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/master/docs/manual/concepts.rst b/master/docs/manual/concepts.rst index d0d1847a429..3a3bf5273e4 100644 --- a/master/docs/manual/concepts.rst +++ b/master/docs/manual/concepts.rst @@ -650,9 +650,9 @@ see :ref:`wamp ` There are then several strategy for introducing multimaster in your buildbot infra. A simple way to say it is by adding the concept of symetrics and asymetrics multimaster (like there is SMP and AMP for multi core CPUs) -Symetric multimaster is when each master share the exact same configuration. They run the same builders, same schedulers, same everything, the only difference is that workers are connected evenly between the masters (by any means (e.g. DNS loadbalancing, etc)) Symetric multimaster is good to use to scale buildbot horizontally. +Symetric multimaster is when each master share the exact same configuration. They run the same builders, same schedulers, same everything, the only difference is that workers are connected evenly between the masters (by any means (e.g. DNS load balancing, etc)) Symetric multimaster is good to use to scale buildbot horizontally. -Asymetric multimaster is when each master have different configuration. Each master may have a specific responsability (e.g schedulers, set of builder, UI). This was more how you did in 0.8, also because of its own technical limitations. A nice feature of asymetric multimaster is that you can have the UI only handled by some masters. +Asymetric multimaster is when each master have different configuration. Each master may have a specific responsibility (e.g schedulers, set of builder, UI). This was more how you did in 0.8, also because of its own technical limitations. A nice feature of asymetric multimaster is that you can have the UI only handled by some masters. Separating the UI from the controlling will greatly help in the performance of the UI, because badly written BuildSteps?? can stall the reactor for several seconds. @@ -661,7 +661,7 @@ You would scale the number of UI master according to your number of UI users, an Depending on your workload and size of master host, it is probably a good idea to start thinking of multimaster starting from a hundred workers connected. -Multimaster can also be used for high availibility, and seemless upgrade of configuration code. +Multimaster can also be used for high availability, and seamless upgrade of configuration code. Complex configuration indeed requires sometimes to restart the master to reload custom steps or code, or just to upgrade the upstream buildbot version. In this case, you will implement following procedure: @@ -669,7 +669,7 @@ In this case, you will implement following procedure: * Start new master(s) with new code and configuration. * Send a graceful shutdown to the old master(s). * New master(s) will start taking the new jobs, while old master(s) will just finish managing the running builds. -* As an old master is finishing the running builds, it will drop the connections from the workers, who will then reconnect automatically, and by the mean of loadbalancer will get connected to a new master to run new jobs. +* As an old master is finishing the running builds, it will drop the connections from the workers, who will then reconnect automatically, and by the mean of load balancer will get connected to a new master to run new jobs. As buildbot nine has been designed to allow such procedure, it has not been implemented in production yet as we know. There is probably a new REST api needed in order to graceful shutdown a master, and the details of gracefully dropping the connection to the workers to be sorted out. diff --git a/master/docs/spelling_wordlist.txt b/master/docs/spelling_wordlist.txt index 4b38f36b3d6..fa7e62070f0 100644 --- a/master/docs/spelling_wordlist.txt +++ b/master/docs/spelling_wordlist.txt @@ -30,6 +30,11 @@ arguent argv ascii Async +asymetrics +Asymetric +Asymetric +asymetric +Async Atlassian attricutes attrs @@ -393,6 +398,7 @@ internet ini intialization intialized +io ip IProperties iptables @@ -496,6 +502,7 @@ multi Multi multiline Multimaster +multimaster munge mutualisation mv @@ -766,6 +773,9 @@ SVN svnmailer svnurl symlinks +symetric +Symetric +symetrics synchronisation synchronise Synchronise