| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-12-13 | |||
| 16:05:21 | bauzas | as you can see, ^ was +Wd | |
| 16:05:43 | bauzas | so, hopefully, it could be merged in a few days | |
| 16:05:50 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:05:54 | bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | |
| 16:05:59 | bauzas | voila for gate bugs | |
| 16:06:39 | bauzas | gibi: you told me some change was fixing the issue for nova-ceph-multistore and nova-grenade-multinode | |
| 16:06:50 | gibi | yes | |
| 16:06:56 | gibi | it was pinning tox to < 4.0 | |
| 16:07:07 | gibi | it is merged last week | |
| 16:07:20 | gibi | since then we merged things to master so I think master gate is OK | |
| 16:07:33 | elodilles | note that that workaround will be removed @ Dec 21 | |
| 16:07:49 | gibi | elodilles: then we have a broken gate @ Dec 21 :) | |
| 16:07:51 | clarkb | in the ensure-tox role which won't affect devstack but will affect unittests and other things | |
| 16:07:52 | bauzas | gibi: cool thanks | |
| 16:08:02 | bauzas | #link https://bugs.launchpad.net/devstack/+bug/1999183 | |
| 16:08:06 | gibi | clarkb: ahh that sounds better | |
| 16:08:26 | clarkb | you can either pin ensure-tox to <4 in your .zuul.yaml by setting ensure_tox_version or whatever I called the variable or fix your tox.ini to work under tox v4 | |
| 16:09:09 | gibi | clarkb: ack, based on the timing I guess we will fix this next year :) | |
| 16:09:09 | elodilles | clarkb: thanks for the clarification | |
| 16:09:24 | clarkb | there are two main issues that we've found with tox v4 you need to convert whitelist_externals to allowlist_externals and that list must be complee as it doesn't just warn now but creates an error. And #'s in commands entries are interpreted as ini comments and you may need to escape them with \# if you intend for them to make it into the command | |
| 16:10:45 | bauzas | so, we don't need to modify our .zuul.yaml file ? | |
| 16:11:21 | clarkb | you either fix your tox.ini so that it is compatibile with tox v4 (and v3) or you update your .zuul.yaml to pin tox <4 | |
| 16:11:29 | gibi | bauzas: probably we are better of fixing our tox.ini instead | |
| 16:11:36 | clarkb | the ideal is the first option as that way developers don't get confused when tox doesn't work for them locally | |
| 16:12:00 | clarkb | I think if that wasn't a concern then we wouldn't be in a hurry to unpin and half force projects to address this, but it does actually represent a real world concern that we should be addressing | |
| 16:12:38 | bauzas | gibi: do we have the same issue than devtack by our own tox.ini file ? | |
| 16:12:53 | bauzas | about usage of allowlist_externals | |
| 16:13:12 | gibi | clarkb: said about that the Dec 21 change will not effect devstack jobs | |
| 16:13:53 | clarkb | devstack installs and manages tox itself so it controls when tox gets unpinned if ever | |
| 16:14:09 | gibi | clarkb thanks | |
| 16:14:28 | clarkb | skimming the nova tox.ini it actually looks like it might be ok. I'll push a change in a second that forces nova to use tox 4 in unittests to try and confirm | |
| 16:15:04 | bauzas | clarkb: okay, let ping us if you want after this | |
| 16:15:16 | bauzas | clarkb: and thanks for working on it | |
| 16:16:10 | bauzas | shall we move on ? | |
| 16:16:12 | opendevreview | Clark Boylan proposed openstack/nova master: DNM force latest tox https://review.opendev.org/c/openstack/nova/+/867533 | |
| 16:16:59 | bauzas | ack ^ | |
| 16:17:05 | bauzas | moving on then | |
| 16:17:13 | bauzas | #topic Release Planning | |
| 16:17:19 | bauzas | #link https://releases.openstack.org/antelope/schedule.html | |
| 16:17:23 | bauzas | #info Antelope-2 is in 3 weeks | |
| 16:17:31 | bauzas | as a reminder, we will have a Spec review day tomorrow | |
| 16:17:34 | bauzas | mark your calendars | |
| 16:17:56 | bauzas | #info Spec review day planned for Dec 14th | |
| 16:18:13 | bauzas | that's all I have here | |
| 16:18:22 | bauzas | any release question ? | |
| 16:19:06 | gibi | I will be a bit busy tomorrow witha in internal demo | |
| 16:19:17 | gibi | but I will try to get some time on specs too | |
| 16:19:20 | bauzas | ++ | |
| 16:19:24 | bauzas | gibi: no worries | |
| 16:19:38 | bauzas | #topic Review priorities | |
| 16:19:45 | 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:19:49 | bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | |
| 16:20:28 | bauzas | btw. for tomorrow's spec review day, it would be nice if cores could +2 the r-p label for each of the specs they want to look at during the day | |
| 16:20:52 | bauzas | so, when another core looks at a spec, he will know whether some other cores want to do this as well | |
| 16:20:58 | bauzas | just sayin' | |
| 16:22:58 | bauzas | movin' on | |
| 16:23:05 | bauzas | #topic Stable Branches | |
| 16:23:10 | bauzas | elodilles: your time | |
| 16:23:18 | elodilles | in short: nothing to report :) | |
| 16:23:22 | bauzas | \o/ | |
| 16:23:23 | elodilles | in more length: | |
| 16:23:28 | elodilles | #info stable branches seem to be unblocked / OK | |
| 16:23:33 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:23:42 | elodilles | and that is all | |
| 16:23:42 | bauzas | cool thanks | |
| 16:23:44 | bauzas | quick and loving | |
| 16:23:51 | elodilles | indeed | |
| 16:23:57 | bauzas | moving on | |
| 16:24:00 | bauzas | last topic | |
| 16:24:06 | bauzas | #topic Open discussion | |
| 16:24:10 | bauzas | first, I have a question | |
| 16:24:16 | bauzas | (bauzas) We're entering the Christmas period. Would we want to skip some meetings ? | |
| 16:24:37 | gibi | I will be off from next Monday so I vote to skip it | |
| 16:24:41 | bauzas | at least for me, I'll be working on next Tuesday | |
| 16:24:59 | bauzas | but if we don't have a quorum, then I'd prefer to punt this meeting | |
| 16:25:22 | bauzas | I know sean-k-mooney won't be there too | |
| 16:25:36 | bauzas | I don't know for others, but if 3 main folks aren't around... | |
| 16:25:50 | Uggla | I guess we should not a lot of people in the next 2 weeks. | |
| 16:25:53 | bauzas | #info Skip the two next Nova meetings | |
| 16:25:56 | opendevmeet | Removing item from minutes: #info Skip the two next Nova meetings | |
| 16:25:56 | bauzas | #undo | |
| 16:25:59 | gmann | +1 on skipping | |
| 16:26:10 | bauzas | #info Skip the two next Nova meetings on Dec 20 and Dec27 | |
| 16:26:15 | opendevmeet | Removing item from minutes: #info Skip the two next Nova meetings on Dec 20 and Dec27 | |
| 16:26:15 | bauzas | #undo | |
| 16:26:24 | bauzas | #info Skip the two next Nova meetings on Dec 20 and Dec 27. See you next year ! | |
| 16:26:35 | bauzas | ok was quick | |
| 16:26:41 | bauzas | I'll send an email | |
| 16:26:48 | bauzas | second question | |
| 16:26:53 | bauzas | (bauzas) Document the volume detach issue | |
| 16:27:17 | bauzas | as a reminder, this volume detach issue we have is related to a specific libvirt release | |
| 16:27:35 | bauzas | so, I don't know how we could document it | |
| 16:27:57 | bauzas | but I'd like to have a way to explain our users that they need to make sure to ask to detach once they can ssh | |
| 16:28:10 | bauzas | and ideally attach as well | |
| 16:28:38 | bauzas | thoughts on that ? | |
| 16:29:31 | bauzas | hah | |
| 16:30:00 | bauzas | you know what ? | |
| 16:30:26 | bauzas | let's discuss this once more people are around like next year :) | |
| 16:30:42 | gibi | I guess you are not happy with a simple reno | |
| 16:31:02 | bauzas | gibi: yes, because this is not related to our repository, right? | |