Change: drop trigger service for now, add artifact store

1 files changed, 18 insertions, 19 deletions

diff --git a/architecture.mdwn b/architecture.mdwn
index b20a23e..1c4f7fb 100644
--- a/architecture.mdwn
+++ b/architecture.mdwn
@@ -143,26 +143,25 @@ how they are used individually and together.
 * 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).
+  unconditional "build this project" API call, which the user can use.
 
-* A **worker-manager** represents a **build host**. It queries the
-  controller for work, and makes the build host (the actual worker)
-  execute it, and then reports results back to the controller.
+* A **worker-manager** represents and directly controls a **build
+  host**. It queries the controller for work, and executes the related
+  action on the build host, and then reports results back to the
+  controller. Results include any output (stdout, stderr) and exit
+  code.
 
-* The **trigger service** decides when a build should start. It polls
-  the state of the universe, or gets notifications of changes of the
-  same. (Trigger services don't exist for ALPHA-1. They'll be added
-  later.)
+* An **artifact store** stores individual files (which may be tar
+  files). As an example, the container system tree (see below) will be
+  stored in the artifact store.
 
-* The controller and trigger services provide an API. The **identity
+* The controller and artifact store provide an API. The **identity
   provider** (IDP) takes care of the authentication of each API
   client, and what privileges each should have. The API client
   authenticates itself to the IDP, and receives an access token. The
-  API provider gets the token in each request, validates it, and
-  inspects it to see what the client is allowed to do. (There is no
-  IDP for ALPHA-1. Each API client generates its own access tokens.
-  This will change later.)
+  client includes the access token with each call to an API, the API
+  provider validates the token, and inspects it to see what the client
+  is allowed to do. (FIXME: this is not yet implemented)
 
 On an implementation level, the various services of Ick may be
 implemented using any language and framework that works. However, to
@@ -175,13 +174,13 @@ backend.
     @startuml
     title Ick services
 
-    [git server] --> [trigger service] : notify of change
-    [trigger service] --> [controller] : start pipeline
+    [git server] --> [controller] : trigger build
     [controller] <-- [worker manager] : get work, report result
     [worker manager] --> [host] : execute command
-    [git server] --> [IDP] : get access token
-    [trigger service] .. [IDP] : get access token
-    [worker manager] .. [IDP] : get access token
+    [worker manager] --> [controller] : report results
+    [worker manager] --> [IDP] : get access token
+    [worker manager] --> [artifact store] : upload blob
+    [artifact store] --> [worker manager] : upload blob
     @enduml
 
 The API providing services will be running in a configuration like