Friday, 2024-04-26

-@gerrit:opendev.org- Christian Mueller proposed: [zuul/nodepool] 916801: WIP: Enable usage of EC2 Fleet API https://review.opendev.org/c/zuul/nodepool/+/91680107:38
-@gerrit:opendev.org- Cedric Jeanneret proposed: [zuul/zuul-jobs] 917118: Toggle synchronize to "quiet" mode https://review.opendev.org/c/zuul/zuul-jobs/+/91711808:36
-@gerrit:opendev.org- Felix Edel proposed:10:33
- [zuul/zuul] 916284: Implement new status page https://review.opendev.org/c/zuul/zuul/+/916284
- [zuul/zuul] 916285: Make helper functions available to other components https://review.opendev.org/c/zuul/zuul/+/916285
- [zuul/zuul] 916286: Implement QueueItemPopover https://review.opendev.org/c/zuul/zuul/+/916286
- [zuul/zuul] 916287: Implement PipelineDetails view https://review.opendev.org/c/zuul/zuul/+/916287
- [zuul/zuul] 916288: Sort pipelines on status page by number of queue items https://review.opendev.org/c/zuul/zuul/+/916288
- [zuul/zuul] 916289: Align QueueItem and QueueItemPopover https://review.opendev.org/c/zuul/zuul/+/916289
- [zuul/zuul] 916290: Align job progress bars and job result labels https://review.opendev.org/c/zuul/zuul/+/916290
- [zuul/zuul] 916744: Visualize branches in ChangeQueues https://review.opendev.org/c/zuul/zuul/+/916744
- [zuul/zuul] 916867: Implement admin actions (promote, dequeue) in new QueueItem component https://review.opendev.org/c/zuul/zuul/+/916867
- [zuul/zuul] 916973: Show queue lengths and fetching state on status page https://review.opendev.org/c/zuul/zuul/+/916973
- [zuul/zuul] 916974: Add switch to show/hide empty pipelines and queues https://review.opendev.org/c/zuul/zuul/+/916974
- [zuul/zuul] 917039: Add support for dark mode to new status view components https://review.opendev.org/c/zuul/zuul/+/917039
-@gerrit:opendev.org- Stephen Finucane proposed:12:57
- [zuul/zuul] 917138: reporter: Add JobStatus namedtuple https://review.opendev.org/c/zuul/zuul/+/917138
- [zuul/zuul] 917139: Use markdown tables in reporter https://review.opendev.org/c/zuul/zuul/+/917139
-@gerrit:opendev.org- Stephen Finucane proposed: [zuul/zuul] 917139: reporter: Use markdown tables https://review.opendev.org/c/zuul/zuul/+/91713912:58
-@gerrit:opendev.org- Albin Vass proposed wip: [zuul/zuul-jobs] 764808: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/76480814:04
@jpew:matrix.orgWould someone mind looking at https://review.opendev.org/c/zuul/zuul/+/914818 ? We'v had users complain that when they apply any comment on a failed gate it re-gates because Zuul is seeing all the scores instead of just the score changes. Thanks14:20
@jpew:matrix.org * Would someone mind looking at https://review.opendev.org/c/zuul/zuul/+/914818 ? We'v had users complain that when they post any comment on a failed gate it re-gates because Zuul is seeing all the scores instead of just the score changes. Thanks14:20
@clarkb:matrix.orgjpew: I guess you don't use an explicit approval vote? We actually want the exact opposite because we do and changing the behavior requires reviewers to remove their vote and then add it again when they want to rerun the gate. In our case it's better to process what votes are there and have people be explicit when voting (eg remove votes if they don't want gating) than force them to do needless busy work14:35
@jpew:matrix.orgClark: We do have an approval vote, but it's controlled by the gerrit OWNERS plugin. The problem isn't that we want users to be toggling scores to trigger a gate, it's that _any_ comment on a change that already has all the scores will regate it. We'd prefer that it only trigger on an explicit "regate" comment, but that doesn't work because Zuul just sees all the scores are present and regates it, even if that's not the intention of the user leaving the comment. The patch allows us to fix that because it will only (re-)gate if the score changes (e.g. when it's first applied) _or_ when the "regate" comment is given and _not_ on any comment that doesn't change a score. The current behavior is the one that actually causes us extra work, because if you want to leave a regular comment on a failed gate, you have to remove scores, otherwise it regate. This is confusing behavior for our users14:42
@jpew:matrix.orgHere is our pipeline config currently for reference:14:47
```yaml
require:
gerrit:
open: True
approval:
- Approve-Change: 1
- Code-Review: 2
- Allow-CI: 1
reject:
gerrit:
approval:
- Approve-Change: -1
trigger:
gerrit:
# Trigger a gate on either a +2 CR comment -or- a +1 AC comment -or- a
# +1 ACI comment. This allows different users to provide the scores,
# and it will still trigger the gate (note that the pipeline
# requirements above are still enforced to queue the change)
- event: comment-added
approval:
- Code-Review: 2
- event: comment-added
approval:
- Approve-Change: 1
- event: comment-added
approval:
- Allow-CI: 1
- event: comment-added
comment: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*regate
```
@jpew:matrix.orgNote that the `regate` comment is actually useless because any comment will trigger a regate14:48
@jpew:matrix.orgAnd also the `require.approval` is actually an anacronism now that https://review.opendev.org/c/zuul/zuul/+/915449?forceReload=true is merged (thanks!). We can just rely on the is mergable logic in gerrit instead14:49
@jpew:matrix.org * Note that the `regate` comment trigger is actually useless because any comment will trigger a regate14:55
@vonschultz:matrix.orgI'm having problems with my executors in Zuul 10.1.0. They worked fine with Zuul 10.0.0. The error is `ZeroDivisionError: float division by zero` and it comes from15:06
```
File "/usr/local/lib/python3.11/site-packages/zuul/executor/sensors/hdd.py", line 30, in get_avail_hdd_inode_pct
files_percent = (files_used / s.f_files) * 100
~~~~~~~~~~~^~~~~~~~~~~
```
For context, we have
```
>>> os.statvfs('/var/lib/zuul')
os.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=52428539, f_bfree=50959902, f_bavail=50560135, f_files=0, f_ffree=0, f_favail=0, f_flag=4096, f_namemax=255)
```
with `/var/lib/zuul` backed by a btrfs filesystem.
@clarkb:matrix.org> <@jpew:matrix.org> Note that the `regate` comment trigger is actually useless because any comment will trigger a regate15:16
Hrm this isn't the case for us I wonder what is different.
@clarkb:matrix.orgReading your pipeline config I think it is because you allow any +2 to enter the gate if anyone else has approved it. We only gate if the vote is for appeovals15:20
@clarkb:matrix.orghttps://opendev.org/opendev/project-config/src/branch/master/zuul.d/pipelines.yaml#L4715:21
@clarkb:matrix.orgThen if I don't want things to regate I remove my approval 15:21
@jpew:matrix.orgClark: Ya, that makes sense. But for scaling reasons, we would like each score to be more or less applied independently15:22
@jpew:matrix.orgOur Allow-CI score is the "This can be gated" score applied by the change owner; Sometimes they want to apply that before the CR and AC, so that it will just gate when those are done, and sometimes they want to do it after the review.15:24
@clarkb:matrix.orgya ok so a different workflow with different expectations on state transitions.15:44
@jim:acmegating.comChristian von Schultz: looks like btrfs doesn't have inodes; feel free to submit a patch to skip that check if it's 015:50
-@gerrit:opendev.org- Christian von Schultz proposed: [zuul/zuul] 917169: Catch ZeroDivisionError when f_files=0 https://review.opendev.org/c/zuul/zuul/+/91716915:56
@vonschultz:matrix.orgI suppose the simplest thing to do would be to just catch the error and move on. 917169: Catch ZeroDivisionError when f_files=0 | https://review.opendev.org/c/zuul/zuul/+/91716915:59
But I wonder if something more intelligent is in order. There's no need to publish statsd metrics about something that doesn't exist. Like, should these be disentangled further, into `HDDSensor` and `InodeSensor` or similar? Or just try to update the `HDDSensor` to not do unnecessary things when there's no inode information?
@jim:acmegating.comChristian von Schultz: i agree with both: that is sufficient, and you could optionally also disable the stats if it's 0.  keep them one sensor though for efficiency.16:02
@clarkb:matrix.orgcorvus: there was a change recently to fine tune Zuul's handling of Gerrit ref-updated events. Gerrit 3.9 complicates this even further: https://www.gerritcodereview.com/3.9.html#new-stream-events17:45
@clarkb:matrix.orgI suspect that zuul will handle this just fine, except that we may add new noise to the mix that we want to tune out similar to the recent change that handled change metadata updates17:45
@jim:acmegating.comClark: agreed, maybe we should get the jump on that and add that now17:46
@clarkb:matrix.orgthough zuul is already going to ignore All-Projects/All-Users so maybe that is sufficient for the draft comments stuff. The batch ref updates would be the only concern then17:47
@clarkb:matrix.orglooks like the default is to not batch ref updates, but zuul should probably handle installations that opt into doing so17:48
@jim:acmegating.comoh that doesn't sound so bad then; i think i need to understand more what the batch refupdate is.17:49
@clarkb:matrix.orgI've got a held gerrit for opendev upgrade testing/prep you're welcome to edit the config there to enable batch refs if that is helpful17:50
@clarkb:matrix.orgotherwise I'll try to look at this closer as I figure out what needs to be done for opendev's upgrade17:50
@jim:acmegating.comClark: i think the question i have is what refs are included in a batch?17:52
@jim:acmegating.comlike, could we get a batch-refupdated event for multiple branch heads being updated at once?17:53
@clarkb:matrix.orgya and if they are relevant ref updates to zuul then we need to have zuul handle that event type17:53
@jim:acmegating.com(if it does happen, does it only happen during replication?  if it does happen, and it's emitted as part of replication, does that only happen after individual ref-update events were already emitted for the original updates?)17:54
@clarkb:matrix.orgI think replication batching has some clues to that. There are certain actions in the web ui for example (I forget which unfortauntely) that result in several refs being updated at basically the same time. Those would probably be sent as a batch ref update17:54
@clarkb:matrix.orglooks like the example in the linked issue (from the release notes) has to do with pushing updates to multiple changes as once17:55
@clarkb:matrix.organd that makes me suspect that zuul would need to be aware of the new event type to process all of the relevant events for those updates that may be batched17:56
@jim:acmegating.combut we only care about ref-updates for non-change items18:14
@jim:acmegating.com * but we only care about ref-updates for non-change items (eg branch heads)18:15
@clarkb:matrix.orgya I suspect that openstack creating a new stable branch across many repos may end up with batched ref updated events. Though I don't know for sure18:19
@clarkb:matrix.orgsimilar with tagging releases all at a similar time (and again the default is the old behavor so this isn't urgent from what I can see. Just seems like somethign we will need to address eventually for the general case)18:20
-@gerrit:opendev.org- Zuul merged on behalf of Christian von Schultz: [zuul/zuul] 917169: Catch ZeroDivisionError when f_files=0 https://review.opendev.org/c/zuul/zuul/+/91716920:46
-@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Simon Westphahl: [zuul/zuul] 917052: Fix issue with reopened PR dependencies https://review.opendev.org/c/zuul/zuul/+/91705221:20

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!