Rename zuul-launcher to zuul-executor
To avoid confusion with nodepool-launcher, we've decided to rename
zuul-launcher to zuul-executor.
Change-Id: I7d03cf0f0093400f4ba2e4beb1c92694224a3e8c
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
diff --git a/doc/source/launchers.rst b/doc/source/executors.rst
similarity index 97%
rename from doc/source/launchers.rst
rename to doc/source/executors.rst
index c9dbd99..5f85f58 100644
--- a/doc/source/launchers.rst
+++ b/doc/source/executors.rst
@@ -1,4 +1,4 @@
-:title: Launchers
+:title: Executors
.. _Gearman: http://gearman.org/
@@ -11,27 +11,27 @@
.. _`Turbo-Hipster Documentation`:
http://turbo-hipster.rtfd.org/
-.. _launchers:
+.. _executors:
-Launchers
+Executors
=========
-Zuul has a modular architecture for launching jobs. Currently, the
+Zuul has a modular architecture for executing jobs. Currently, the
only supported module interfaces with Gearman_. This design allows
any system to run jobs for Zuul simply by interfacing with a Gearman
server. The recommended way of integrating a new job-runner with Zuul
is via this method.
-If Gearman is unsuitable, Zuul may be extended with a new launcher
+If Gearman is unsuitable, Zuul may be extended with a new executor
module. Zuul makes very few assumptions about the interface to a
-launcher -- if it can trigger jobs, cancel them, and receive success
+executor -- if it can trigger jobs, cancel them, and receive success
or failure reports, it should be able to be used with Zuul. Patches
to this effect are welcome.
Zuul Parameters
---------------
-Zuul will pass some parameters with every job it launches. These are
+Zuul will pass some parameters with every job it executes. These are
for workers to be able to get the repositories into the state they are
intended to be tested in. Builds can be triggered either by an action
on a change or by a reference update. Both events share a common set
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 784fc4d..3f903db 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -21,7 +21,7 @@
zuul
merger
cloner
- launchers
+ executors
statsd
client
developer
diff --git a/doc/source/merger.rst b/doc/source/merger.rst
index 82e204b..d8de702 100644
--- a/doc/source/merger.rst
+++ b/doc/source/merger.rst
@@ -30,7 +30,7 @@
Git reference of the form ``refs/zuul/<branch>/Z<random sha1>``.
Preparing the workspace is then a simple matter of fetching that ref
and checking it out. The parameters that provide this information are
-described in :ref:`launchers`.
+described in :ref:`executors`.
These references need to be made available via a Git repository that
is available to workers (such as Jenkins). This is accomplished by
diff --git a/doc/source/quick-start.rst b/doc/source/quick-start.rst
index 82779c6..6d16c92 100644
--- a/doc/source/quick-start.rst
+++ b/doc/source/quick-start.rst
@@ -19,7 +19,7 @@
Zuul provides the following components:
- **zuul-server**: scheduler daemon which communicates with Gerrit and
- Gearman. Handles receiving events, launching jobs, collecting results
+ Gearman. Handles receiving events, executing jobs, collecting results
and postingreports.
- **zuul-merger**: speculative-merger which communicates with Gearman.
Prepares Git repositories for jobs to test against. This additionally
diff --git a/doc/source/statsd.rst b/doc/source/statsd.rst
index b3bf99f..fb6989e 100644
--- a/doc/source/statsd.rst
+++ b/doc/source/statsd.rst
@@ -17,7 +17,7 @@
The configuration is done via environment variables STATSD_HOST and
STATSD_PORT. They are interpreted by the statsd module directly and there is no
such parameter in zuul.conf yet. Your init script will have to initialize both
-of them before launching Zuul.
+of them before executing Zuul.
Your init script most probably loads a configuration file named
``/etc/default/zuul`` which would contain the environment variables::
@@ -61,7 +61,7 @@
#. **job.<jobname>** subtree detailing per job statistics:
#. **wait_time** counter and timer of the wait time, with the
- difference of the job start time and the launch time, in
+ difference of the job start time and the execute time, in
milliseconds.
**zuul.pipeline.**
@@ -88,7 +88,7 @@
#. **total_changes** counter of the number of change proceeding since
Zuul started.
#. **wait_time** counter and timer of the wait time, with the difference
- of the job start time and the launch time, in milliseconds.
+ of the job start time and the execute time, in milliseconds.
Additionally, the `zuul.pipeline.<pipeline name>` hierarchy contains
`current_changes` (gauge), `resident_time` (timing) and `total_changes`
diff --git a/doc/source/zuul.rst b/doc/source/zuul.rst
index 4f43596..8b325ba 100644
--- a/doc/source/zuul.rst
+++ b/doc/source/zuul.rst
@@ -635,9 +635,9 @@
**hold-following-changes (optional)**
This is a boolean that indicates that changes that follow this
change in a dependent change pipeline should wait until this job
- succeeds before launching. If this is applied to a very short job
+ succeeds before executing. If this is applied to a very short job
that can predict whether longer jobs will fail early, this can be
- used to reduce the number of jobs that Zuul will launch and
+ used to reduce the number of jobs that Zuul will execute and
ultimately have to cancel. In that case, a small amount of
parallelization of jobs is traded for more efficient use of testing
resources. On the other hand, to apply this to a long running job
@@ -709,7 +709,7 @@
a job is voting or not. Default: ``true``.
**attempts (optional)**
- Number of attempts zuul will launch a job. Once reached, zuul will report
+ Number of attempts zuul will execute a job. Once reached, zuul will report
RETRY_LIMIT as the job result.
Defaults to 3.