| opendevreview | Tony Breeds proposed openstack/election master: Update job config. https://review.opendev.org/c/openstack/election/+/891818 | 15:05 |
|---|---|---|
| opendevreview | Tony Breeds proposed openstack/election master: Update job config. https://review.opendev.org/c/openstack/election/+/891818 | 15:07 |
| tonyb | ianychoi[m]: Do you want to update the election_open template to prevent the confusion? | 15:19 |
| ianychoi[m] | Hi tonyb, does it mean kickoff notice to the mailing list, or template content on the election repo? | 15:22 |
| tonyb | ianychoi[m]: I was thinking about the template, it looks like there was an issue with the timeline? | 15:23 |
| ianychoi[m] | Ah, no issues on the template - very strangely I wrongly interpreted time zone. It is more related into my wrong interpretation on reading time zones | 15:25 |
| tonyb | Ahh okay. | 15:25 |
| tonyb | ianychoi[m]: if you wouldn't mind reviewing 891818 that'd be good. It shoudl fix the pep8 failure/issue | 15:26 |
| tonyb | which will unblock the other candidates (I think) | 15:26 |
| ianychoi[m] | Thank you tonyb on this! Waiting for +1 on Zuul :) | 15:28 |
| tonyb | Yeah it's kinda backed up right now | 15:28 |
| tonyb | https://zuul.openstack.org/status#election all jobs queued but there are 137 jobs i the queue/pipeline | 15:29 |
| ianychoi[m] | So far jobs are building with pass well | 15:48 |
| ianychoi[m] | I can get back after several hours. I have reviewed based on current status, and will look once I am get back. imo it can go forward once Zuul jobs are passed | 15:50 |
| opendevreview | Artem Goncharov proposed openstack/election master: Add Artem Goncharov candidacy for OpenStackSDK PTL https://review.opendev.org/c/openstack/election/+/891865 | 15:52 |
| fungi | https://grafana.opendev.org/d/21a6e53ea4/zuul-status indicates we have a backlog of node requests and have been running around max capacity since about an hour ago when the pending request count began to rise | 15:55 |
| tonyb | Oh dear | 16:08 |
| tonyb | gmann: (as noted on the review) we run pep8 (well flake8) as part of the linters target. which is why we don't have pep8. | 16:09 |
| tonyb | It's wasteful to have 2 separate jobs (nodes) for such lightweight work | 16:09 |
| gmann | tonyb: ohk I did not see that, where we run those flake8 ? | 16:19 |
| tonyb | for example: https://zuul.opendev.org/t/openstack/build/90f135c5890b47d18557835a9cee6296/log/job-output.txt#7416 | 16:20 |
| gmann | tonyb: maybe commit msg can be updated as it was confusing to me thinking we do not need those pep8/flak8 checks run | 16:21 |
| gmann | yeah, checked now. thanks | 16:21 |
| tonyb | https://opendev.org/openstack/election/src/branch/master/tox.ini#L18-L20 | 16:21 |
| gmann | yeah | 16:22 |
| tonyb | With the long check pipeline I'd rather not update the commit message. | 16:22 |
| opendevreview | Felipe Reyes proposed openstack/election master: Add Felipe Reyes candidacy for OpenStack Charms https://review.opendev.org/c/openstack/election/+/891868 | 16:22 |
| gmann | tonyb: but commit message it not right. it convey that pep8 does not work and fail on eletion repo and we do not need these checks | 16:23 |
| gmann | that is why I got confused before you pinged about linters target | 16:23 |
| tonyb | No it says we don't have a pep8 [tox] target, not that we don't run it/it fails | 16:26 |
| gmann | this line where I unserdtood this does not work "This doesn't work for the elections repo.." | 16:27 |
| gmann | and it does not say about linter target already cover this | 16:27 |
| gmann | I thikn updating that in commit msg is important to know the history and why we do not run pep8 job otherwise many of us might be confusing until we check the disussion | 16:28 |
| gmann | otherwise its up to you. those jobs does not take much time to run. | 16:29 |
| tonyb | I agree, but they do take 2 nodes instead of one, which is wasteful | 16:30 |
| gmann | yeah but that should not stop us to improve things, if it is any other change than commit msg i could have agree that it can be done in followup or so but if any change require commit msg change we have to do irrespective of infra load | 16:32 |
| gmann | I mean if it is trivial we could skip but I find current commit msg confusing that is why I feel we should update | 16:32 |
| opendevreview | Felipe Reyes proposed openstack/election master: Add Felipe Reyes candidacy for OpenStack Charms PTL https://review.opendev.org/c/openstack/election/+/891868 | 16:33 |
| tonyb | Sorry my statement about 2 jobs is running tox -e pep8 (flake8) & tox -e linters (yamillint) in 2 jobs which is super wasteful and why they were combined as a single linters target. | 16:34 |
| fungi | the surge in queued builds peaked about 30 minutes ago and nodepool appears to be burning through the backlog now | 16:34 |
| fungi | but we should be prepared for more of this as we approach feature freeze | 16:35 |
| fungi | also the election changes aren't really contributing to the job load in any significant way, they're merely victims of the resource shortage | 16:36 |
| fungi | election checks take a few minutes to run. a nova change runs 24+ builds some of which require multiple nodes each and can run for 1-2 hours | 16:37 |
| fungi | a nova change consumes at least two orders of magnitude more resources than an election change | 16:38 |
| gmann | tonyb: yeah, I agree with the change. I am just saying updating the commit msg about it so that it will be clear from there | 16:43 |
| tonyb | fungi: If I update *only* the commit message will that invalidate the test-results? | 16:47 |
| fungi | tonyb: that's configurable per-project in the gerrit acl | 16:48 |
| fungi | i'll look at the election repo acl | 16:48 |
| tonyb | Thank you | 16:49 |
| fungi | https://review.opendev.org/Documentation/config-labels.html#label_copyCondition is what governs that behavior, the "NO_CODE_CHANGE" condition in particular | 16:55 |
| fungi | we document our base "All-Projects" acl that all other projects inherit from here: https://docs.opendev.org/opendev/system-config/latest/gerrit.html#access-controls | 16:56 |
| fungi | and we don't override the copyCondition in the [label "Verified"] section so by default it will be the same as gerrit's inbuilt default | 16:56 |
| fungi | https://review.opendev.org/Documentation/config-labels.html#label_Verified shows an example with "copyCondition = changekind:NO_CODE_CHANGE" but i don't think that's actually the default | 16:59 |
| fungi | from what i've observed we default to "TRIVIAL_REBASE" | 16:59 |
| fungi | https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/election.config doesn't override it either | 17:00 |
| tonyb | Okay. Thanks | 17:00 |
| fungi | nor does the https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/meta-config.config it's inheriting from | 17:00 |
| tonyb | I appreciate the detailed answer. Now I understand how that works *and* you validadted my reading :) | 17:01 |
| fungi | so i think yes, if you "edit" the commit message in the gerrit webui or push up a new commit which changes only the commit message, the verified vote from zuul will be cleared and it will need to be tested again | 17:01 |
| fungi | i believe you could add a [label "Verified"] section in election.config which set "copyCondition = changekind:NO_CODE_CHANGE" or maybe "copyCondition = changekind:NO_CODE_CHANGE,TRIVIAL_REBASE" if you wanted to override that behavior | 17:02 |
| fungi | aha, syntax would actually be "copyCondition = changekind:NO_CODE_CHANGE OR changekind:TRIVIAL_REBASE" based on other examples in the project-config repo | 17:04 |
| opendevreview | Merged openstack/election master: Update job config. https://review.opendev.org/c/openstack/election/+/891818 | 18:31 |
| fungi | the node request backlog is basically gone now, so builds should have nodes or should get them pretty much immediately | 19:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!