From 1d17b2bde2da902418681f9d0d7d5c0f2d19c825 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Tue, 22 Apr 2014 14:03:26 +0000 Subject: Remove implementation plan from ARCH Things have been implemented, no need for the plan anymore. --- ARCH | 72 -------------------------------------------------------------------- 1 file changed, 72 deletions(-) (limited to 'ARCH') 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. -- cgit v1.2.1