| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-02-14 | |||
| 16:26:41 | bauzas | anyway, back to the release | |
| 16:26:56 | bauzas | I think we made good progress on reviews | |
| 16:27:09 | bauzas | if we missed something or some patch, feel free to amend the etherpad please | |
| 16:27:13 | bauzas | or comment it out | |
| 16:27:33 | bauzas | I did a bit of research and digging but I think I found all the open changes | |
| 16:28:11 | bauzas | moving on then, unless someone caring about an accepted blueprint makes to take the opportunity to raise a concern ? | |
| 16:28:17 | gibi | yeah please cry out loudly if your series has a chance to land in the next two day and you lack reviews | |
| 16:29:24 | bauzas | ++ | |
| 16:30:03 | bauzas | ok, let's jump to the next one | |
| 16:30:06 | bauzas | #topic vPTG Planning | |
| 16:30:09 | bauzas | will be short | |
| 16:30:12 | bauzas | just a reminder | |
| 16:30:16 | bauzas | #link https://www.eventbrite.com/e/project-teams-gathering-march-2023-tickets-483971570997 Register your free ticket | |
| 16:30:21 | bauzas | #link https://etherpad.opendev.org/p/nova-bobcat-ptg Draft PTG etherpad | |
| 16:30:37 | bauzas | feel free to add the items you wanna discuss in ^ | |
| 16:30:45 | bauzas | #topic Review priorities | |
| 16:30:50 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | |
| 16:30:58 | bauzas | I'll be honest, I lost my attention | |
| 16:31:18 | bauzas | but I'll try to look at those once we cut m-3 | |
| 16:31:31 | bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | |
| 16:31:37 | bauzas | #topic Stable Branches | |
| 16:31:54 | bauzas | elodilles: showcase. | |
| 16:31:59 | elodilles | ~o~ | |
| 16:32:02 | elodilles | #info ussuri and train gates are fixed (ensure-rust role was added to grenade and tempest jobs) | |
| 16:32:17 | elodilles | #info stable/victoria gate is blocked (failing openstacksdk-functional-devstack job needs to be removed: https://review.opendev.org/c/openstack/nova/+/873295 similarly as in wallaby) | |
| 16:32:27 | elodilles | #info rest of the stable branches seem to be OK | |
| 16:32:32 | elodilles | or at least unblocked | |
| 16:32:45 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:32:59 | elodilles | i think that is all i can tell now | |
| 16:34:04 | bauzas | cool | |
| 16:34:18 | bauzas | I just rechecked the CVE fix for the ussuri branch | |
| 16:34:23 | bauzas | should land hopefully | |
| 16:34:32 | elodilles | fingers crossed | |
| 16:34:56 | gibi | bauzas: do we have CVE fix for stable/train? | |
| 16:35:01 | gibi | or we punted on that? | |
| 16:35:10 | gibi | due to oslo | |
| 16:35:12 | bauzas | gibi: as I said last week, I loudly said no to it | |
| 16:35:16 | gibi | OK | |
| 16:35:21 | bauzas | if someone wants to propose it, fair | |
| 16:35:23 | gibi | thanks for the refrsh | |
| 16:35:37 | bauzas | but yeah, due to the oslo.utils dep, that's not gonna be a fun conversation | |
| 16:35:53 | bauzas | and most distros now include the fix in their own products | |
| 16:36:13 | bauzas | that's it. | |
| 16:36:40 | gibi | thanks | |
| 16:36:53 | bauzas | #topic Open discussion | |
| 16:36:58 | bauzas | anything anyone ? | |
| 16:37:04 | bauzas | the agenda is empty | |
| 16:38:03 | gibi | I assume that if there are no loud cries for review on the week of FF then we are done a good job :) | |
| 16:38:25 | artom | So I have a weird thing | |
| 16:38:30 | artom | https://opendev.org/openstack/nova/src/branch/master/nova/image/glance.py#L392 | |
| 16:38:34 | artom | Count the length of that line | |
| 16:39:14 | artom | (We could also end the meeting and chat about that in "normal" IRC) | |
| 16:40:13 | gibi | 83? | |
| 16:40:13 | bauzas | artom: sure, that's a good point | |
| 16:40:17 | bauzas | I have 82 | |
| 16:40:21 | auniyal | 1116 | |
| 16:40:32 | artom | Yep. So... what's our pep8 job doing? | |
| 16:40:40 | bauzas | but AFAIR, we only enforce line lengths on code | |
| 16:40:55 | bauzas | that has to be doublechecked | |
| 16:41:03 | bauzas | anyway | |
| 16:41:15 | bauzas | let's wrap it now and chase this question outside of the meeting | |
| 16:41:17 | bauzas | thanks all | |
| 16:41:22 | bauzas | #endmeeting | |
| 16:41:23 | opendevmeet | Meeting ended Tue Feb 14 16:41:22 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:41:23 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-02-14-16.00.html | |
| 16:41:23 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-02-14-16.00.txt | |
| 16:41:23 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-02-14-16.00.log.html | |
| 16:41:27 | bauzas | so | |
| 16:41:42 | bauzas | we now enforce the line lengths by a pre-commit | |
| 16:42:02 | bauzas | not sure our tox pep8 target continues to check it | |
| 16:42:23 | artom | I only noticed it because a downstream pep8 job failed | |
| 16:42:29 | artom | It's from a commit in 2020 | |
| 16:42:32 | artom | https://review.opendev.org/c/openstack/nova/+/738738 | |
| 16:42:32 | bauzas | oh | |
| 16:42:36 | bauzas | no, I'm wrong | |
| 16:42:46 | bauzas | we autopep8 it with the pep8 target | |
| 16:43:08 | bauzas | https://github.com/openstack/nova/blob/master/tox.ini#L100 | |
| 16:45:56 | clarkb | bauzas: the --inplace flag doesn't appear to be a currently documented flag. Maybe it is fixing your code in CI and the flake8 passes after | |
| 16:46:29 | bauzas | clarkb: that's my guess but that doesn't explain this https://opendev.org/openstack/nova/src/branch/master/nova/image/glance.py#L392 | |
| 16:50:53 | clarkb | looking at the flake8 script it passes in the target posargs as the arguments to flake8 | |
| 16:51:30 | clarkb | the CI jobs don't have posargs by default (you could override them though I think, but I'm not seeing that in logs). Does flake8 check things without args? | |
| 16:51:38 | clarkb | you might simply be not checking things? I dunno | |
| 16:53:47 | gibi | I just tried, flake8 check all files if called without args and it finds the long line I add in nova/image/glance.py but not the L392 | |
| 16:54:50 | clarkb | autopep8 relies on pycodestyle to know whento change things too. Maybe the issue is in pycodestyle then where it doesn't see that as a problem so neither autopep8 nor flake8 complain | |
| 16:54:56 | artom | Yeah, same here. And it's not a comment thing (at least with # ) because if I comment out the long line it still finds it | |
| 16:55:34 | gibi | artom: yeah, I added a long line in the same doc comment and it finds that | |
| 16:56:03 | artom | Ah, but apparently not the *first* line? | |
| 16:56:41 | artom | So yeah | |
| 16:56:42 | artom | def _get_verifier(self, context, image_id, trusted_certs): | |
| 16:56:42 | artom | """Really long line long long long long long long long long long long long | |
| 16:56:42 | artom | Really long line long long long long long long long long long long long long long | |
| 16:56:42 | artom | """ | |
| 16:56:51 | artom | It complains about the second line (without """) | |
| 16:56:54 | artom | But not the first line | |
| 16:57:17 | gibi | yeah it seems the leading line is ignored | |
| 16:57:36 | clarkb | is the threshold different? I wonder if it complains eventually | |
| 16:57:40 | gibi | I moved L392 to a new line and padded it with 3 leading char and it finds it | |
| 16:58:33 | gibi | yeah if I pad the leading line with 10 extra chars then it finds it | |
| 16:58:38 | artom | Is that a bug in hacking or pep8? As I said, a downstream pep8 check does find it, using an older version of hacking/pep8 I think | |
| 16:59:06 | clarkb | artom: considering that autopep8 which also relies on pycodestyle doesn't complain about it either probably a thing in pycodestyle | |