| openstackgerrit | Merged zuul/zuul master: Switch to opendev release/docs jobs https://review.opendev.org/670388 | 00:22 |
|---|---|---|
| *** armstrongs has quit IRC | 00:29 | |
| *** dmsimard4 is now known as dmsimard | 00:32 | |
| *** panda has quit IRC | 00:48 | |
| *** panda has joined #zuul | 00:50 | |
| openstackgerrit | James E. Blair proposed zuul/nodepool master: Switch to zuul tenant jobs for docs/release https://review.opendev.org/670422 | 00:53 |
| *** irclogbot_3 has joined #zuul | 00:56 | |
| *** irclogbot_3 has quit IRC | 01:00 | |
| *** irclogbot_0 has joined #zuul | 01:26 | |
| openstackgerrit | Merged zuul/nodepool master: Switch to zuul tenant jobs for docs/release https://review.opendev.org/670422 | 01:32 |
| *** irclogbot_0 has quit IRC | 01:34 | |
| *** igordc has quit IRC | 01:35 | |
| *** swest has quit IRC | 01:36 | |
| *** swest has joined #zuul | 01:51 | |
| *** irclogbot_3 has joined #zuul | 02:26 | |
| *** irclogbot_3 has quit IRC | 02:30 | |
| *** altlogbot_1 has joined #zuul | 02:48 | |
| *** altlogbot_1 has quit IRC | 02:52 | |
| *** bhavikdbavishi has joined #zuul | 03:00 | |
| *** bhavikdbavishi has quit IRC | 03:02 | |
| *** michael-beaver has quit IRC | 03:08 | |
| *** rlandy has quit IRC | 03:16 | |
| *** irclogbot_2 has joined #zuul | 03:22 | |
| *** irclogbot_2 has quit IRC | 03:26 | |
| *** irclogbot_1 has joined #zuul | 03:52 | |
| *** irclogbot_1 has quit IRC | 03:56 | |
| *** swest has quit IRC | 04:26 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Normalize test jobs yaml https://review.opendev.org/670198 | 04:31 |
| *** bolg has joined #zuul | 04:39 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Add add-authorized-keys test job https://review.opendev.org/670199 | 04:45 |
| *** toabctl has quit IRC | 04:53 | |
| *** toabctl has joined #zuul | 04:55 | |
| *** irclogbot_2 has joined #zuul | 05:00 | |
| *** bhavikdbavishi has joined #zuul | 05:01 | |
| *** pcaruana has joined #zuul | 05:13 | |
| *** irclogbot_2 has quit IRC | 05:16 | |
| *** swest has joined #zuul | 05:24 | |
| *** altlogbot_0 has joined #zuul | 06:10 | |
| *** altlogbot_0 has quit IRC | 06:14 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Advance ansible-lint cap to test with 4 https://review.opendev.org/667695 | 06:31 |
| *** irclogbot_0 has joined #zuul | 06:36 | |
| *** irclogbot_0 has quit IRC | 06:40 | |
| *** saneax has joined #zuul | 06:53 | |
| *** tosky has joined #zuul | 07:19 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 07:21 |
| *** badboy has joined #zuul | 07:35 | |
| badboy | hi guys | 07:35 |
| badboy | I have a problem with web console | 07:41 |
| badboy | I have a problem with web console | 07:41 |
| badboy | 2019-07-11 09:16:21.248160 | [ubuntu-bionic] Waiting on logger | 07:42 |
| badboy | This is what I get | 07:42 |
| badboy | additionally this is in the logs: http://paste.openstack.org/show/754332/ | 07:42 |
| *** hashar has joined #zuul | 07:49 | |
| *** altlogbot_3 has joined #zuul | 08:03 | |
| *** altlogbot_3 has quit IRC | 08:04 | |
| *** yolanda has quit IRC | 08:08 | |
| *** yolanda has joined #zuul | 08:09 | |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: Overriding max. starting builds. https://review.opendev.org/670461 | 08:09 |
| *** altlogbot_3 has joined #zuul | 08:12 | |
| *** altlogbot_3 has quit IRC | 08:16 | |
| *** altlogbot_1 has joined #zuul | 08:18 | |
| *** altlogbot_1 has quit IRC | 08:22 | |
| *** altlogbot_2 has joined #zuul | 08:24 | |
| *** altlogbot_2 has quit IRC | 08:29 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 08:42 |
| *** aluria has quit IRC | 08:48 | |
| *** irclogbot_3 has joined #zuul | 09:00 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 09:03 |
| *** aluria has joined #zuul | 09:03 | |
| *** irclogbot_3 has quit IRC | 09:04 | |
| *** gtema_ has joined #zuul | 10:03 | |
| *** hashar has quit IRC | 10:28 | |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: Overriding max. starting builds. https://review.opendev.org/670461 | 10:31 |
| *** yolanda has quit IRC | 10:31 | |
| *** yolanda has joined #zuul | 10:32 | |
| *** irclogbot_2 has joined #zuul | 10:32 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Annotate canMerge check with event id https://review.opendev.org/670494 | 10:35 |
| *** irclogbot_2 has quit IRC | 10:38 | |
| *** irclogbot_2 has joined #zuul | 10:44 | |
| *** irclogbot_2 has quit IRC | 10:44 | |
| *** gtema_ has quit IRC | 10:47 | |
| *** aluria has quit IRC | 10:56 | |
| *** hashar has joined #zuul | 11:01 | |
| *** altlogbot_0 has joined #zuul | 11:04 | |
| *** altlogbot_0 has quit IRC | 11:08 | |
| *** aluria has joined #zuul | 11:11 | |
| *** altlogbot_3 has joined #zuul | 11:14 | |
| *** altlogbot_3 has quit IRC | 11:16 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 11:26 |
| openstackgerrit | Jan Kubovy proposed zuul/zuul master: Overriding max. starting builds. https://review.opendev.org/670461 | 11:29 |
| *** saneax has quit IRC | 11:52 | |
| pabelanger | badboy: check your firewall ports, tcp/19885 needs to be open. Also ensure zuul_console is running on the node | 11:59 |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Use a requests session to simplify auth'd calls https://review.opendev.org/670511 | 12:16 |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Use urllib.parse for manipulating client urls https://review.opendev.org/670512 | 12:16 |
| mordred | mhu: I was reviewing your stack and noticed two things ^^ feel free to ignore, use or squash as you see fit | 12:16 |
| mhu | mordred, nice; I never think about sessions ... | 12:18 |
| mordred | mhu: I only due because of openstacksdk :) | 12:19 |
| mhu | mordred, also I think that self.port is a remnant from a previous patchset, I'll have a look | 12:20 |
| mhu | I must have been distracted by all that red turning blue | 12:20 |
| mordred | mhu: I have had some similar experiences :) | 12:22 |
| mordred | mhu: if self.port is a leftover, then probably that entire patch can just be abandoned | 12:22 |
| *** electrofelix has joined #zuul | 12:23 | |
| mhu | mordred, right, let me upload the fixed PS | 12:23 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Zuul CLI: allow access via REST https://review.opendev.org/636315 | 12:27 |
| openstackgerrit | Monty Taylor proposed zuul/zuul master: Use a requests session to simplify auth'd calls https://review.opendev.org/670511 | 12:33 |
| mordred | mhu: cool. +2 - and I abandoned the urlparse madness patch and rebased the other | 12:33 |
| mhu | thanks! | 12:33 |
| openstackgerrit | Simon Westphahl proposed zuul/nodepool master: Don't pause static pool on single label quota https://review.opendev.org/667371 | 12:37 |
| *** rlandy has joined #zuul | 12:37 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add Authorization Rules configuration https://review.opendev.org/639855 | 12:41 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Evaluate CODEOWNERS settings during canMerge check https://review.opendev.org/644557 | 12:42 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Web: plug the authorization engine https://review.opendev.org/640884 | 12:45 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Zuul Web: add /api/user/authorizations endpoint https://review.opendev.org/641099 | 12:45 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: authentication config: add optional token_expiry https://review.opendev.org/642408 | 12:45 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: Web: plug the authorization engine https://review.opendev.org/640884 | 12:54 |
| *** tjgresha_nope has joined #zuul | 12:59 | |
| *** tjgresha has quit IRC | 13:02 | |
| *** sshnaidm|off has quit IRC | 13:30 | |
| *** sshnaidm has joined #zuul | 13:35 | |
| *** sshnaidm is now known as sshnaidm|off | 13:36 | |
| *** irclogbot_2 has joined #zuul | 13:38 | |
| *** irclogbot_2 has quit IRC | 13:38 | |
| Shrews | swest: i havent yet looked at the new patchset on 667371, but i | 14:01 |
| Shrews | i'm much happier it doesnt touch the generic driver code | 14:02 |
| *** bolg has quit IRC | 14:07 | |
| *** irclogbot_1 has joined #zuul | 14:11 | |
| *** chandankumar is now known as raukadah | 14:14 | |
| *** altlogbot_3 has joined #zuul | 14:15 | |
| SpamapS | #1 most often thing I wish for now that cleanups and filtering on job config changes are implemented: I wish Zuul had a clear way to show why an event didn't result in any jobs running... | 14:19 |
| SpamapS | trying to discern it from the DEBUG logs is nearly impossible with lots of pipelines and trigger rules | 14:20 |
| SpamapS | So it'd be nice if those things were more succinctly logged and possibly surfaced to a SQL table where one could inspect it more readily. | 14:20 |
| corvus | SpamapS: it's really hard to say why things don't happen (as in all of life, many more things don't happen than do happen) | 14:21 |
| SpamapS | Right, I'm just thinking that when an event gets to the end and nothing happens, I'd like the trail of failed matchers and/or other thing to be summarized. | 14:21 |
| corvus | SpamapS: so i think part of the challenge is that it is logged succinctly, it's just that it might be 200 things that are logged succinctly, and you only care about one | 14:22 |
| SpamapS | Right now the debug log is the only way.. and it's a *huge* mess even if you have the github event ID.. I'm sure gerrit provides a similar breadcrumb. | 14:22 |
| *** jeliu_ has joined #zuul | 14:22 | |
| SpamapS | 2019-07-12 00:20:04,421 DEBUG zuul.Pipeline.GoodMoney.gate: [e: caf568d0-a43a-11e9-87ad-dae44ef23b0c] Event <GithubTriggerEvent 0x7fce18157e48 pull_request GoodMoney/funnel-cake refs/pull/31/head labeled github.com/GoodMoney/funnel-cake 31,5885856ca64b47163a04cee4dc37b7f6eff0711f delivery: caf568d0-a43a-11e9-87ad-dae44ef23b0c> for change <Change 0x7fce183dc978 GoodMoney/funnel-cake | 14:23 |
| SpamapS | 31,5885856ca64b47163a04cee4dc37b7f6eff0711f> matched <GithubEventFilter types: pull_request ignore_deletes: True actions: labeled labels: shipit> in pipeline <DependentPipelineManager gate> | 14:23 |
| corvus | SpamapS: there's another way: https://zuul-ci.org/docs/zuul/user/config.html#attr-project.%3Cpipeline%3E.debug | 14:23 |
| SpamapS | That's realy hard to compare to other log entries with similar info. | 14:23 |
| SpamapS | Hm that debug thing may be useful, I had not seen it. | 14:24 |
| corvus | SpamapS: you're not going to want to set it permanently, but you can set it as part of an in-repo dynamic config change and get output for that specific change | 14:24 |
| corvus | (it's like dumping the debug logs into the zuul report; though they are formatted slightly nicer) | 14:25 |
| SpamapS | To be more concrete: This time, I've been having a problem lately where I think users have scripted opening the pr and dropping the shipit label on things.. and I think the caching in github or zuul is making zuul think the label isn't there yet. | 14:27 |
| SpamapS | I don't really have 1 change to debug.. I have a rate of about 10%. | 14:28 |
| SpamapS | Anyway this may yet prove useful for that. I'll play. Thanks. | 14:28 |
| corvus | SpamapS: curious. i wouldn't expect that to be a problem. let me know what you find. | 14:29 |
| pabelanger | delayed events? | 14:29 |
| pabelanger | I've seen a label show up late before | 14:29 |
| pabelanger | also, see issue with label not getting seen, but haven't really debugged why yet | 14:30 |
| pabelanger | been holding off on that until running tobiash latest github updates | 14:30 |
| SpamapS | corvus:I've had that exact problem in the past. I thought we solved it with etags or something. | 14:31 |
| SpamapS | github's API is kind of async sometimes. The same happens with statuses... if you set a status and read it back it will often be the old value. | 14:31 |
| SpamapS | which is one reason I can't use the "require gate status to be reported success" trick to ensure only Zuul merges PRs. | 14:32 |
| corvus | SpamapS: we could have zuul delay after setting statuses until it reads back correctly | 14:34 |
| SpamapS | corvus:I believe we just need Zuul to set the appropriate E-Tag on the request which will force a cache invalidation. | 14:34 |
| corvus | (there's actually some code in gerrit for something similar -- gerrit itself is sync, but there's some code to make sure that git replicas are updated) | 14:34 |
| tobiash | corvus: actually this should work, as we also can react on the status event (which should then guarantee that the status is set) | 14:35 |
| SpamapS | The promote pipeline took pressure off of me to solve this.. | 14:35 |
| SpamapS | if the users self-merge, they don't get artifacts built, and promote fails. | 14:35 |
| SpamapS | so Zuul has trained them not to click the merge button | 14:36 |
| * SpamapS afk | 14:36 | |
| openstackgerrit | Jeff Liu proposed zuul/zuul-operator master: Add Kubernetes Operator Functional Test Job https://review.opendev.org/668029 | 14:38 |
| openstackgerrit | Jeff Liu proposed zuul/zuul-operator master: [WIP] Verify Operator Pod Running https://review.opendev.org/670395 | 14:38 |
| *** hashar has quit IRC | 14:51 | |
| corvus | pabelanger, mordred, tobiash, SpamapS, clarkb: ^ I think 668029 is ready for review | 14:59 |
| openstackgerrit | Jeff Liu proposed zuul/zuul-operator master: Remove Operator SDK dependency in Zuul Job https://review.opendev.org/670584 | 15:17 |
| *** mattw4 has joined #zuul | 15:37 | |
| openstackgerrit | Jeff Liu proposed zuul/zuul-operator master: Remove Operator SDK dependency in Zuul Job https://review.opendev.org/670584 | 15:58 |
| *** armstrongs has joined #zuul | 16:00 | |
| armstrongs | hey small query if anyone can help. I am looking at using a timer pipeline.trigger.timer, so if this is used will it just build the latest ref from the projects master branch? | 16:02 |
| fungi | armstrongs: the short answer is yes (or you can specify the branch you want it to use) | 16:03 |
| armstrongs | is there an example config of where it is used anywhere? | 16:03 |
| fungi | already pulling one up to link | 16:03 |
| armstrongs | thanks you | 16:03 |
| fungi | armstrongs: here's an example of using one called "periodic-stable" in a project-template: https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/project-templates.yaml#L1125-L1146 | 16:06 |
| fungi | you can see there how the jobs in the periodic-stable pipeline have branches lists | 16:06 |
| fungi | if you don't supply a branches list, the default is just master | 16:06 |
| armstrongs | thank you will give that a go | 16:07 |
| armstrongs | :) | 16:07 |
| fungi | armstrongs: for reference, we define that pipeline here: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L236-L252 | 16:07 |
| fungi | but there's really not much to it | 16:08 |
| *** jangutter has quit IRC | 16:16 | |
| *** jangutter has joined #zuul | 16:16 | |
| SpamapS | mmmm operator | 16:19 |
| * SpamapS would love to throw away his janky spruce scripts | 16:19 | |
| fungi | but they really spruce up the place | 16:22 |
| *** aluria has quit IRC | 16:26 | |
| *** armstrongs has quit IRC | 16:31 | |
| SpamapS | you'd think | 16:31 |
| corvus | jeliu_: now that the pod list command is in place, it does look like the operator is crashing: http://logs.openstack.org/29/668029/19/check/zuul-operator-functional-k8s/cedd11a/ara-report/result/98cfffd4-34d2-40ac-be8b-208bb3129e9f/ that's fine, we don't care that much at this point, but it does mean that once you get the job set up to verify that the operator is running, that is going to (correctly) fail. | 16:33 |
| corvus | jeliu_: regarding the other change, it looks like the plain docker build worked: https://review.opendev.org/670584 \o/ | 16:33 |
| mordred | pabelanger, clarkb: https://review.opendev.org/#/c/668029 have 2x+2 but I left it open since you'd reveiwed before in case you want to look again | 16:34 |
| *** jangutter has quit IRC | 17:16 | |
| pabelanger | mordred: corvus: +2, too | 17:20 |
| pabelanger | left +A to clarkb if wanted otherwise good to merge | 17:20 |
| clarkb | I'll look at it now that fedora 28 problems are debugged | 17:23 |
| clarkb | approved. There was one minor task/play naming thing that I noted but can be cleaned up in a follow on | 17:25 |
| openstackgerrit | Merged zuul/zuul-operator master: Add Kubernetes Operator Functional Test Job https://review.opendev.org/668029 | 17:37 |
| openstackgerrit | Merged zuul/zuul-operator master: Remove Operator SDK dependency in Zuul Job https://review.opendev.org/670584 | 17:37 |
| corvus | jeliu_: ^ yay! | 17:37 |
| * mordred does a dane | 17:38 | |
| mordred | dane | 17:38 |
| mordred | GAH | 17:38 |
| mordred | dance | 17:38 |
| mordred | apparently a danish dance | 17:38 |
| * mordred crawls back under his rock | 17:38 | |
| *** igordc has joined #zuul | 17:43 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Build layout of non-live items with config updates https://review.opendev.org/670335 | 17:53 |
| clarkb | the zuul zuul tenant has made me wonder if it would be a worthwhile thing to have a status dashboard that allows you to opt into seeing specified tenants? | 18:08 |
| clarkb | so I could see the zuul and openstack tenants in the same dashboard and someone els could have zuul and opendev or whatever | 18:08 |
| clarkb | though I think I sort of assumed I could see things mixed together but the pipeline defs may not overlap so that won't work generally | 18:09 |
| corvus | tenants are completely isolated; so a combined dashboard would have to query multiple endpoints, and yeah, you'd have a lot of duplicate pipelines | 18:10 |
| clarkb | ya I'll have to think about this a bit more to see if there is a good way to do it in my head | 18:11 |
| corvus | clarkb: honestly, even a native implementation may not be much more sophisticated than an iframe, which you could try out now :) | 18:11 |
| clarkb | ya the initial thing I had thought of was to just stick everything from zuul check and openstack check into one logical pipeline in the dashboard called check | 18:13 |
| clarkb | (and so on with gate promote post release etc) | 18:13 |
| mordred | for the naive case that's actuall probably "good enough" for visualizing the aggregate system | 18:14 |
| corvus | the order would convey something which wasn't right | 18:14 |
| mordred | yeah - there's definitely issues and incorrectnesses | 18:14 |
| mordred | sort of depends on what questions you're wanting answered by such a view | 18:14 |
| clarkb | for me its mostly so I don't have to have multiple status windows open to track progress of chagnes I have in flight udner different tenants | 18:15 |
| openstackgerrit | James E. Blair proposed zuul/nodepool master: Add functional jobs to gate https://review.opendev.org/670612 | 18:17 |
| corvus | clarkb: ^ i think the time has come :) | 18:18 |
| mordred | ++ | 18:18 |
| clarkb | approved | 18:18 |
| *** electrofelix has quit IRC | 18:18 | |
| corvus | i'm now very motivated to write the "gate pipeline supercedes check" patch. but it's #3 on the list. | 18:19 |
| *** jeliu_ has quit IRC | 18:42 | |
| *** irclogbot_1 has quit IRC | 18:49 | |
| *** edmondsw_ has quit IRC | 18:49 | |
| *** irclogbot_0 has joined #zuul | 18:53 | |
| *** michael-beaver has joined #zuul | 18:56 | |
| Shrews | corvus: so what purpose does check pipeline serve in this scenario w/o clean-check? seems like a waste of test resources. for nodepool, we could move the last remaining non-voting job to gate and not need check at all | 19:00 |
| fungi | the check pipeline is a way to automatically run jobs on any new proposed change, to aid reviewers in determining whether it's ready | 19:06 |
| fungi | but you're right, you *could* go it with no check pipeline, and just rely on the gate to bounce back changes when they're approved | 19:07 |
| Shrews | oh, i wasnt thinking about the approval requirement. | 19:08 |
| Shrews | my "duh" moment for the day | 19:08 |
| * mordred hands Shrews a beer, suggests maybe it's time for the weekend | 19:19 | |
| Shrews | true | 19:20 |
| Shrews | mordred: i'm blaming the pain meds i'm still on, which is also the reason i must decline your beer | 19:21 |
| corvus | i think there's 2 common scenarios: 1) upload a change, people get to it after a day+ and merge it. check shows us it's ready. 2) upload a change which is simple and obviously works and we should just merge asap. forget check, go straight to gate, gate tells us if we're wrong. | 19:21 |
| corvus | the change i'd like to write to zuul would let zuul know that if case #2 happens, it can abort the jobs running in check | 19:21 |
| fungi | yeah, i do think that's a nice optimization to free up resources | 19:22 |
| Shrews | corvus: sounds like a sensible change | 19:22 |
| fungi | granted, it assumes you run at least all the check jobs in the gate pipeline | 19:22 |
| fungi | but we strongly recommend that anyway | 19:22 |
| corvus | case 2 works for us, because we're a small group of people who never make mistakes.... or, maybe, we're just small enough and judicious enough with +W that we won't end up backing up gate with a bunch of failing changes. | 19:22 |
| fungi | or we're small enough to not be judgemental when someone approves an obviously non-test-passing change | 19:23 |
| corvus | but in openstack's case, no matter how many times we said "be better programmers", people still wanted to throw complex changes that had no chance of passing tests straight at the gate. that's why clean-check was invented -- to keep those changes from backing up openstack's huge gate pipeline | 19:23 |
| corvus | probably, if you get down to basics, if the gate pipeline spends any significant amount of time empty, clean-check isn't necessary. if it spends most of its time with a multi-hour backlog, it probably is. | 19:24 |
| fungi | "keeping things out of the gate until they work" | 19:25 |
| corvus | ^ probably | 19:25 |
| fungi | heh, right! | 19:26 |
| fungi | and yeah, the deeper your gate pipeline is on average, the more costly gate resets become | 19:26 |
| clarkb | another reason for clean check in poenstack is there was a lot of forcing code that had races in it through by enqueuing to the gate over and over | 19:26 |
| clarkb | it is very rare for peopel to actualyl debug those problems it seems :/ | 19:27 |
| clarkb | zuul seems to do a better job | 19:27 |
| fungi | right, that at least forced changes to be good enough to be able to pass all jobs twice in a row | 19:27 |
| fungi | not to pick on openstack... it still has better quality control than 99% of the projects its scale | 19:29 |
| fungi | but complexity and bugs go hand in hand, and in a large interrelated codebase you have to take defensive approaches to nondeterministic behaviors | 19:30 |
| clarkb | ya | 19:32 |
| *** bhavikdbavishi has quit IRC | 19:48 | |
| corvus | i have a weird question | 20:02 |
| corvus | currently if you have change B depending on change A, and change A breaks zuul's config, when they show up in the check pipeline, change B will be reported with a configuration error. that's a side effect of the way we build configuration for dependent changes in check. (weirdly, B would not report an error if it were somehow able to run in gate, but of course it can't.) | 20:06 |
| corvus | of course, A does in all cases have its error reported. | 20:06 |
| corvus | i may have an opportunity to change that, so that we don't see the config error for A on B. would that be desirable? what should happen in its place? attempt to use the broken config anyway (as if we had just restarted zuul with change A merged and then enqueued B)? or should we say "this change depends on a change with a broken config" and not run any jobs? | 20:09 |
| fungi | i desire that, yes | 20:09 |
| fungi | i like the latter | 20:09 |
| fungi | don't run jobs for the depending change because the change it depends on is untestable | 20:09 |
| fungi | but limit the configuration error to the change which actually is attempting to add that error | 20:10 |
| corvus | okay, one vote for "don't run the jobs, but report an abbreviated error message" | 20:10 |
| fungi | the alternative of running the jobs with the broken change applied seems inefficient, since the depending change is most likely going to need to be rebased anyway once the dependency is fixed | 20:11 |
| clarkb | ya that makes the most sense to me | 20:12 |
| clarkb | fungi: and you could get misleading results that create confusion | 20:12 |
| corvus | (there's a lot of code to do almost exactly that, but i suspect that some of it may be dormant due to some optimizations which i'm semi-undoing; we used to build a config for every change, and that was very inefficient because large stacks would have tons of merge jobs for non-live items; so then we stopped merging non-live items at all, but that means we can't see where in a stack the config broke; the | 20:13 |
| corvus | change i'm working on would have us merge non-live items with config updates, so we would still usually not merge them, but sometimes we would if we need their data) | 20:13 |
| corvus | it turns out that looking at a change ahead in the pipeline to find out if the config for a job changed is basically the same as looking to see where the config broke. | 20:14 |
| fungi | strangely, that make sense | 20:28 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Build layout of non-live items with config updates https://review.opendev.org/670335 | 20:41 |
| corvus | oh, let me add more to the commit message about that | 20:41 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Build layout of non-live items with config updates https://review.opendev.org/670335 | 20:45 |
| corvus | okay. that's a long change with a long commit message. :) | 20:45 |
| corvus | next up is to try to repro and fix the error we saw yesterday -- where an existing broken config in the check pipeline caused us not to be able to fix it. | 20:47 |
| corvus | we have tests that check that a broken config can be fixed, but in those tests, i don't think the "check" pipeline is the thing that's broken | 20:49 |
| fungi | seems like a bit of a catch-22 | 20:50 |
| corvus | that's more or less how zuul behaved at the time :) | 20:50 |
| *** pcaruana has quit IRC | 20:59 | |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Handle existing broken config in job updates https://review.opendev.org/670666 | 21:17 |
| corvus | AJaeger, clarkb, fungi: ^ that should handle the exciting catch-22 error we hit yesterday | 21:18 |
| fungi | awesome, looking | 21:21 |
| mordred | corvus: nice | 21:26 |
| corvus | zuul has 32417 lines of test source-code and 33470 lines of application source-code (or about 97% as much test code as app) | 21:28 |
| corvus | (excluding zuul/ansible, which is another 26k very duplicative lines) | 21:29 |
| corvus | some of that should be included, but i'm not curious enough to figure out a fair way to do that | 21:30 |
| clarkb | corvus: left a comment on 670666 | 21:32 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Handle existing broken config in job updates https://review.opendev.org/670666 | 21:37 |
| corvus | clarkb: good point; i think that'll take care of it ^ | 21:37 |
| clarkb | ya that should do it | 21:38 |
| clarkb | corvus: reading the commit message of the non live change could we cache the merge results for each item (maybe we already do?) then we only do it the once (until some ttl times out) for all instances of that item whether live or non live? | 21:45 |
| corvus | clarkb: yeah; i think we could just grab the layout and files objects from an existing copy of the item in the pipeline. that would help with the pathological case of A, AB, ABC, ... . there would be a behavior difference if, for some reason, A stuck around in the pipeline for a long time, AB showed up, and then was rechecked. that means we would end up reusing the result from the A item rather than (as | 21:50 |
| corvus | would happen today) we reperform the merge for AB. i'm not certain whether we care or not. | 21:50 |
| corvus | it's not going to be a trivial optimization; if we do it, i think it should be a followup (since i don't think the current slight sub-optimization is critical) | 21:52 |
| corvus | (incidentally, we do something kinda similar in the provides/requires thing -- where we look for a live dependent change to find its artifact return data -- so the 'look for a change' part of that won't be unique) | 21:53 |
| *** ianychoi has quit IRC | 21:54 | |
| *** rlandy has quit IRC | 21:54 | |
| clarkb | corvus: left a comment on that change related to something else | 21:57 |
| clarkb | I haven't fully gotten through it yet but other than that I think it is looking good | 21:58 |
| corvus | clarkb: replied (yeah, i waffled on dropping that but couldn't quite bring myself to do so, mostly so we keep all of those requirements in one place) | 22:11 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Add "supercedes" pipeline option https://review.opendev.org/670670 | 22:13 |
| SpamapS | corvus: get out of my head.. I was just thinking earlier today I wanted that supercedes option! | 22:15 |
| corvus | SpamapS: you should really clean up in here ;) | 22:18 |
| clarkb | corvus: ok properly through it now and noticed one other thing (comment inline) | 22:23 |
| openstackgerrit | James E. Blair proposed zuul/zuul master: Add "supercedes" pipeline option https://review.opendev.org/670670 | 22:24 |
| corvus | that adds more config validation | 22:24 |
| *** demeg0 has joined #zuul | 22:30 | |
| corvus | clarkb: replied with short essay :) | 22:38 |
| *** armstrongs has joined #zuul | 22:42 | |
| clarkb | corvus: that makes sense (re a third change and diffing against that) | 22:50 |
| *** michael-beaver has quit IRC | 22:57 | |
| *** mattw4 has quit IRC | 23:01 | |
| *** armstrongs has quit IRC | 23:15 | |
| *** tosky has quit IRC | 23:20 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!