1 files changed, 76 insertions, 0 deletions
diff --git a/yarns.webapp/050-troves.yarn b/yarns.webapp/050-troves.yarn
new file mode 100644
index 0000000..8737306
--- /dev/null
+++ b/yarns.webapp/050-troves.yarn
@@ -0,0 +1,76 @@
+Handling of remote Troves
+=========================
+
+This chapter has tests for WEBAPP's handling of remote Troves: getting
+the listing of repositories to mirror from the Trove, and creating
+entries in the run-queue for them.
+
+
+Reading a remote Trove specification from CONFGIT
+-------------------------------------------------
+
+When there's a `troves` section in the Lorry Controller configuration
+file, the WEBAPP should include that in the list of Troves when
+reported.
+
+    SCENARIO a Trove is listed in CONFGIT
+    GIVEN a new git repository in CONFGIT
+    AND an empty lorry-controller.conf in CONFGIT
+    AND WEBAPP uses CONFGIT as its configuration directory
+
+Note that we need to fake a remote Trove, using static files, to keep
+test setup simpler.
+
+    AND WEBAPP fakes Trove example-trove
+    AND a running WEBAPP
+
+Initially WEBAPP should report no known Troves, and have an empty
+run-queue.
+
+    WHEN admin makes request GET /1.0/status
+    THEN response has run_queue set to []
+    AND response has troves set to []
+
+Let's add a `troves` section to the configuration file. After WEBAPP
+reads that, it should list the added Trove in status.
+
+    GIVEN lorry-controller.conf in CONFGIT adds trove example-trove
+    AND lorry-controller.conf in CONFGIT has prefixmap example:example for example-trove
+    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    AND admin makes request GET /1.0/status
+    THEN response has troves item 0 field trovehost set to "example-trove"
+
+However, this should not have made WEBAPP to fetch a new list of
+repositories from the remote Trove.
+
+    AND response has run_queue set to []
+
+If we tell WEBAPP to fetch the list, we should see repositories.
+
+    GIVEN remote Trove example-trove has repository example/foo
+    WHEN admin makes request POST /1.0/ls-troves with dummy=value
+    AND admin makes request GET /1.0/list-queue
+    THEN response has queue set to ["example/foo"]
+
+If we re-read the configuration again, without any changes to it or to
+the fake Trove's repository list, the same Troves and Lorry specs
+should remain in STATEDB. (It wasn't always thus, due to a bug.)
+
+    WHEN admin makes request POST /1.0/read-configuration with dummy=value
+    AND admin makes request GET /1.0/status
+    THEN response has troves item 0 field trovehost set to "example-trove"
+    WHEN admin makes request GET /1.0/list-queue
+    THEN response has queue set to ["example/foo"]
+
+If the Trove deletes a repository, we should still keep it locally, to
+avoid disasters. However, it will be removed from the Trove's STATEDB,
+and it won't be lorried anymore.
+
+    GIVEN remote Trove example-trove doesn't have repository example/foo
+    WHEN admin makes request POST /1.0/ls-troves with dummy=value
+    AND admin makes request GET /1.0/list-queue
+    THEN response has queue set to []
+
+Cleanup.
+
+    FINALLY WEBAPP terminates