Remove IterateAllocSane test

The test is testing for a property that just isn't true. Iterated
allocation greedily place one instance at a time taking the locally
most balanced solution. Then it is tested whether the resulting global
allocation can be improved.

To see that this assumption does not hold, consider placing 3
identical instances on 3 nodes. The most balanced allocation of all 3
instances would be that each node is primary and secondary for one
instance. Now let's see what iterative allocation does.

Up to symmetry, the placing of the first instance is unique. Any
placement of the second instance that keeps the way to the global
optimum open would be one node being primary and secondary for one
instance each, one node being only secondary for instance, and one
node being only primary for one instance. An alternative allocation
would be to place the instances on two different nodes as primaries
and using the third node as shared secondary.

For cpu (2 nodes with 1 cpu, 1 with none), free memory (on two nodes
all minus 1 unit, on one node all), and disk (2 nodes with 1 disk, 1
with 2) there is no difference between these allocations. For reserved
memory, there's a difference in the values. In the first case, on two nodes,
there's one unit reserved and nothing on the third. In the second
case, on two nodes, there is nothing reserved, while on the third
node, there still is only one unit reserved, as the two instances have
different primaries. Nevertheless, the standard deviations of
0,0,1 and 1,1,0 are both sqrt(5/9); so, in everything that contributes
to the balancedness metric these allocations are equal. Therefore, it is
locally correct to chose the wrong allocation.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Thomas Thrainer <thomasth@google.com>

diff --git a/test/hs/Test/Ganeti/HTools/Cluster.hs b/test/hs/Test/Ganeti/HTools/Cluster.hs
index 75525b4..7b34c3c 100644 (file)
--- a/test/hs/Test/Ganeti/HTools/Cluster.hs
+++ b/test/hs/Test/Ganeti/HTools/Cluster.hs
@@ -148,41 +148,6 @@ prop_Alloc_sane inst =
                 printTestCase "Solution score differs from actual node list:"
                   (Cluster.compCV xnl ==? cv)
 
--- | Check that multiple instances can allocated correctly, without
--- rebalances needed.
-prop_IterateAlloc_sane :: Instance.Instance -> Property
-prop_IterateAlloc_sane inst =
-  forAll (choose (5, 10)) $ \count ->
-  forAll genOnlineNode $ \node ->
-  forAll (choose (2, 5)) $ \limit ->
-  let (nl, il, inst') = makeSmallEmptyCluster node count inst
-      reqnodes = Instance.requiredNodes $ Instance.diskTemplate inst
-      allocnodes = Cluster.genAllocNodes defGroupList nl reqnodes True
-  in case allocnodes >>= \allocnodes' ->
-     Cluster.iterateAlloc nl il (Just limit) inst' allocnodes' [] [] of
-       Bad msg -> failTest msg
-       Ok (_, xnl, xil, _, _) ->
-         let old_score = Cluster.compCV xnl
-             tbl = Cluster.Table xnl xil old_score []
-         in case Cluster.tryBalance tbl True True False 0 1e-4 of
-              Nothing -> passTest
-              Just (Cluster.Table ynl _ new_score plcs) ->
-                -- note that with a "min_gain" of zero, sometime
-                -- rounding errors can trigger a rebalance that
-                -- improves the score by e.g. 2e-14; in order to
-                -- prevent such no-real-change moves from happening,
-                -- we check for a min-gain of 1e-9
-                -- FIXME: correct rebalancing to not do no-ops
-                printTestCase
-                  ("Cluster can be balanced after allocation\n" ++
-                   " old cluster (score " ++ show old_score ++
-                   "):\n" ++ Cluster.printNodes xnl [] ++
-                   " new cluster (score " ++ show new_score ++
-                   "):\n" ++ Cluster.printNodes ynl [] ++
-                   "placements:\n" ++ show plcs ++ "\nscore delta: " ++
-                   show (old_score - new_score))
-                  (old_score - new_score < 1e-9)
-
 -- | Checks that on a 2-5 node cluster, we can allocate a random
 -- instance spec via tiered allocation (whatever the original instance
 -- spec), on either one or two nodes. Furthermore, we test that