| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-07 | |||
| 16:53:16 | elodilles | ack | |
| 16:53:23 | elodilles | start with some repetition | |
| 16:53:26 | elodilles | #info stable/2023.1 branches were cut | |
| 16:53:34 | elodilles | #info stable gates seem to be OK - though it's hard to merge patches due to intermittent failures | |
| 16:53:43 | bauzas | unfortunately true | |
| 16:53:51 | elodilles | on older branches especially | |
| 16:53:54 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:54:02 | elodilles | and that's all | |
| 16:54:07 | elodilles | to be quick | |
| 16:54:25 | bauzas | thanks a lot | |
| 16:54:33 | bauzas | last topic | |
| 16:54:40 | bauzas | #topic Open discussion | |
| 16:54:46 | bauzas | we have an item | |
| 16:54:53 | bauzas | (astupnik) Known Issues section of Release Notes contains only known issues added during specific release cycle instead of complete list of known issues (all issues notes from nova/releasenotes/notes). I am wondering if this is normal or there is some bug in documentation framework? Example: min-bandwidth-workaround-0533ad03f67592a9.yaml introduced using I41f42c1a7595d9e6a73d1261bf1ac1d47ddadcdf and still affecting Nova. | |
| 16:55:04 | bauzas | tl;dr: answer is yes, this is expected behaviour | |
| 16:55:40 | bauzas | our release notes tooling provides a list of items based on YAML files that exist on a git branch | |
| 16:56:00 | bauzas | and accordingly heavily relies on git for the ordering and sorting | |
| 16:56:16 | astupnik | ack. I am wondering what's the best approach for tracking known issues? | |
| 16:56:33 | bauzas | known issues that aren't fixed ? | |
| 16:56:43 | sean-k-mooney | we dont really want to retoactivly delete the old release notes for knwon issues | |
| 16:56:56 | bauzas | that's a very good question and I don't have an existing solution on top of my head | |
| 16:56:57 | sean-k-mooney | we generally try ot refence the previous know issue in the patch that fixes it | |
| 16:57:02 | sean-k-mooney | and update the docs where approprate | |
| 16:57:35 | astupnik | the problem is that known issues in release notes only contain new issues, not ones that existed before release... | |
| 16:57:50 | sean-k-mooney | correct that is waht we wanted | |
| 16:57:55 | astupnik | ack | |
| 16:57:56 | bauzas | well, you have a list of known issues per release here https://docs.openstack.org/releasenotes/nova/zed.html | |
| 16:57:59 | bauzas | and others | |
| 16:58:17 | sean-k-mooney | we also tend to do thins like this https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#caveats | |
| 16:58:39 | bauzas | but we don't have a specific page that references a list of known issues over all the releases, despite that being possible with the reno tool, I think | |
| 16:59:04 | sean-k-mooney | i dont know how we would mark them as resolved | |
| 16:59:18 | bauzas | the best remains to bug the worldwide intelligence that stays on that channel :) | |
| 16:59:23 | sean-k-mooney | you dont really want a list of all know issue ever just the ones that are still outstanding | |
| 16:59:34 | astupnik | thank you for clarifications. Simplest way I found is to look for "issue" in release notes folder. I was wondering if there is more user-friendly option. | |
| 16:59:40 | bauzas | sean-k-mooney: yeah tracking is a problem | |
| 16:59:46 | sean-k-mooney | im sure chatgpt can fix this for us :P | |
| 16:59:53 | bauzas | ideally a known issue should mention a bug report | |
| 16:59:55 | astupnik | sean-k-mooney: I want all unresolved issues | |
| 17:00:13 | sean-k-mooney | that is our launchpad open bug list | |
| 17:00:19 | astupnik | heh, ok | |
| 17:00:21 | bauzas | so people should know the status of that issue by querying the bug tracker | |
| 17:00:36 | bauzas | sean-k-mooney: on a side note, I have a PTG topic on it :) | |
| 17:00:45 | sean-k-mooney | ack | |
| 17:00:45 | bauzas | -ETOOMANY open bugs | |
| 17:00:58 | bauzas | let's just axe them ::) | |
| 17:01:06 | bauzas | anyway, we're overtime | |
| 17:01:08 | bauzas | thanks all | |
| 17:01:10 | bauzas | #endmeeting | |
| 17:01:10 | opendevmeet | Meeting ended Tue Mar 7 17:01:10 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:10 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.html | |
| 17:01:10 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.txt | |
| 17:01:10 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.log.html | |
| 17:01:59 | elodilles | thanks o/ | |
| 17:03:05 | opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | |
| 17:26:47 | sean-k-mooney | bauzas: im conflicted about https://review.opendev.org/c/openstack/nova/+/875621 by the way | |
| 17:27:09 | sean-k-mooney | you should not need to delete those test but we might need to modify them slightly | |
| 17:27:30 | sean-k-mooney | at some point we can drop the version check in the api and the tests | |
| 17:27:57 | sean-k-mooney | perhaps for now we should set https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_compute_service_check_for_ffu | |
| 17:27:59 | sean-k-mooney | in them | |
| 17:28:08 | sean-k-mooney | to disable the compute service verion check | |
| 17:32:09 | dansmith | I'm confused | |
| 17:32:26 | dansmith | I thought we were going to set the min version for bobcat to zed to keep testing N-2 to master | |
| 17:32:44 | dansmith | oh wait, I'm being stupid | |
| 17:32:52 | dansmith | no wait | |
| 17:34:02 | bauzas | sean-k-mooney: yeah I'll try to modify the tests | |
| 17:34:05 | dansmith | yeah, that workaround is the thing we need to support N-2 to N upgrades without being live, so the conductors start before the computes have come online and upgraded, right? | |
| 17:34:11 | dansmith | and we're setting this in the skip-level job already IIRC | |
| 17:34:41 | bauzas | dansmith: the problem is that the test verifies some Yoga compute | |
| 17:34:52 | dansmith | the vdpa test? | |
| 17:35:02 | bauzas | so, even if we were saying ok for having N-2 computes, those tests couldn't work | |
| 17:35:04 | bauzas | dansmith: yea | |
| 17:35:42 | dansmith | okay, that just means our functional tests are broken, not the grenade job right? | |
| 17:36:00 | opendevreview | Amit Uniyal proposed openstack/placement master: Bugtracker link update https://review.opendev.org/c/openstack/placement/+/876768 | |
| 17:36:07 | bauzas | dansmith: yeah | |
| 17:36:13 | dansmith | I guess I'm jumped over that in my head and thought there was a suggestions that the grenade job had a problem | |
| 17:36:18 | dansmith | gotcha, nevermind me :) | |
| 17:36:19 | bauzas | context : https://fb9f1a762c721749bb72-4adf110539aed9252479dc6b548d2884.ssl.cf5.rackcdn.com/875621/9/check/nova-tox-functional-py38/7df3e76/testr_results.htm | |
| 17:36:47 | dansmith | yeah | |
| 17:36:54 | bauzas | so I'll try to modify those functional tests | |
| 17:36:57 | dansmith | yup | |
| 17:37:04 | dansmith | I'm caught up now :) | |
| 17:37:11 | bauzas | either I'll delete those tests given we no longer need to verify yoga computes | |
| 17:37:26 | bauzas | or I'll find a way to verify yoga computes with antelope services | |
| 17:38:06 | dansmith | I think we have other tests that continue to test those things | |
| 17:38:35 | dansmith | but also, if we're past the support envelope for those things, I'm not sure we need the tests or the code that supports them | |
| 17:39:07 | dansmith | if it's really RPC compat then sure, but if it's service version based, maybe not | |
| 17:42:34 | bauzas | dansmith: in general we have unittests verifying RPC compatibilty | |
| 17:42:52 | bauzas | like, we have UTs for RPC 6.x compute versions | |
| 17:43:07 | bauzas | that continue to verify if we can call a 5.x one | |
| 17:43:16 | dansmith | right, what I'm saying is.. if the functionality being tested is that service version X can coexist with master, we should be able to drop those tests *and* the functionality once X becomes old enough | |
| 17:43:36 | bauzas | dansmith: yeah me too | |
| 17:44:10 | bauzas | hence me saying I'll try to see if we can modify the tests, but if not, I'll delete those tests as we no longer support Yoga computes in Bobcat | |
| 17:44:22 | bauzas | sean-k-mooney: ^ | |
| 17:46:08 | bauzas | dansmith: btw. should I modify my change to rather depend on https://review.opendev.org/c/openstack/nova/+/875773 ? | |
| 17:46:34 | bauzas | and no longer modify zuul to say voting for grenade-skip-level https://review.opendev.org/c/openstack/nova/+/875621/9/.zuul.yaml | |
| 17:47:10 | dansmith | I mean it's up to you.. depends on how much of a hurry you're in I guess | |
| 17:48:29 | bauzas | dansmith: well, here I need your advice | |
| 17:48:35 | bauzas | we'll now have two zuul jobs | |
| 17:48:54 | bauzas | grenade-skip-level and grenade-skip-level-always | |
| 17:49:07 | bauzas | none of them will be voting once we merge https://review.opendev.org/c/openstack/nova/+/875773 | |