i @vchlum - thanks for taking on the kerberos tests. About exactly how to add them to CI, we need to find out how much extra duration it is going to be. I think the community will like to keep the overall duration to a manageable duration, so that every PR does not have take too long and then PR’s pile up.
Looks like we have just the build phase and no tests added. And currently, that extra run is taking about 5 minutes since there are only 5 concurrent runs. Just 5 mins might be quite acceptable, but if we added tests how much longer will it take?
I understand to keep the Travis CI tests duration reasonable @subhasisb .
I don’t know the duration with tests yet. The tests are not implemented yet. We could add only simple tests to Travis CI. E.g. test whether the ticket is supplied to the job. This could be quite fast. The rest would be run manually.
I would also love to test regularly whether the ticket is renewed. Right now, the main renew task runs only once in 5 minutes and the actual renew of a job is randomly scheduled within the next 5 minutes. It means up to 10 minutes for this test - this is probably not acceptable even for a manual test… This can be resolved by adding a new server attribute cred_renew_task_period, which will control this period. So, we can set it to 5 seconds or so.
The jobs run parallel but on 5 slots. The first 5 jobs run parallel in the beginning. But the last two (the new ones) were in the queue until one of the 5 jobs finished - then the 6th started and 7th was still in queue until another job finished. The 6th and 7th had finished before the sanitized (5th) job finished.
- this is probably not acceptable even for a manual test… This can be resolved by adding a new server attribute cred_renew_task_period, which will control this period. So, we can set it to 5 seconds or so.