Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-07
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 bauzas -ETOOMANY open bugs
17:00:45 sean-k-mooney ack
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 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.log.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 Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-03-07-16.00.html
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 bauzas #endmeeting
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
17:49:27 bauzas my point is, should we get one of them voting and if so, which one ?
17:49:39 bauzas in a non-SLURP release I mean
17:49:57 dansmith we should get the always job voting on bobcat
17:50:07 dansmith are we ready to merge that job change now, or are we waiting still?
17:50:23 bauzas dansmith: if so, I'll rebase my change on top of yours
17:50:24 dansmith if we're ready, then I say depends-on my change and make always voting
17:50:31 bauzas and change zuul to make the -always voting
17:50:47 bauzas cool
17:51:12 dansmith I think that's just waiting on grenade and devstack branching 2023.1, which usually happens a bit after the other projects, IIRC
17:51:14 dansmith gmann: ^
17:51:29 bauzas dansmith: and then, once we open C, we enable grenade-skip-level job and make it voting too, amirite ?
17:52:11 dansmith the always job will work for C as well
17:52:21 dansmith or are you asking how to avoid running both?
17:52:42 bauzas no, I want to make sure I understand you
17:52:46 bauzas https://review.opendev.org/c/openstack/grenade/+/875990/2/.zuul.yaml
17:53:04 bauzas in there, that means we'll have a -always job that always test N-2
17:53:27 bauzas and a specific grenade-skip-level job that tests the previous SLURP release (or yoga in our case)
17:53:29 dansmith right, which for a slurp release will be the same for both jobs
17:53:38 bauzas correct
17:53:52 bauzas but that doesn't tell what a project should be testing

Earlier   Later