Remove implementation plan from ARCH

Things have been implemented, no need for the plan anymore.

1 files changed, 0 insertions, 72 deletions

diff --git a/ARCH b/ARCH
index c1cb979..d6199bf 100644
--- a/ARCH
+++ b/ARCH
@@ -339,75 +339,3 @@ WEBAPP knows about. It has the following columns:
   Lorry when a job is run.
 * `generated` is set to 0 or 1, depending on if the Lorry came from an
   actual `.lorry` file or was generated by Lorry Controller.
-
-Implementation plan
-===================
-
-The following are meant to be a good sequence of steps to implement
-the design as described above.
-
-*   Make a skeleton Lorry Controller and yarn test suite for it (2d)
-
-    Write a simplistic, skeleton of a Lorry Controller WEBAPP and MINION,
-    and a few representative tests for them using yarn. The goal here is
-    not to have applications that do something real, or tests that test
-    something real, but to have a base upon which to start building, and
-    especially to make it easy to write tests (including new step
-    implementations) easily in the future.
-
-*   Implement /1.0/status and /1.0/status-html in Lorry Controller
-    WEBAPP (1d)
-
-    This is the very basic, core of the status reporting. Every
-    subsequent change will include updating the status reporting as
-    necessary.
-
-*   Implement /1.0/status/disk-free-bytes in Lorry Controller WEBAPP (1d)
-
-*   Implement /1.0/stop-queue and /1.0/start-queue in Lorry Controller
-    WEBAPP (1d)
-
-    This should just affect the bit in STATEDB that decides whether we
-    are currently running jobs from the run queue or not. This
-    implementation step does not need to actually implement running
-    jobs.
-
-*   Implement /1.0/read-configuration and /1.0/list-queue in Lorry
-    Controller WEBAPP (3d) (S10450)
-
-    This requires implementing parsing of the configuration files in
-    CONFGIT, generation of Lorry specs from Trove specs,
-    adding/removing/updating specs in the run queue according to
-    changes. list-queue needs to be implemented so that the results of
-    read-configuration can be verified.
-
-*   Implement running jobs in Lorry Controller WEBAPP (1d) (S10451)
-
-    Requests /1.0/give-me-job, /1.0/job-update,
-    /1.0/list-running-jobs, /1.0/stop-job/. These do not actually run
-    anything, of course, since that is a job for MINION, but they
-    change the state of the job in STATEDB, and that's what needs to
-    be implemented and tested.
-
-*   Implement MINION in Lorry Controller (1d) (S10452)
-
-*   Implement /1.0/move-to-top/ and /1.0/move-to-bottom/ in Lorry
-    Controller WEBAPP (1d) (S10453)
-
-*   Implement /1.0/list-all-jobs, /1.0/job/ in Lorry Controller
-    WEBAPP (1d) (S10454)
-
-*   Implement /1.0/lorry/ in Lorry Controller WEBAPP (1d) (S10455)
-
-*   Add new Lorry Controller to Trove (2d) (S10456)
-
-    Replace old Lorry Controller with new one, and add any systemd
-    units needed to make it functional. Create at least a very basic
-    sanity check, using yarn, to verify that a deployed, running
-    system has a working Lorry Controller.
-
-*   Review Lorry Controller situation and decide on further work
-
-    No implementation plan survives contact with reality, and thus
-    things will need to be reviewed at the end, in case something has
-    been forgotten or requirements have changed.