2:28 p.m.
See https://review.gerrithub.io/#/c/ffilz/nfs-ganesha/+/409213/
Centos CI seems to be having an issue with Gluster packages.
This also shows an issue with several Centos CI tests sharing a Gerrit ID -
one test set verify -1 but then the next test passed and overrode the verify
-1 with a verify +1.
I'm guessing the testing has no way to track a cumulative state, so it would
work better to have separate IDs.
Frank
1:28 a.m.
New subject: [Nfs-ganesha-devel] Re: Centos CI issues
Frank Filz wrote on Thu, Apr 26, 2018 at 12:28:31PM -0700:
I'm guessing the testing has no way to track a cumulative state,
so it would
work better to have separate IDs.
Another possibility would be to have a single gerrit job from the centos
ci that triggers many builds (cthon, gluster etc) and then only sends
one update based on all the tests.
We already have everything needed to do that on centos ci - for example
the actual cthon04 test is split into these two:
- nfs_ganesha_cthon04 that does the actual build
- nfs-ganesha_trigger-cthon04-on-new-patch that listens to gerrit
events and triggers the build
We'd just need to remove all the nfs-ganesha_triggers-* (actually some
do work there, so rename the ones who do and remove just the trigger
part); then keep just one, but make that trigger all the actual build
projects instead.
It'd then automatically only post once with the aggregated result (I
assume it'd fail if any of the tests failed)
My only concern is whether or not it'd slow things down, I'm not sure
it'd trigger all jobs in parallel.. But then again I'm not sure how many
workers are allocated for ganesha so if we only have few it might not
make much difference?
--
Dominique
6:15 a.m.
New subject: [Nfs-ganesha-devel] Re: Centos CI issues
On Fri, Apr 27, 2018 at 08:28:05AM +0200, Dominique Martinet wrote:
This list has been deprecated. Please subscribe to the new devel list
at lists.nfs-ganesha.org.
Frank Filz wrote on Thu, Apr 26, 2018 at 12:28:31PM -0700:
> I'm guessing the testing has no way to track a cumulative state, so it would
> work better to have separate IDs.
Another possibility would be to have a single gerrit job from the centos
ci that triggers many builds (cthon, gluster etc) and then only sends
one update based on all the tests.
We already have everything needed to do that on centos ci - for example
the actual cthon04 test is split into these two:
- nfs_ganesha_cthon04 that does the actual build
- nfs-ganesha_trigger-cthon04-on-new-patch that listens to gerrit
events and triggers the build
We'd just need to remove all the nfs-ganesha_triggers-* (actually some
do work there, so rename the ones who do and remove just the trigger
part); then keep just one, but make that trigger all the actual build
projects instead.
It'd then automatically only post once with the aggregated result (I
assume it'd fail if any of the tests failed)
I think a single multi-job configuration is the best approach. There can
then be a single Jenkins job that starts a series of tests.
nfs-ganesha_trigger-cthon04-on-new-patch could easily be used for that
indeed.
My only concern is whether or not it'd slow things down, I'm
not sure
it'd trigger all jobs in parallel.. But then again I'm not sure how many
workers are allocated for ganesha so if we only have few it might not
make much difference?
At the moment there are 3 executors, and certain tests may not run at
the same time (because they use Virtual IPs for failover testing, if
those tests are actually running?).
It could be dangerous to allow multiple multi-job jobs running at once.
Those and their jobs may compete for the 3 executors. I thought there
was a way to give priorities to jobs, but I can not find the options in
the Jenkins UI anymore.
I can help with changing the configuration if needed, but do not have
time for it this week (KubeCon in Copenhagen).
HTH,
Niels
2196
days inactive
2200
days old
2 comments
3 participants
participants (3)
-
Dominique Martinet -
Frank Filz -
Niels de Vos