readme
authorThierry Parmentelat <thierry.parmentelat@sophia.inria.fr>
Tue, 20 Sep 2011 09:09:22 +0000 (11:09 +0200)
committerThierry Parmentelat <thierry.parmentelat@sophia.inria.fr>
Tue, 20 Sep 2011 09:09:22 +0000 (11:09 +0200)
system/Substrate.readme [new file with mode: 0644]

diff --git a/system/Substrate.readme b/system/Substrate.readme
new file mode 100644 (file)
index 0000000..1698d70
--- /dev/null
@@ -0,0 +1,45 @@
+This is a rewrite of TestResources
+
+Like for TestResources, this expects that you install in /root/LocalSubstrate.py a definition of your local hardware and related IP pools; see LocalSubstrate.inria.py for an example
+
+it takes care of everything that has to do with provisioning a test on the local substrate
+it can handle multiple vserver-ready PLC boxes
+it can handle multiple qemu/kvm-ready QEMU boxes
+Each of these is declared with a maximum number of instances
+
+You should make sure that your substrate can at least hold all the nightly tests, so you can inspect stuff right away the following day 
+
+Also you can use 'run' manually in a given test directory (/root/<buildname>) 
+This is safe as long as you make sure to not restart a running plc or node; 
+trying to start the plc again is rather harmless, as vserver <> start will fail
+OTOH running qemu_start again will probably run another qemu instance, and things can get messy
+
+You can monitor the status of the local substrate by running your LocalSubstrate.py 
+this would sense the local substrate and display its status
+this is a replacement for a former script named manage-infrastructure.py that was local to onelab 
+although it does not support hard/soft rebooting of the underlying plc/qemu boxes yet
+
+This implementation is tracker-less; mostly everything is sensed using pings/ssh/ps or whatever;
+however there's a shared file named /root/starting that's used to inform concurrent test instances about the IP addresses that were assigned but not yet started; 
+when all the tests are over this file should be empty
+
+---
+
+The inria sample gives an example, with currently
+(*) 3 build boxes (one per fedora flavour)
+(*) 1 PLC box that can host 20 myplcs
+(*) 6 QEMU boxes that can host 3 nodes each
+
+What we do in the nightlies is to run in parallel on all 3 boxes
+. a 32bits build, with a single myplc (and so a single node) 
+. a 64bits build with a triangle setup (3 plcs and 3 nodes)
+
+this means we have 
+(*) at around midnight, 3 single-myplc builds in parallel
+    this uses 3 myplcs and 3 nodes
+(*) at around 1, 3 triangle-myplc builds in parallel
+    this in turn uses 9 myplcs and 9 nodes
+
+so the substrate can basically hold builds from one day and a half...
+
+---