Thursday, 2020-02-13

corvusand so i think what's happening with download plugin is that as changes merge to d-p master, since that doesn't match stable-3.0, the pointer from gerrit/stable3.0 to download-plugin does not advance (but the pointer in gerrit/master to download-plugin does advance)00:00
corvusso yeah, things are effectively "frozen" until either download-plugin gets a stable-3.0 branch and merges changes to it, or someone moves the submodule pointer manually00:00
mordredyah00:01
fungimaybe this helps them improve their coordination between repos00:02
mordredwhcih makes zuul dependencies hard to do anything with other than bail00:02
corvusmordred, fungi: yes to both00:03
*** Defolos has quit IRC00:09
*** sgw has joined #zuul00:17
*** wxy-xiyuan has joined #zuul00:46
*** sgw has quit IRC00:52
*** sshnaidm is now known as sshnaidm|afk01:20
*** jamesmcarthur has joined #zuul01:22
*** jamesmcarthur has quit IRC01:34
*** jamesmcarthur has joined #zuul01:41
*** bhavikdbavishi has joined #zuul01:52
*** bhavikdbavishi1 has joined #zuul01:55
*** bhavikdbavishi has quit IRC01:57
*** bhavikdbavishi1 is now known as bhavikdbavishi01:57
*** jamesmcarthur has quit IRC02:05
*** jamesmcarthur has joined #zuul02:11
*** jamesmcarthur has quit IRC02:40
*** jamesmcarthur has joined #zuul02:43
*** jamesmcarthur has quit IRC02:48
*** zxiiro has quit IRC02:54
*** jamesmcarthur has joined #zuul02:57
*** jamesmcarthur has quit IRC03:25
*** jamesmcarthur has joined #zuul03:27
*** rlandy|bbl is now known as rlandy03:29
*** jamesmcarthur has quit IRC03:55
*** jamesmcarthur has joined #zuul03:56
*** jamesmcarthur has quit IRC04:01
*** rlandy has quit IRC04:03
*** jamesmcarthur has joined #zuul04:26
*** igordc has joined #zuul04:37
*** igordc has quit IRC04:48
*** igordc has joined #zuul04:48
*** igordc has quit IRC04:48
*** raukadah is now known as chandankumar04:59
*** evrardjp has quit IRC05:34
*** evrardjp has joined #zuul05:34
*** swest has joined #zuul05:36
*** reiterative has quit IRC05:39
*** reiterative has joined #zuul05:39
*** sgw has joined #zuul05:53
openstackgerrityatin proposed zuul/zuul-jobs master: Ensure indirect deps are updated too  https://review.opendev.org/70756906:32
openstackgerritMerged zuul/zuul master: Don't report enqueue of non-live item  https://review.opendev.org/70747906:50
openstackgerritSimon Westphahl proposed zuul/zuul master: Ensure correct cleanup on repo update and reset  https://review.opendev.org/70153107:02
*** saneax has joined #zuul07:20
*** AJaeger has quit IRC07:35
*** AJaeger has joined #zuul07:38
*** Defolos has joined #zuul07:39
*** jpena|off is now known as jpena07:51
*** armstrongs has joined #zuul08:04
*** armstrongs has quit IRC08:13
*** hashar has joined #zuul08:14
*** tosky has joined #zuul08:19
openstackgerritTobias Henkel proposed zuul/zuul master: Make most test cases work on MacOS  https://review.opendev.org/70758508:41
openstackgerritTobias Henkel proposed zuul/zuul master: Reduce gearman logging in tests  https://review.opendev.org/70758708:52
*** mhu has joined #zuul09:11
openstackgerritFelix Schmidt proposed zuul/zuul master: Report retried builds in a build set via mqtt.  https://review.opendev.org/63272709:11
openstackgerritFelix Schmidt proposed zuul/zuul master: Report retried builds via sql reporter.  https://review.opendev.org/63350109:11
*** NBorg has joined #zuul09:25
*** avass has joined #zuul09:44
openstackgerritTobias Henkel proposed zuul/zuul master: Make most test cases work on MacOS  https://review.opendev.org/70758510:02
openstackgerritFelix Schmidt proposed zuul/zuul master: Report retried builds via sql reporter.  https://review.opendev.org/63350110:07
*** AJaeger has quit IRC10:10
*** AJaeger has joined #zuul10:11
fboHi, maybe someone could confirm, regarding provide/require for artifacts. Here https://src.fedoraproject.org/rpms/python-setuptools/pull-request/31 we see "Requirements ['repo'] not met by build defd1e2b60f6420faa59f4d2e51e575e" I guess it means a depends PR should have generated an artifact but in reality it has not. So I guess that the reason ?10:12
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Add support for tracing using OpenTelemetry  https://review.opendev.org/70517010:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Enable tracing of trigger events  https://review.opendev.org/70628910:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace Github webhook trigger events  https://review.opendev.org/70629010:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace Gerrit trigger events  https://review.opendev.org/70629110:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace timer trigger events  https://review.opendev.org/70760610:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace git trigger nevents  https://review.opendev.org/70760710:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace zuul trigger events  https://review.opendev.org/70760810:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace Pagure webhook trigger events  https://review.opendev.org/70760910:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace queue items  https://review.opendev.org/70761010:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace merge jobs (client)  https://review.opendev.org/70761110:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: Trace merge jobs (server)  https://review.opendev.org/70761210:26
openstackgerritSimon Westphahl proposed zuul/zuul master: wip: DNM test  https://review.opendev.org/70761310:26
openstackgerritTobias Henkel proposed zuul/zuul master: Add load-branch to tenant configuration  https://review.opendev.org/70566410:31
tobiashfbo: not necessarily a depends, a gate job that provides the artifact that resulted in a merge is sufficient10:49
tobiashfor introducing a provides/requires it might be needed to get the job that 'provides' merged first to get it working10:50
tobiashbut corvus knows that better10:50
fbotobiash: my testing regarding theprovide/require shown even not merged change can expose artifacts. See this example10:58
fboThis PR https://github.com/rpm-software-management/dnf/pull/1584 (last rpm-mock-build-source) in the inventory the artifact produced by the 'Depends-on: rpm-software-management/libdnf#896' is exposed11:00
fbotobiash: ^11:00
*** AJaeger has quit IRC11:04
*** hashar has quit IRC11:05
*** AJaeger has joined #zuul11:09
tobiashyes, you need just a provides job that ran before the requires job regardless if that's merged or not11:15
openstackgerritMatthieu Huin proposed zuul/zuul master: Add project, change in RequirementError message  https://review.opendev.org/70762011:17
fbothe behavior of zuul when an artifact is missing is to make the require job fail. but in my use case I would like prefer like a soft require that would have just added in the inventory that the artifact is missing. That way I could handle that case in the job.11:20
*** sshnaidm|afk is now known as sshnaidm|brb11:25
tobiashfbo: do you need the artifact within a buildset or from different changes?11:27
mhutobiash, from depends-on11:29
tobiashhrm, then a soft-requirement would be needed11:29
*** jpena is now known as jpena|lunch11:56
*** sshnaidm|brb is now known as sshnaidm11:56
fbotobiash: in fact from both, depends-on provide dependents 'rpms repo' artifacts to a buildset that run a parent job (that provide also a 'rpms repo' artifact) and child jobs require a 'rpms repo' artifact. But here https://src.fedoraproject.org/rpms/python-setuptools/pull-request/31#comment-37696 we see that childs jobs failed (even before the parent job run)12:05
*** rfolco has joined #zuul12:25
*** rlandy has joined #zuul13:00
*** jamesmcarthur has quit IRC13:12
*** jamesmcarthur has joined #zuul13:12
openstackgerritTobias Henkel proposed zuul/zuul master: Improve error reporting when pr merge fails  https://review.opendev.org/70763713:12
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: Run ensure-tox on all platforms  https://review.opendev.org/70723813:19
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: WIP: Make ensure-tox pass cross-platform  https://review.opendev.org/70743913:19
openstackgerritTobias Henkel proposed zuul/zuul master: Add foreground option  https://review.opendev.org/63564913:29
openstackgerritTobias Henkel proposed zuul/zuul master: Deprecate -d switch for running in foreground  https://review.opendev.org/70518513:29
openstackgerritTobias Henkel proposed zuul/zuul master: Don't enforce foreground with -d switch  https://review.opendev.org/70518913:29
*** jpena|lunch is now known as jpena13:29
*** jamesmcarthur has quit IRC13:38
*** Goneri has quit IRC13:40
*** Goneri has joined #zuul14:31
mordredcorvus: https://gerrit-review.googlesource.com/c/zuul/jobs/+/254752 is missing a change-id - which has shown me a gerrit behavior I'd never seen before!14:38
mordredcorvus: also - the second change has a typo, so if you decide to rectify the change-id in the first (not strictly necessary) - I'd go ahead and fix the second thing too14:39
mordredbut otherwise, both look great14:39
*** NBorg has quit IRC14:58
*** chandankumar is now known as raukadah14:59
*** rlandy is now known as rlandy|brb15:10
openstackgerritMonty Taylor proposed zuul/zuul master: Move oc download to before src copy  https://review.opendev.org/70725015:20
*** rlandy|brb is now known as rlandy15:26
*** saneax has quit IRC15:34
*** michael-beaver has joined #zuul15:53
*** zxiiro has joined #zuul15:58
*** Defolos has quit IRC16:02
*** Defolos has joined #zuul16:06
*** jpena is now known as jpena|off16:06
*** tosky has quit IRC16:21
corvusfbo, tobiash: a requires job should not fail if a provides job does not produce an artifact.16:36
*** Defolos has quit IRC16:36
fungithat's simply used for execution ordering the builds, right?16:38
fungiso that the requiring job doesn't run until the providing one finishes?16:38
fungithough obviously if the requiring job makes use of that provided artifact in some way then it could end up failing because the artifact wasn't available, but that's under control of the job itself16:39
corvusif the providing job failed though...16:39
corvusi'm trying to figure out exactly what's going on with the examples fbo linked16:40
*** jamesmcarthur has joined #zuul16:41
*** tosky has joined #zuul16:43
corvusfbo: it looks like this is the build that failed: https://fedora.softwarefactory-project.io/zuul/build/defd1e2b60f6420faa59f4d2e51e575e16:43
fbocorvus: yes, some of the depends-on change did not produced the expected artifact16:44
corvusfbo: the situation looks to me like this: a job on a change says it requires "repo" artifacts, the change depends on another change which runs jobs which provide "repo" artifacts, but that job failed.16:45
corvusfbo: well, it more than just didn't produce it -- the job that was supposed to produce it failed16:45
corvusthat really seems to me like the sort of case that zuul should not assume that it's okay not to have an artifact.16:45
corvus(it would be something else if the job that was supposed to produce it was skipped, or ran successfully but produced zero artifacts as a result)16:46
fungithough presumably the job could be made to still succeed if there are expected conditions under which the artifact can't be produced, and the requiring job has a reasonable fallback16:46
fungior basically what corvus just said16:47
corvusyeah.  it just seems like the one case where we couldn't say "it's okay not to have an artifact" is when the job producing it really does fail.16:47
fbocorvus ok but the failure let the user with a not human friendly info thus  https://review.opendev.org/70762016:47
mhucorvus, yeah that's a contingency we have, if the artifact doesn't exist we can rebuild it in the job that required it16:48
fbocorvus: ok but could we have a solution to still run the job but have this information (artifact missing) in thi sinventory16:48
mhucorvus, fbo: I was thinking of adding a "soft" option to requires, similar to job dependencies16:48
fungiif it's expected that the providing job sometimes doesn't produce an artifact, then why not just make it succeed under those circumstances?16:50
fungi(especially if you have a good way of detecting when non-production of an artifact is expected vs when it's not expected)16:51
corvusmhu: what happens with a soft dependency if the parent job fails?16:52
corvusmhu: i'm pretty sure the child job does not run16:52
corvusso i agree that it makes sense to look into situations where a requires job should still run even if a provides job doesn't provide an artifact, but if the provides job errors, that sounds really dangerous16:53
corvusis the use-case here opportunistic artifact caching?16:54
openstackgerritTobias Henkel proposed zuul/zuul master: WIP: Centralize merge handling  https://review.opendev.org/70769216:55
mhuyeah: if the artifact exists, use it, otherwise build it16:55
fboyes eventually that could be handled by the job itself. But yes, you are true corvus that's not safe. I need to think more about it.16:55
fbothe fact is today zuul returns a not obvious warning to the user16:56
mhubut the only case an artifact wouldn't exist is if the provides job didn't succeed16:56
fboMaybe better to have such a message "Unable to run jobs as depends artifacts are misssing for X Y Z projects"16:57
mhufbo: although it's true that you can search by build id in the web ui16:57
fbos/projects/changes/16:57
fungiexcept it didn't refuse to run because the artifact was missing, it refused to run because the job which would have provided that artifact did not succeed16:57
mhufungi, right16:57
corvusmhu: it could not exist because the job that produces it was intentionally not run.  yeah what fungi said16:57
fboyes16:58
corvusbasically the system was predicated on the idea that A depends on B, and if B doesn't get built, then A is invalid.  you seem to be describing a system where even if that's true, A can build both A and B.16:59
corvusi guess i don't understand why if B wasn't able to build itself, why would A have any better luck building B?17:00
corvusmhu, fbo: yes we should absolutely improve the messages.  even i find them confusing.  :)17:00
*** jamesmcarthur has quit IRC17:02
fboyes you're right. thanks to have clarified the issue :)17:03
mhuditto!17:03
*** jamesmcarthur has joined #zuul17:06
*** jamesmcarthur has quit IRC17:09
*** jamesmcarthur has joined #zuul17:15
openstackgerritMatthieu Huin proposed zuul/zuul master: Add project, change in RequirementError message  https://review.opendev.org/70762017:21
*** jpena|off is now known as jpena17:27
*** evrardjp has quit IRC17:34
*** evrardjp has joined #zuul17:34
*** jamesmcarthur has quit IRC17:47
*** jamesmcarthur has joined #zuul17:50
*** Defolos has joined #zuul17:59
*** bhavikdbavishi has quit IRC18:13
*** igordc has joined #zuul18:28
*** igordc has quit IRC18:28
*** adamw has quit IRC18:29
*** jpena is now known as jpena|off18:31
*** adamw has joined #zuul18:32
*** adamw has quit IRC18:32
*** adamw has joined #zuul18:32
corvusmordred: https://gerrit-review.googlesource.com/c/zuul/jobs/+/254994 is the repo setup from yesterday.  it has a configuration error in that it refers to a bunch of unknown projects.  but it got reported as "not relevant" because the config error caused no jobs to match.  it also didn't post the line comments about the error.18:36
corvusso i think there's some bugs there we should fix18:36
corvusi think line comments should always be posted, and config errors should probably be failure, not "not relevant"18:37
*** jamesmcarthur has quit IRC18:37
*** jamesmcarthur has joined #zuul18:38
mordredcorvus: yes - I agree with that18:39
*** jamesmcarthur has quit IRC18:44
corvusmordred: oh, hrm, it looks like it hit the not-relevant path because we haven't actually landed any changes which add the project to the check pipeline.18:48
corvusmaybe we should go ahead and land https://gerrit-review.googlesource.com/c/zuul/jobs/+/254752/118:49
openstackgerritJames E. Blair proposed zuul/zuul master: Report robot comments to gerrit  https://review.opendev.org/70770819:02
corvusmordred: that looks like that's why that didn't show up19:03
mordredcorvus: I merged the change, which felt very wrong19:29
corvusmordred: yeah, it's an icky feeling :)  i figure we should be able to gate those repos eventually.  just wanted to get gerrit-focused stuff going first19:40
mordred++19:40
mordredcorvus: https://gerrit-review.googlesource.com/c/zuul/jobs/+/254994/1/roles/prepare-gerrit-repos/README.rst is nicely written19:43
corvusmordred: thanks, i figured we probably needed to brain dump somewhere :)19:45
mordredcorvus: I look forward to pulling that role back in to zuul jobs and then using it for our own gerrit builds19:46
corvusmordred: you think that one should migrate?  i was thinking that should maybe live in gerrit's zuul.  i guess it probably only needs a little bit of generalization then it could be in zuul-jobs.  or we could pull gerrit/zuul/jobs into opendev's zuul19:47
corvusmordred: w00t!  https://gerrit-review.googlesource.com/c/zuul/jobs/+/254994 has comments now19:48
corvus(running with a locally built image to get the robot comments fix)19:48
mordredcorvus: hrm. yeah - maybe it doesn't need to be in zuul-jobs ... it's _similar_ to our pre-playbook, but in honestly the chances that we're going to need the error condition check in ours are *way* low19:50
mordredcorvus: I left a +2 with a nit comment in case you need to respin for other reasons19:51
fungithe "run details" link to the buildset info gives a blank page in the zuul dashboard... is that expected at this stage?19:52
fungihttps://gerrit-zuul.inaugust.com/t/gerrit/buildset/c47cf6a1c0324d509ffffd65d2d1e8b319:52
corvusfbo: yeah, i would describe that as an "expected bug".  no builds reported since the config was invalid, so there's no buildset record in the db.  we should do something different, but i'm unsure what.19:53
corvusfungi: sorry fbo19:53
corvusmordred: https://gerrit-review.googlesource.com/c/zuul/ops/+/255012  is the next step19:57
mordredcorvus: do we have any more cores? or should I just straight approve things?19:58
corvusmordred: i think the gerrit maintainers are included too, but i think we should probably just approve that one20:00
corvusi'll make sure to mention it in my report so that people can see the whole process (including the changes we haad to merge)20:00
mordredkk20:01
fungioh, right-o20:01
fungiit didn't run anything20:01
fungiwell, didn't run any builds anyway20:01
corvusyeah. i think the first obvious step would be to report that as a null url.  but maybe long-term after the db rework we can have buildsets with no builds20:01
corvuscause that's a thing internally in zuul.  that buildset has the result "CONFIG_ERROR".  it's not crazy to think that visualizing that in the zuul web ui would be useful.20:02
corvusmordred: an interesting thing happened on the gerrit zuul.  the scheduler lost its zk connection in a way that seemed permanent21:13
corvusalso, the debug log is completely spammed with refs from the additional repos.  so my first step in addressing this problem is rejiggering the io debug logging a bit so "-d" is more sensible and maybe we can actually tell what's going on if it happens again.21:14
mordredcorvus: oh weird - and yeah - that is an interesting thing21:21
mordredcorvus: it's running in a GKE - I wonder if the containers are co-located such that zuul noisy-neighbored itself enough to make the zk unhappy21:22
mordred(just thinking out loud)21:22
corvusmordred: yeah, could be, or maybe some migration thingy happened or something21:23
mordredyeah21:24
mordredas you said - mo bettah logging21:24
mordredand by mo, I mean less21:24
openstackgerritJames E. Blair proposed zuul/zuul master: Adjust io-level logging in gerrit/git drivers  https://review.opendev.org/70772821:28
corvusmordred: ^ more lessness21:28
*** dpawlik is now known as dpawlik_off21:30
corvusmordred: potentially related, i see "end of stream" sometimes when watching the console streaming.  it's not ended, and it resumes (by starting over again).  i wonder if some intra-k8s connection for the log streamer is getting interrupted?21:36
corvustristanC, tobiash, SpamapS: ^ ever seen anything like that?21:37
*** avass has quit IRC21:53
openstackgerritJames E. Blair proposed zuul/zuul master: Gerrit checks: trigger new patchset behavior  https://review.opendev.org/70772922:01
*** sshnaidm is now known as sshnaidm|afk22:21
openstackgerritMerged zuul/zuul master: Report robot comments to gerrit  https://review.opendev.org/70770822:28
tristanCcorvus: i've not seen that. could it be the inbound that drop long websocket connection?22:50
*** Goneri has quit IRC22:51
SpamapScorvus: yes, I've seen it a few times when my connection was wonky, like on a train tethered.22:51
SpamapSI believe that it's an exception bubbling up from the streaming code.22:51
SpamapSShould not blank an existing stream, and it should also not say "END OF STREAM" but probably something like a spinner.22:52
corvustristanC: yeah, and that seems to jive with SpamapS's observation22:53
corvusi don't see that watching opendev streams, so maybe something about my terminal <-> GKE is the issue22:53
SpamapSwebsocket timeouts would explain it too22:53
corvusor the particular configuration of the load balancer22:53
corvusin fact, that's probably the place to start looking22:54
SpamapSLike, if the LB has a lower timeout than the server, you'll get dropped websocket conns when there's no output.22:54
SpamapSI raised my websocket timeout to 30 minutes.22:54
corvusSpamapS: yep.  and i haven't paid attention to that at all :)22:54
SpamapS(on the origin).. but I don't know what it is on my LB.22:55
corvusi was just really happy i convinced GKE to make the right kind of load balancer at all.  :)22:55
SpamapSyeah, maybe GKE's LB's have short websocket timeouts.22:55
SpamapSIt might make sense to change the streaming code to send empty messages if nothing sends for more than 60s or something.22:55
SpamapSoh websocket has ping/pong22:56
corvusSpamapS: gke lb websocket timeout is 30s by default!22:56
corvusso that's almost certainly the problem.  i'll look into fixing that, and hopefully we can also do a ping as well22:57
SpamapSyep22:57
corvusoh wow, it's actually not even an idle timeout.  it's just 30s max connection length.23:04
corvuslooks like *all* i need to do is create a BackendConfig then annotate the Service with the BackendConfig name then bob's my uncle23:08
corvusmordred: looks like https://gerrit-review.googlesource.com/c/zuul/jobs/+/254994 is working now23:08
fungimake sure you double-check with bob on that though23:09
corvusfungi: you are not going to let us leave today without a msft bob joke are you?23:10
fungihe was such a cute doggo though23:11
fungii guess rover was the dog23:12
*** paladox|UKInEU has quit IRC23:14
fungihuh, i never knew (or conveniently forgot) this, per wikipedia anyway: "The typeface Comic Sans was created for (but not used in) Microsoft Bob."23:14
fungii'm sure there's a good comic sans joke somewhere in that, it's just too late in the day for me to tease it out23:15
corvusfungi: really?  i thought it was created, for, well, comics23:15
*** paladox has joined #zuul23:17
fungiwp's citation goes to an interview with the creator of the microsoft font file for it, anyway23:17
fungiwho claims that's what he created it for23:17
fungigranted, this is on the internet, so who knows really23:18
*** rlandy is now known as rlandy|bbl23:30
*** wxy-xiyuan has quit IRC23:35
corvusmordred, paladox: https://ci.gerritcodereview.com/ is live23:45
paladoxohhhh23:45
paladoxwooooo!23:45
paladoxcorvus <323:46
fungiit's running jobs!!!23:53
* fungi stares intently at the test-gerrit-base output stream23:54
*** Defolos has quit IRC23:54
fungithis is *so* cool23:54
paladoxindeed, it's awesome!23:55

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