Change: clarify ick architecture on project, pipelines etc

1 files changed, 18 insertions, 16 deletions

diff --git a/architecture.mdwn b/architecture.mdwn
index ecad0a4..b20a23e 100644
--- a/architecture.mdwn
+++ b/architecture.mdwn
@@ -98,48 +98,50 @@ will come with libraries of pre-defined pipelines that can easily be
 reused, but it will always be possible for users to define their own.
 
 
-Ick ALPHA-1 architecture
+Ick architecture
 -----------------------------------------------------------------------------
 
 The architecture of Ick is a collection of mutually recursive
 self-modifying microservices. (That's intended to scare you off.)
 
 * A project consists of one or more pipelines to be executed when
-  triggered to do so, and some parameters given to the pipelines. Each
-  pipeline needs to be triggered individually. Each pipeline acts in
-  the same workspace. The entire pipeline is executed on the same
-  worker. All workers are considered equal (for now).
+  triggered to do so, and some parameters given to the pipelines. The
+  user (or some other entity) triggers a project, and ick will execute
+  all the pipelines (FIXME: this is not yet implemented, currently
+  each pipeline needs to be triggered individually). Each pipeline
+  acts in the same workspace. The entire pipeline is executed on the
+  same worker. All workers are considered equal (for now).
 
 * There is currently no separate workspace description. Each pipeline
-  needs to construct the workspace itself, if it needs to. (This
-  probably will change.)
+  needs to construct the workspace itself, if it needs to.
 
 * The project's pipelines do things like: prepare workspace, run
-  actual build, publish build artefacts from worker to a suitable
+  actual build, publish build artifacts from worker to a suitable
   server. The controller keeps track of where in each pipeline a
   build is.
 
-* Workers are represented by worker-managers, which request work from
+* Each worker is represented by a worker-manager, which requests work from
   the controller and perform the work by running commands locally
   (later also over ssh on the actual worker host).
 
 * Worker-builders register themselves with the controller.
 
-* A pipeline is a sequence of steps (such as shell or python snippets
-  to run), plus some parameters that the shell (or whatever) can
-  reference.
+* A pipeline is a sequence of actions (such as shell or python
+  snippets to run), plus some parameters that the shell (or whatever)
+  can reference.
 
-* If a pipeline step fails, the controller will mark the pipeline
+* If a pipeline action fails, the controller will mark the pipeline
   execution as having failed and won't schedule more steps to execute.
 
-Ick ALPHA-1 components
+
+Ick components
 -----------------------------------------------------------------------------
 
 Ick consists of several independent services. This document describes
 how they are used individually and together.
 
-* The **controller** keeps track of projects, build pipelines, workers,
-  and the current state of each. It decides which build step is next,
+* The **controller** keeps track of projects, pipelines, workers, and
+  the current state of each. It decides which build action is next,
   and who should execute it. The controller provides a simple,
   unconditional "build this pipeline" API call, to be used by the
   trigger service (see below).