Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-07
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
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
17:54:03 bauzas when we have a slurp release
17:54:18 bauzas the -always will always run and voting, as its name says :)
17:54:45 bauzas but at the beginning of C, we would then enable the grenade-skip-level job and make it voting too, then ?
17:54:59 dansmith no, because it would be the exact same as the -always job in C
17:55:02 dansmith there's no reason to run both
17:55:22 bauzas so we would just change zuul to use grenade-skip-level instead of -always ?
17:55:33 bauzas or not changing anything ? :)
17:55:35 dansmith I don't know how we could avoid inheriting the regular job from the template, but we can worry about that when C comes, IMHO
17:55:56 bauzas meh ok
17:56:18 dansmith we could just remove the -always job in the slurp releases since we will get the regular job automatically, but I'd prefer to avoid that, I just don't know the zuul-fu to make that happen, but it's a problem for later, IMHO :)
17:56:37 bauzas honestly, if you want MHO, now that we have an -always job that tests N-2 even on non-SLURP, I'm quite intended to leave it as it is, whether it's a slurp or not in the master branch :)
17:56:54 dansmith that's what I'm trying to say
17:56:58 bauzas and just pretend the grenade-skip-level job never existed :)
17:57:06 dansmith right, that's what we should do
17:57:16 bauzas cool, then I understand it better :)
17:57:37 dansmith I guess the skip-level job is not in the template, actually

Earlier   Later