| *** dmellado_ has joined #zuul | 00:07 | |
| *** dmellado has quit IRC | 00:11 | |
| *** dmellado_ is now known as dmellado | 00:11 | |
| *** marios has joined #zuul | 05:12 | |
| *** swest has joined #zuul | 05:36 | |
| *** jpena|off is now known as jpena | 07:33 | |
| opendevreview | Simon Westphahl proposed zuul/zuul master: Remove layout attribute from queue items https://review.opendev.org/c/zuul/zuul/+/792622 | 07:53 |
|---|---|---|
| opendevreview | Simon Westphahl proposed zuul/zuul master: Optimize layout re-calculation after re-enqueue https://review.opendev.org/c/zuul/zuul/+/792623 | 07:53 |
| opendevreview | Simon Westphahl proposed zuul/zuul master: Remove layout attribute from queue items https://review.opendev.org/c/zuul/zuul/+/792622 | 08:00 |
| opendevreview | Simon Westphahl proposed zuul/zuul master: Optimize layout re-calculation after re-enqueue https://review.opendev.org/c/zuul/zuul/+/792623 | 08:00 |
| *** rpittau has joined #zuul | 08:24 | |
| *** ttx has joined #zuul | 09:15 | |
| *** tosky has joined #zuul | 10:09 | |
| *** jpena is now known as jpena|lunch | 11:31 | |
| *** jangutter has joined #zuul | 12:08 | |
| opendevreview | Simon Westphahl proposed zuul/zuul master: Show pipeline event queue lengths in Zuul web https://review.opendev.org/c/zuul/zuul/+/793781 | 12:23 |
| *** jpena|lunch is now known as jpena | 12:32 | |
| mhu | Hello zuul-maint, here's a simple fix in zuul-client's doc: https://review.opendev.org/c/zuul/zuul-client/+/789007 | 12:45 |
| mhu | zuul-maint, here's also support for builds & buildsets querying in the CLI: https://review.opendev.org/c/zuul/zuul-client/+/751070 https://review.opendev.org/c/zuul/zuul/+/758783 https://review.opendev.org/c/zuul/zuul-client/+/752909 https://review.opendev.org/c/zuul/zuul/+/758985 | 12:51 |
| *** measure20[m] has left #zuul | 13:03 | |
| opendevreview | Matthieu Huin proposed zuul/zuul-client master: Add support for XDG-compliant config file https://review.opendev.org/c/zuul/zuul-client/+/793796 | 13:45 |
| mhu | swest, what are the event queue lengths for (re: https://review.opendev.org/c/zuul/zuul/+/793781 ) - I'm looking at the openstack tenant status page and all the lengths are set to 0 regardless of what's currently in the pipelines | 13:51 |
| swest | mhu: it's showing the length of the pipeline event queues in Zookeeper. if there are no unprocessed event the length is expected to be 0 | 13:54 |
| fungi | right, on opendev you'll see those spike up when there are bursts of reviews submitted or changes merged which cause events or results to queue up awaiting processing, but that's independent of the pipeline queues | 14:01 |
| fungi | they represent internal fifo queues zuul keeps potential triggering conditions in until it has a chance to evaluate them to find out if it should enqueue or report something | 14:03 |
| swest | I'm just not sure though if we want to display this as prominently as in my proposal. I'm open to other ideas | 14:03 |
| mhu | ok thanks that explains it. I think it deserves at least a mention of Zookeeper or some similar kind of explanation, as it might be confusing as is | 14:05 |
| fungi | it mostly tends to come up when people looking at the status page are scratching their heads wondering why a change they pushed hasn't shown up in any queue yet, or why there's an item which has completed all its builds but is still just sitting in a pipeline with nothing ahead blocking it from merging | 14:05 |
| fungi | those are generally represented by one or more conditions held in the events or results queues | 14:05 |
| fungi | (a gerrit patchset-uploaded event, an internal buildset completion event...) | 14:06 |
| mhu | I think the confusion also stems from the use of the term "queue" in dependent pipelines themselves, IIUC these are completely different concepts | 14:09 |
| fungi | yes, different class of queue, but they still are both first-in/first-out queue structures | 14:12 |
| fungi | the other common term is "pipe" but we already have pipelines so that could also get confusing | 14:13 |
| *** y2kenny has joined #zuul | 14:18 | |
| fungi | on a different topic, anybody happen to know if there is weirdness around builds not seeing configuration changes when the zuul config file is updated by a merge commit which has been pushed for review? i have an example where someone changed a nodeset on the master branch of their project, then proposed a merge from master to a feature branch, and the builds for that did not use the new nodeset. | 14:18 |
| fungi | i downloaded the merge commit change and confirmed the changed nodeset value does appear in my local tree, and the build inventory indicates (in its inheritance path) that the job definition was taken from the branch that merge commit is being proposed to. also the project is just a normal untrusted project so it shouldn't be anything to do with config project protections | 14:18 |
| y2kenny | Hi, I noticed the latest zuul-launcher on docker hub is still 4.1.0 (https://hub.docker.com/r/zuul/nodepool-launcher/tags?page=1&ordering=last_updated) is that intentional? | 14:39 |
| fungi | y2kenny: it has a different checksum than the 4.1.0 image | 14:40 |
| avass[m] | y2kenny: nodepool doesn't sync it's releases with zuul | 14:41 |
| fungi | we generally keep the major version number the same between them, but yes the minor versions can be (and often are) different | 14:42 |
| fungi | and the latest version of nodepool is indeed 4.1.0 | 14:43 |
| fungi | but the "latest" tag there i think represents commits after nodepool's 4.1.0 tag | 14:43 |
| avass[m] | yeah | 14:43 |
| *** timburke has joined #zuul | 14:50 | |
| *** ricolin has joined #zuul | 15:00 | |
| y2kenny | fungi, avass[m]: ok thanks. | 15:04 |
| opendevreview | Matthieu Huin proposed zuul/zuul-client master: Clarify ~/.zuul.conf and --use-config option spelling https://review.opendev.org/c/zuul/zuul-client/+/789007 | 15:05 |
| opendevreview | Matthieu Huin proposed zuul/zuul-client master: Add support for XDG-compliant config file https://review.opendev.org/c/zuul/zuul-client/+/793796 | 15:05 |
| corvus | swest, mhu: maybe we should drop the queue lengths to the bottom of the page to indicate they are more 'system status' types of info | 15:15 |
| corvus | fungi: yes, i have observed the same in gerrit's gerrit; a full reconfiguration will be needed for zuul to see the update | 15:16 |
| fungi | corvus: full reconfiguration will cause it to notice the changed configuration in the merge commit and apply it, or you mean it needs to be backported separately and merged before the merge commit is proposed? | 15:17 |
| mhu | corvus: yes, and maybe have a "show/hide FIFO queue statistics" button or something like that | 15:18 |
| mhu | as it seems to be some advanced, "under the hood" kind of info | 15:19 |
| fungi | if it's embedded in the page footer with the version info or something, i don't know that it needs a toggle | 15:19 |
| fungi | at least in opendev it's not advanced under the hood information, we have to point our users to it on a regular basis | 15:20 |
| mhu | fungi, swest added queue info for every pipeline though | 15:20 |
| fungi | ahh, okay | 15:20 |
| corvus | i haven't reviewed the ui change yet; so i'm only speaking in generalities | 15:25 |
| *** dmsimard has joined #zuul | 15:25 | |
| corvus | fungi: er, i mean that after the merge commit merges, a full reconfiguration will be needed for zuul to adopt the changes | 15:26 |
| corvus | nothing will make it notice the change behind the merge commit | 15:26 |
| fungi | corvus: got it, so if they want zuul configuration changes from master to take effect in a feature branch, they'll need to separately backport those as a parent of the proposed merge? | 15:30 |
| corvus | yeah that should work | 15:30 |
| guillaumec | fungi: corvus I have 2 patches for that: https://review.opendev.org/c/zuul/zuul/+/762886/ https://review.opendev.org/c/zuul/zuul/+/762887 | 15:31 |
| guillaumec | ie: configuration changes with merge commits | 15:32 |
| corvus | gchauvel: nice, thanks! | 15:32 |
| guillaumec | they both need some rework, they are no longer mergeable :) | 15:33 |
| *** rpittau is now known as rpittau|afk | 16:07 | |
| *** mnaser has joined #zuul | 16:40 | |
| *** marios has quit IRC | 16:40 | |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: WIP test stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 16:42 |
| *** jpena is now known as jpena|off | 16:45 | |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: WIP test stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 16:46 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: WIP test stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 17:01 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: WIP test stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 17:13 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: WIP test stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 17:24 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Handle no-sudo in stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 17:35 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Tidy up file matcher for bindep jobs https://review.opendev.org/c/zuul/zuul-jobs/+/793834 | 17:41 |
| corvus | zbr: ^ you added the line i'm proposing we remove there; i suspect it was either a copy-pasta or was from before zuul automatically ran jobs with changed definitions. can you confirm? | 17:42 |
| *** opendevreview has quit IRC | 17:47 | |
| avass[m] | corvus: I generally try to avoid setting facts unless I need to since it can cause issues for subsequent roles if they use a variable with the same name since ansible has no scopes. There can also be variables set with higher precedence so set_fact won't work (see: https://opendev.org/zuul/zuul-jobs/commit/6f2ff3f1b8aa899d2a01d73e7de081ce5f9cffcd), now that's true for registered variables too but I try to avoid that by following python private | 18:31 |
| avass[m] | variable conventions (`_have_sudo` instead of `have_sudo`). | 18:31 |
| corvus | oh yeah, i forgot we have a rule, that should be called "zjhavezudo" i think | 18:32 |
| avass[m] | I don't think we have a rule for that, the `zj_` prefix is for loop variables and we have a linting rule for that | 18:32 |
| corvus | oh that may have eaten underscores | 18:32 |
| corvus | hrm, you're right, that is only for loops | 18:32 |
| corvus | avass: sounds like a good addition to https://zuul-ci.org/docs/zuul-jobs/policy.html :) | 18:33 |
| avass[m] | I think I already started on it somewhere :) | 18:34 |
| corvus | avass: but in the mean time, sounds like you suggest we should either give that var a tail, or just use the result expression in those 3 places and skip the set fact? | 18:34 |
| *** opendevreview has joined #zuul | 18:36 | |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Handle no-sudo in stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 18:36 |
| avass[m] | yeah, maybe even giving the registered variable a tail since that would also be affected, so `_sudo_result` | 18:36 |
| corvus | avass: ^ i chose skipping set_fact because it eliminates a task :) | 18:36 |
| avass[m] | an earlier set_fact: sudo_result would take precedence over a registered sudo_result and would be annoying to debug :) | 18:38 |
| corvus | avass: of course the same would be true for sudoresult :) | 18:38 |
| avass[m] | though _sudo_result would have the same issue if set as a fact and registered. | 18:38 |
| corvus | avass: i feel like this is a can of worms that may be worth opening (maybe we should name-scope all our variables), but maybe we could draw the line somewhere so my patch doesn't get caught up in it? i'd draw the line at "consistent with the rest of the file and doesn't add any new potentially tricky usages" | 18:39 |
| corvus | which is coincidentally what i just uploaded ;) | 18:40 |
| corvus | avass: but if you feel we should start doing something else for all new variables, i'm happy to change it | 18:40 |
| avass[m] | yeah, my rule of thumb is to just not set facts unless needed (usually when it needs to persist across playbooks) | 18:40 |
| *** measure20[m] has joined #zuul | 18:47 | |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Handle no-sudo in stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 18:55 |
| avass[m] | corvus: you can actually do that without registering sudo_result | 18:56 |
| avass[m] | but I don't think I like it :) | 18:56 |
| corvus | heh, okay. it sounds scary. :) | 18:57 |
| corvus | avass: are you ok with that version of the patch? or do you want me to add the tail or do "stageoutputsudoresult" ? | 18:57 |
| avass[m] | I'm fine with it | 18:57 |
| corvus | grr, sorry... should i _stage_output_sudo_result ? | 18:57 |
| corvus | ok, i'll leave it as is, and now i know how to type underscores :) | 18:58 |
| avass[m] | I'm mostly just trying to figure out how to avoid this if in the future we have hundreds of variables sprinkled in the all roles that could lead to hard to trace bugs for people downstream | 18:59 |
| avass[m] | current idea is to somehow use block/rescue | 18:59 |
| avass[m] | but namespacing variables is probably nicer and easier | 19:00 |
| corvus | maybe we could put all vars in a dict with a unique name; like setfact _zjstageoutput: {}; then access _zjstageoutput.sudoresult | 19:01 |
| corvus | i forgot to quote that again | 19:01 |
| corvus | * maybe we could put all vars in a dict with a unique name; like set_fact `_zj_stage_output: {}`; then access `_zj_stage_output.sudo_result` | 19:01 |
| avass[m] | in that case it's seems easier to just do `_zj_stage_output_sudo_result` or `_stage_output_sudo_result` | 19:03 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Tidy up file matcher for bindep jobs https://review.opendev.org/c/zuul/zuul-jobs/+/793834 | 19:03 |
| corvus | probably. though the dict gets you one-stop initialization in case there's an existing var conflict. | 19:04 |
| corvus | the risk may not be worth the extra typing though | 19:04 |
| avass[m] | in that case the question is if we want to fail if anything collides or try our best to run the role anyway? | 19:09 |
| avass[m] | is it possible to register variables in a dict? | 19:09 |
| avass[m] | doesn't look like it: `Invalid variable name in 'register' specified: 'my_var.a'` | 19:10 |
| corvus | then nevermind :) | 19:16 |
| opendevreview | Matthieu Huin proposed zuul/zuul-client master: Add support for XDG-compliant config file https://review.opendev.org/c/zuul/zuul-client/+/793796 | 19:26 |
| *** opendevreview has quit IRC | 19:48 | |
| *** opendevmeet has joined #zuul | 19:53 | |
| avass[m] | curl apparently has issues with travisCI new open source policies: https://github.com/curl/curl/issues/7150 | 19:54 |
| avass[m] | mnaser: oh I see you've already commented :) | 19:55 |
| *** timburke has quit IRC | 22:15 | |
| *** opendevreview has joined #zuul | 22:40 | |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Handle no-sudo in stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 22:40 |
| corvus | ianw: ^ | 22:41 |
| ianw | corvus: become: "{{ not sudo_result.failed }}" won't be true now because the task won't have failed? might have to check return code? | 22:44 |
| corvus | hrm maybe | 22:45 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Handle no-sudo in stage-output https://review.opendev.org/c/zuul/zuul-jobs/+/793829 | 22:48 |
| corvus | ianw: testing should catch that sort of thing now at least :) | 22:48 |
| ianw | yep! thanks, that looks correct to the slightly unreliable ansible interpreter in my head :) | 22:49 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Tidy up file matcher for bindep jobs https://review.opendev.org/c/zuul/zuul-jobs/+/793834 | 22:52 |
| *** tosky has quit IRC | 22:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!