Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-07
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
17:57:49 dansmith I was thinking we'd inherit that from the template regardless, but we won't
17:58:08 dansmith so yes, all we need to do is enable -always and voting=true and we're good forever
17:58:51 bauzas all good
17:58:54 bauzas wfm
18:09:04 bauzas gmann: now we branched 2023.1, do you want to explicitly mark the branches on https://review.opendev.org/c/openstack/nova/+/875773 ?
18:41:34 gmann bauzas: no that is not needed as it is defined as '-always' now so we will open this to run on everywhere it is added. for example once we will have stable/2023.2 it will continue running there to rest stable/zed->stable/2023.2
18:42:57 gmann and setting of those and on future master will be taken care on grenade side
18:46:41 gmann dansmith: you mean grenade-skip-level-always to be always run and only skip level job we will have and if project want they can stop it to run on non-slurp they can do. That way grenade-skip-level will disappear ?
18:47:24 dansmith gmann: no I think if the project only wants to test skip-level on slurps, they use skip-level, if they want to always test N-2->master, they use skip-level-always
18:47:30 gmann and we can add grenade-skip-level-always in integrated gate as voting in SLURP release only
18:48:03 gmann dansmith: in SLURP grenade-skip-level and grenade-skip-level-always will be with same setting so why we cannot just keep grenade-skip-level-alwaysonly
18:48:12 gmann and remove grenade-skip-level completly
18:48:51 gmann I mean grenade-skip-level-always always do N-2 -> N upgrade and 1. project need to run it mandatory in SLURP 2. it is optional to run in non-SLURP
18:48:57 dansmith you mean have the job branch-limited in the template and make nova override branches to be "all" for that job?
18:49:53 gmann nova having it in check pipeline should run even integrated template does add it but this is something we can test as zuul crazy magic
18:50:33 gmann but idea is to handle 1.mandatory in SLURP 2. optional in non-SLURP can by handled via branch variant
18:50:52 gmann keeping both jobs will confuse people
18:54:13 gmann let me do and show the template and greande side changes once we will branch greande (maybe this or early next week) and we can see/test how that can work for both cases 1. project want to run it in non-SLURP 2. project do not
19:22:20 opendevreview David Hill proposed openstack/nova master: Wait for VM to be paused before cleaning up https://review.opendev.org/c/openstack/nova/+/876776
19:25:49 artom gmann, oh hey, seeing your name here reminds me to gently poke you for input on https://review.opendev.org/c/openstack/nova/+/875653
19:28:43 gmann artom: yeah I opened it few days back after seeing it from channel and it is in my list. I will try to do it today if not tomorrow for sure.
19:28:45 gmann thanks for ping
19:29:28 artom No huge rush, good to know you're aware :)
#openstack-nova - 2023-03-08
08:39:14 opendevreview Jorge San Emeterio proposed openstack/nova master: Adding a default schema for requests to the 'lock', 'migrate' and 'unshelve' actions. https://review.opendev.org/c/openstack/nova/+/875653
10:30:31 opendevreview Merged openstack/nova stable/2023.1: [stable-only] Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876551
10:30:37 opendevreview Merged openstack/nova stable/2023.1: [stable-only] Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/nova/+/876552
11:24:54 opendevreview Rajesh Tailor proposed openstack/nova master: Add functional regression tests for bug 1857306 https://review.opendev.org/c/openstack/nova/+/700456
11:24:55 opendevreview Rajesh Tailor proposed openstack/nova master: Handle InstanceExists exception for duplicate instance https://review.opendev.org/c/openstack/nova/+/860938

Earlier   Later