| *** jamielennox is now known as jamielennox|away | 02:25 | |
| *** jamielennox|away is now known as jamielennox | 03:03 | |
| *** rmoe has quit IRC | 05:29 | |
| *** abregman has joined #zuul | 05:54 | |
| *** saneax-_-|AFK is now known as saneax | 06:35 | |
| *** bhavik1 has joined #zuul | 06:48 | |
| *** bhavik1 has quit IRC | 06:53 | |
| *** rmoe has joined #zuul | 06:55 | |
| *** hashar has joined #zuul | 07:41 | |
| *** saneax is now known as saneax-_-|AFK | 08:09 | |
| *** saneax-_-|AFK is now known as saneax | 08:16 | |
| *** saneax is now known as saneax-_-|AFK | 09:24 | |
| *** saneax-_-|AFK is now known as saneax | 09:34 | |
| *** abregman_ has joined #zuul | 10:00 | |
| *** abregman has quit IRC | 10:03 | |
| *** abregman_ has quit IRC | 10:15 | |
| *** abregman has joined #zuul | 10:16 | |
| *** abregman_ has joined #zuul | 11:23 | |
| *** abregman has quit IRC | 11:26 | |
| *** saneax is now known as saneax-_-|AFK | 11:42 | |
| *** saneax-_-|AFK is now known as saneax | 11:43 | |
| *** saneax is now known as saneax-_-|AFK | 13:17 | |
| *** abregman_ is now known as abregman|mtg | 13:29 | |
| *** abregman|mtg is now known as abregman | 14:32 | |
| *** phschwartz has quit IRC | 14:53 | |
| *** phschwartz has joined #zuul | 14:58 | |
| *** saneax-_-|AFK is now known as saneax | 14:59 | |
| *** saneax is now known as saneax-_-|AFK | 15:20 | |
| *** hashar is now known as hasharAway | 16:24 | |
| *** saneax-_-|AFK is now known as saneax | 16:35 | |
| * morgan shuffles papers loudly | 17:09 | |
| *** saneax is now known as saneax-_-|AFK | 17:12 | |
| *** abregman has quit IRC | 17:26 | |
| *** bhavik1 has joined #zuul | 18:03 | |
| *** bhavik1 has quit IRC | 18:07 | |
| jlk | be sure to stack them up and straighten them by tapping them on the table numerous times | 18:19 |
|---|---|---|
| clarkb | rcarrillocruz: commented on the rest of the d-g ansibly stack | 18:21 |
| Shrews | jeblair: Do we want to be able to support shared providers among nodepool launchers? | 18:50 |
| Shrews | jeblair: because doing so means we need some way to determine provider usage (for quota mgmt) among the launchers | 18:52 |
| jeblair | Shrews: i think so (though i doubt we will use it that way in production) -- i think that if we examine the existing nodes in zk to get the quota used, it should generally work. it could be slightly racy when we're right at the edge, but we expect failure from openstack at any point anyway. if we wanted to mitigate that, we could probably have a "provider lock" which each provider grabs before creating new node entries. | 18:56 |
| *** Shuo_ has joined #zuul | 18:56 | |
| Shrews | jeblair: gotcha. i'll go without the new lock for now | 18:57 |
| jeblair | Shrews: cool. it should be easy to add later if needed. | 18:58 |
| Shrews | i'll make sure to document that point in the code re: the race+expected fail | 18:59 |
| clarkb | fwiw the spec said punt on that til later | 19:04 |
| clarkb | so maybe update the spec as part of docs writing | 19:04 |
| Shrews | clarkb: ah, so it does | 19:12 |
| *** rmoe has quit IRC | 19:49 | |
| *** rmoe has joined #zuul | 19:50 | |
| jeblair | oh hey it does :) | 19:51 |
| jeblair | Shrews: so i'd say it's up to you how far you want to go in that direction. | 19:52 |
| mordred | jeblair: bikeshed warning - what should I call the branch? | 19:55 |
| clarkb | feature/gearman-zk-shim ? | 19:56 |
| mordred | wfm - any objections? | 19:57 |
| jeblair | lgtm | 19:58 |
| Shuo_ | in the openstack workflow http://docs.openstack.org/infra/manual/developers.html, if my change (let's call it change_a) is based upon HEAD that I checked out at 10:00am on 1/1/2017, but the new HEAD moves forward during my development and wait for review time window. Am I required to git pull from time to time (to sync up with the current HEAD), if my change does not get impacted by the newly added commit in master line? (just a high leve | 19:59 |
| clarkb | Shuo_: no | 20:01 |
| clarkb | you only need to update it if merge conflicts are introduced | 20:01 |
| *** hasharAway is now known as hashar | 20:01 | |
| mordred | Shuo_: in fact, we recommend against rebasing unnecessarily as it makes it harder to review | 20:01 |
| Shuo_ | clarkb: just wonder, what is the ration of all code change/commit that need rebase (because of the moving HEAD problem)? Is there a high level ballpark number? | 20:02 |
| clarkb | I am not sure we have measured it | 20:03 |
| clarkb | and I doubt it is consitsten across code bases or time | 20:03 |
| clarkb | since it is highly dependent on who is working on what code at what times | 20:03 |
| Shuo_ | clarb: but I would imagine that if a necessary rebase happens in the middle of a review process (say, TL has already made some comments and the developer agrees to change accordingly, but a rebase has to be done because of a new merge), it would be very annoying to both parties. | 20:08 |
| clarkb | yes rebases are annoying | 20:08 |
| clarkb | my point is that I don't think they happen in statistically common ways | 20:08 |
| clarkb | they are highly dependent on the structure of the repos, the current work being done on them, etc | 20:08 |
| clarkb | (but if someone were to measure it across our repos they might prove me wrong) | 20:10 |
| adam_g | are MergeCompletedEvent received by the scheduler only when post-gate merges have completed, or also when the changes have been merged together for testing? | 20:14 |
| adam_g | jeblair: ^ | 20:14 |
| clarkb | adam_g: my reading is it happens for both | 20:19 |
| clarkb | zuul/merger/client.py calls sched.onMergeCompleted() | 20:19 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool: Begin implementing node request handling. https://review.openstack.org/421485 | 20:25 |
| jlk | Looking at (old) zuul tests, seems a pipeline AND a trigger can have a requirement? Is that right? | 20:26 |
| Shrews | jeblair: 421485 is kind of in the middle of implementing things. no real good place to delineate the work to keep it from getting huge, so i just tossed it up as-is | 20:27 |
| Shrews | also, my brain hurts | 20:31 |
| adam_g | clarkb: ok ya. so it looks like its realy only used for the speculative merges, and not the changes merging upstream | 20:31 |
| clarkb | adam_g: I think its both | 20:32 |
| clarkb | adam_g: the scheduler calls that method on itself when processing the events queue too | 20:32 |
| clarkb | but I may have misread that | 20:32 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool: Begin implementing node request handling. https://review.openstack.org/421485 | 20:34 |
| Shrews | commit msg updated | 20:34 |
| jeblair | adam_g, clarkb: i believe that event only represents the internal speculative merging. a merg into a managed repo would just be a regular TriggerEvent | 20:42 |
| jeblair | Shrews: i'm in favor of that approach :) | 20:43 |
| jeblair | jlk: yes -- and it's not redundant... a pipeline requirement generally specifies aspects of the change that may not relate to the triggering event | 20:47 |
| jlk | okay, and a trigger event is basically "ignore this trigger unless these requirements are met" | 20:57 |
| jlk | so like, trigger on comment, but require approvals in place, or ignore comment unless it comes from specific user | 20:57 |
| *** Shuo__ has joined #zuul | 21:03 | |
| *** klindgren has quit IRC | 21:03 | |
| *** Shuo_ has quit IRC | 21:05 | |
| *** Shuo__ has quit IRC | 21:07 | |
| jeblair | jlk: right. there's some marginally complex things we do with that in the openstack config (like "trigger in check on a workflow+1 if jenkins has a -1" (because we require a +2 from jenkins for gate, and that probably means someone wants a recheck) | 21:08 |
| jeblair | jlk: there's another subtle difference between trigger and pipeline requirements: some items get enqueued into a pipeline because of dependencies. those are not subject to trigger requirements, but are subject to pipeline requirements. (so, for instance because workflow+1 is a gate pipeline requirement, you can't pull a change into gate with depends-on unless that change has also been approved) | 21:10 |
| jlk | nod | 21:41 |
| *** hashar has quit IRC | 21:57 | |
| *** harlowja has quit IRC | 22:01 | |
| *** Shuo_ has joined #zuul | 22:04 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!