Earlier  
Posted Nick Remark
#openstack-nova - 2021-01-19
17:15:12 sean-k-mooney presumably for consitncy between different operators
17:15:38 sean-k-mooney and preventing code debt thorugh duplciation
17:15:43 efried exactly.
17:16:13 artom sean-k-mooney, right, so I think that's the part that could be made more explicit (at least for my brain): "the existing whitelist mechanism is unchanged - if a device is whitelisted and is bound to the vdpa driver, it will be inventoried as type-VDPA and plugged accordingly."
17:16:58 sean-k-mooney artom: sure i can adde that proably in the developer inpact section
17:17:27 sean-k-mooney * Other deployer impact
17:17:33 sean-k-mooney sorry no
17:17:38 sean-k-mooney Developer impact
17:17:53 sean-k-mooney ill add it now in any case
17:19:51 sean-k-mooney i guess technically im modifying this code https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7074-L7110 so i can put it in proposed change section
17:37:50 openstackgerrit Balazs Gibizer proposed openstack/nova master: Replace blind retry with libvirt event waiting in detach https://review.opendev.org/c/openstack/nova/+/770246
17:52:03 dansmith gmann: hey I was looking for some fat to cut from jobs.. just thinking.. do we really need to run grenade and grenade-multinode against nova? not sure under what circumstances we'd really get benefit from regular grenade that we don't see in the multinode job
17:55:09 gmann dansmith: multinode you mean this right ( not grenade-multinode ) nova-grenade-multinode ?
17:55:21 dansmith sure
17:56:00 gmann dansmith: it run live migration tests too https://github.com/openstack/nova/blob/master/playbooks/legacy/nova-grenade-multinode/run.yaml#L58
17:56:39 dansmith gmann: right, but is there anything fundamental about the base grenade job that we don't or can't do in the multinode variant such that we could stop running the base grenade job?
17:56:52 gmann dansmith: or you are thinking to drop grenade-py3 in favor of nova-grenade-multinode which cover upgrade + live migration?
17:56:59 gmann dansmith: right,
17:57:07 dansmith right
17:57:49 gmann I think yes, that make sense. in grenade-py3 we only run smoke test so it is a rick set of test we run there so nova-grenade-multinode server the purpose
17:57:53 gmann serve
17:57:54 sean-k-mooney dansmith: im not sure we rung the same test in both
17:58:27 dansmith gmann: cool, that'd be another ~1h job we run less
17:58:37 dansmith sean-k-mooney: I think the multinode job is a superset, no?
17:58:38 sean-k-mooney if its the same tests and same backend e.g. ceph vs non ceph i think we are ok
17:59:01 gmann dansmith: +1
17:59:13 sean-k-mooney dansmith: im not sure if we use the same storage backend in both
17:59:47 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: libvirt: Add support for flavor and image defined ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/771474
18:00:06 dansmith gmann: okay, what's the magic to make zuul not run a job we inherited? :)
18:00:30 dansmith sean-k-mooney: I think those jobs are just stock storage config aren't they?
18:00:41 lyarwood gmann / dansmith ; just a quick point, at the moment the multinode job is still stuck on bionic
18:00:47 sean-k-mooney ya i would expect so
18:00:49 lyarwood but the single node job is on focal
18:01:01 sean-k-mooney so likel cinder isci/lvm
18:01:03 dansmith lyarwood: okay, but for grenade things is that significant?
18:01:05 lyarwood I'm not sure if we want to drop the single node job until the multinode job has moved finally
18:01:48 sean-k-mooney there is noting preventing us form using focal at this point right
18:01:49 dansmith lyarwood: okay, we can wait if it's significant, but I think we should aim to do it
18:01:50 lyarwood dansmith: I guess, it's just not as stable as the focal based job at the moment imho
18:02:00 sean-k-mooney it was only using bionic for the device detach thing
18:02:09 sean-k-mooney which is kind of fixed with the increased timeout
18:02:24 lyarwood sean-k-mooney: it's the move to the native zuulv3 based job that's blocking us at the moment
18:02:26 dansmith lyarwood: if we run both and the superset is less stable, it's the same number of -1s from zuul, but double the resource usage, so :/
18:02:27 gmann lyarwood: yeah bionic and zuulv2
18:02:29 sean-k-mooney and which gibi is trying to fix fully currently usign the events
18:02:51 gmann dansmith: but to stop the grenade-py3 we need to change in integrated-gate template also
18:02:52 lyarwood sean-k-mooney: that isn't the issue anymore
18:02:54 sean-k-mooney lyarwood: right but it could be zuulv2 + focal
18:03:07 sean-k-mooney you just need to change the label
18:03:34 lyarwood sean-k-mooney: assuming devstack-gate etc actually support it
18:03:36 gmann dansmith: here https://github.com/openstack/tempest/blob/master/zuul.d/integrated-gate.yaml#L378
18:03:39 lyarwood I'm not sure that's the case
18:04:04 gmann sean-k-mooney: its not easy, legacy jobs were left to run on bionic and once they move to zuulv3 it will run on focal
18:04:19 gmann so how much work we need for Focal in devstack-gate is not known
18:04:28 sean-k-mooney gmann: devstack-gate basiclaly wraps devstack i dont think its actully executing os level commands
18:04:30 dansmith gmann: right that's where we inherit it from, correct? we have to do something in nova/.zuul to say "don't run this" ?
18:05:04 lyarwood FWIW I wanted to help move the multinode grenade job to zuulv3 once https://review.opendev.org/q/topic:%2522native-zuulv3-migration%2522+owner:lyarwood%2540redhat.com+status:open had landed for nova-live-migration-ceph
18:05:24 lyarwood ^ that's pretty much ready now I think, just needs core reviews in devstack, devstack-plugin-ceph and eventually nova.
18:05:25 gmann dansmith: i do not think there is a way to say "don't run this". we have to remove it from defined pipeline from template or explicitly added
18:06:04 dansmith gmann: ah, what if we set irrelevant files to "everything" ?
18:06:17 gmann lyarwood: yeah, I need to look into this patch to proceed further https://review.opendev.org/c/openstack/nova/+/742056
18:07:25 gmann dansmith: :) that is nice trick but let's remove it from template so that grenade testing can be added explicitly by projects with base or specific jobs
18:07:58 dansmith gmann: okay I just didn't want to mess with the base template and/or make everyone add grenade themselves
18:09:25 gmann dansmith: integrated-gate-compute is used by nova only so it is fine.
18:09:32 dansmith ah
18:09:56 gmann and we will keep it in integrated-gate so that it can used as complete set of integration + upgrade tests
18:10:07 dansmith oh I see, -compute
18:10:08 dansmith got it
18:10:23 dansmith gmann: I will propose and we can -W until we do the conversion
18:10:46 gmann yeah, i separated those template per integrated services so that we can do such type of optimization
18:10:52 gmann +1
18:11:01 dansmith gmann: you're smart :)
18:11:46 gmann otherwise nova and neutron use to get swift failure and cinder get neutron and vice versa
18:14:15 rouk 2.48 removed lots of kvm details (specifically memory) when standardizing diagnostics, i can get more detail by asking for 2.47, where are these details represented in 2.48+?
18:19:00 sean-k-mooney why are we altering the templates by the way.
18:19:20 sean-k-mooney given grenade and the multi node one are both listed in our .zuul.yaml in the check pipeline
18:19:45 sean-k-mooney https://github.com/openstack/nova/blob/master/.zuul.yaml#L443-L470
18:20:09 sean-k-mooney given noone else use integrated-gate-compute
18:20:22 sean-k-mooney im not sure moving grenade into that nessisarly helps
18:22:00 sean-k-mooney im not sure maintianing https://opendev.org/openstack/tempest/src/branch/master/zuul.d/integrated-gate.yaml#L369-L383 makes sense
18:22:22 sean-k-mooney at least im not sure it should live in tempest
18:22:52 gmann sean-k-mooney: it need to be at central place in QA side.
18:22:59 sean-k-mooney same for the other project for that matter
18:23:07 sean-k-mooney i dont really thing it does
18:23:37 gmann this can be extended in future to add slow test job too which is currently not separated out as such
18:24:10 sean-k-mooney it could but since we would want the project input when doing that
18:24:18 sean-k-mooney does it not make sense to defien it in the proejcts
18:24:52 gmann its both project and QA
18:25:45 sean-k-mooney right but it feels odd that tempest would reference any job not defiend in it in that template
18:27:28 sean-k-mooney gmann: if dansmith is ok with it i guess its fine it just feels odd that the qa team would be defining jobs that run against nova outside of the nova repo
18:27:43 dansmith tons of jobs are like that?
18:27:51 dansmith we define jobs other projects run
18:28:06 sean-k-mooney well i dont know tha tfeels more elective
18:28:19 sean-k-mooney i guess its just greneade the feels weried to me
18:28:22 sean-k-mooney i dotn know why
18:28:34 sean-k-mooney i know all the tox jobs work this way
18:28:53 sean-k-mooney i just wasnt expecting to see grenade in those templates
18:29:35 sean-k-mooney since that was managed in tree by project grenade supported
18:30:44 sean-k-mooney for example neutron https://github.com/openstack/neutron/blob/master/zuul.d/project.yaml#L21-L22
18:32:15 sean-k-mooney although they do not use integrated-gate-networking

Earlier   Later