GitLab

...so that it can be used outside the filter test as well.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

In tests, give Ganeti enough time to actually start up jobs before
asserting that they succeed. While normally forking and executing
a job is finished in less than a second in some circumstances it
can take longer; so give enough time to avoid flaky tests.

While there, also pause the watcher, so that it doesn't submit
jobs inbetween that cause our 0.01 second delay jobs to take
longer while waiting for locks taken by the watcher's jobs.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

This test verifies a global limit on the number of jobs running. This
requires knowledge of all jobs submitted between the addition of the
filter and the submission of our last test job. While we send these
commands directly one after the other, this still takes a second or
two, thus giving the watcher slightly less than a 1% change of
interfering. Avoid this by pausing the watcher during this test.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

The test submits 3 jobs in an environment rate-limited to two, and verifies
that the first 2 jobs are running whereas the third one remains queued. However,
it takes for Ganeti some time to get a submitted job to actually being confirmed
waiting (in some circumstances over a second). So wait a bit longer to avoid
losing the race. While there, increase the time of the delay jobs to avoid
them finishing during that test in an extremely slowly running QA. (Note that
the jobs are killed forcefully at the end of the test, so that time is never
really waited for.)
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

The test submits 3 jobs in an environment rate-limited to two, and verifies
that the first 2 jobs are running whereas the third one remains queued. However,
it takes for Ganeti some time to get a submitted job to actually being confirmed
waiting (in some circumstances over a second). So wait a bit longer to avoid
losing the race. While there, increase the time of the delay jobs to avoid
them finishing during that test in an extremely slowly running QA. (Note that
the jobs are killed forcefully at the end of the test, so that time is never
really waited for.)
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Even starting a (delay 0.01) job without filters does not happen
within the 0.5 seconds we allowed if run in a big cluster.
Use retry here as well.
Signed-off-by: Niklas Hambuechen <niklash@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

The time needed to delete a filter and have jobs that were paused
by that filter be scheduled depends on the size of the cluster.

The polling retry introduced here is more robust than a sleep.
Signed-off-by: Niklas Hambuechen <niklash@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Includes QA for RAPI filter management and gnt_filter.

System tests (adding/removing filters, observing their effects)
are done with gnt_filter.
Signed-off-by: Niklas Hambuechen <niklash@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>