> On Mar 21, 2016, at 5:40 AM, Ihar Hrachyshka <[email protected]> wrote: > > Sean M. Collins <[email protected]> wrote: > >> Rossella Sblendido wrote: >>> 2) multi-node jobs run for every patch set. Is that really what we want? >>> They take pretty long. We could move them to a periodic job. >> >> I would rather remove all the single-node jobs. Nova has been moving to >> multinode jobs for their gate (if I recall correctly my >> conversation with Dan Smith) and we should be moving in this direction >> too. We should test Neutron the way it is deployed in production. >> >> Also, who is really monitoring the periodic jobs? Truthfully? I know >> there are some IPv6 jobs that are periodic and I'll be the first to >> admit that I am not following them *at all*. > > Well, stable maintainers track their periodic job failures. :) Email > notifications when something starts failing help. > >> >> So, my thinking is, unless it's running at the gate and inflicting pain >> on people, it's not going to be a treated as a priority. Look at Linux >> Bridge - serious race conditions that existed for years only >> got fixed once I inflicted pain on all the Neutron devs by making it >> voting and running on every patchset (sorry, not sorry). > > I think there is still common ground between you and Rossella’s stances: the > fact that we want to inflict gating pain does not mean that we want to > execute every single job on each PS uploaded to gerrit. For some advanced and > non-obvious checks [like partial grenade] the validation could be probably > postponed till the patch hits the gate. > > Yes, sometimes it will mean gate being reset due to the bad patch. This can > be avoided in most of cases if reviewers and the author for a patch that > potentially touches a specific scenario execute the jobs before hitting the > gate with the patch [for example, if the job is in experimental set, it’s a > matter of ‘check experimental’ before pressing W+1].
We have been pretty consciously moving neutron jobs to cause pain to *neutron* and not everyone else, which is the opposite of a “gate only” plan. Aside from that being against infra policy, I think I’m reading between the lines that folks are wanting faster iterations between patchsets. I note that the standard -full job is up to 55-65 minutes, from it’s old time of 40-45. Have we characterized why that’s so much slower now? Perhaps addressing that will bring down to the turn-around for all. Thanks, doug > > Ihar > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
