Saturday, 2016-12-10

jeblairadam_g: i want to say that since in v2, the merge conflict detection happens before the jobs are launched, that ensures that A and C will end up in the queue before we release the jobs.  but in v3, the conflict detection happens after the jobs are launched, which means when you release it, B will fail, C will restart, and if that happens after A merges, you'll end up with the output you pasted (C tested without A -- but only because A was ...00:01
jeblair... already merged)00:01
jeblairadam_g: i am not 100% sure about that, but if so, doing the stepwise release of the -merge jobs like in the old change would probably preserve the behavior (A would still be running when C is re-enqueued after B fails out, so you should see A and C together in the history)00:02
adam_gjeblair: ok that all makes some sense. it looks like the merge conflict detection isn't happening ATM without the little change in that patch to the launcher00:03
adam_gi couldn't get the stepwise releases to work as they did in v2 but ill play with what im looking at in test_parallel_changes.00:03
jeblairadam_g: yeah, i agree that fix is probably necessary.  re stepwise -- since you're switching to holding the jobs in the launch_server, you'll need to use the launch_server release, which i think just "self.release('.*-merge')" will do.00:06
jeblairadam_g: er, looks like we're preferring self.launch_server.release00:07
adam_gjeblair: yep00:07
adam_gjeblair: OK! the stepwise releases helped there00:11
jeblairyay!00:11
adam_gi may keep the patch as-is without them, though. im not sure it provides much value at this point if its a non-standard behavior00:13
openstackgerritAdam Gandelman proposed openstack-infra/zuul: Re-enable test_build_configuration_conflict  https://review.openstack.org/40937600:20
openstackgerritJames E. Blair proposed openstack-infra/zuul: WIP organize connections into drivers  https://review.openstack.org/40884900:24
openstackgerritJerry Zhao proposed openstack-infra/zuul: add check if an event matches the connection which triggered it.  https://review.openstack.org/40939703:17
*** harlowja_ has quit IRC03:36
*** jeblair_ has joined #zuul03:37
*** pleia2_ has joined #zuul03:37
*** pleia2 has quit IRC03:38
*** jeblair has quit IRC03:38
*** hogepodge has quit IRC05:06
*** saneax-_-|AFK is now known as saneax06:20
*** saneax is now known as saneax-_-|AFK07:01
*** saneax-_-|AFK is now known as saneax07:02
*** pleia2_ has quit IRC07:28
*** pleia2 has joined #zuul07:29
*** jeblair_ has quit IRC08:22
*** jeblair has joined #zuul08:23
*** saneax is now known as saneax-_-|AFK08:52
*** Cibo_ has quit IRC11:32
*** Cibo_ has joined #zuul11:41
*** pleia2 has quit IRC12:51
*** cinerama has quit IRC12:51
*** mmedvede has quit IRC12:51
*** pleia2 has joined #zuul12:51
*** cinerama has joined #zuul12:51
*** mmedvede has joined #zuul12:51
dmsimardjeblair: I'm curious to know how Zuul is planned to be licensed. Is it going to stick with Apache v2 and keep the callbacks/plugins GPLv3 ?14:20
dmsimardfungi: ^14:21
mordreddmsimard: that is my understanding of the current plan, yes15:28
dmsimardOk, I'll align ara in a similar fashion .. callbacks and plugins were created with an apache v2 header from inception due to ignorance15:29
*** bhavik has joined #zuul16:12
openstackgerritMerged openstack-infra/zuul: Re-enable requirement vote tests  https://review.openstack.org/40106117:45
pabelangerjeblair: Shrews: Now that we are running feature/zuulv3 in production for nodepool what is the plan for the feature/zuulv3 branch?  Are we thinking of merging to master, then dropping it, and propose patches directly to master? Or keep it alive for a little longer?17:53
*** bhavik has quit IRC18:25
mordredpabelanger: I think the plan is to let it burn in for just a bit, then merge it back to master (switching puppet to run from master) and start working on the node-launcher bits in the zuulv3 branch18:52
*** jesusaur has joined #zuul19:24
*** jeblair has quit IRC21:48

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!