| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-19 | |||
| 15:48:34 | lyarwood | oh that part | |
| 15:48:36 | lyarwood | lol | |
| 15:52:39 | sean-k-mooney | lol | |
| 15:52:48 | sean-k-mooney | why | |
| 16:05:36 | openstackgerrit | Artom Lifshitz proposed openstack/nova-specs master: `socket` PCI NUMA-affinity Policy https://review.opendev.org/c/openstack/nova-specs/+/765551 | |
| 16:06:36 | artom | sean-k-mooney, ^^ I'll look at the vdpa spec now. I think the only thing I had a bit of a beef with is the whitelist. IIUC, it would have to contian the parent PF of any vdpa devices, so that should get documented methinks | |
| 16:36:22 | efried | I've never used "ta". | |
| 16:36:39 | efried | I did grow up mostly in London, so I wasn't a stranger to the idiom. But it never made it into my lexicon. | |
| 16:37:32 | sean-k-mooney | efried: really never knew you had a london connection | |
| 16:37:45 | sean-k-mooney | efried: hows life in k8s land | |
| 16:44:36 | sean-k-mooney | artom: +1 on your spec. i think that is consitent with my expections now | |
| 17:01:39 | artom | sean-k-mooney, cool, thanks! Yeah, I dunno if the "parent PF must be whitelisted" thing is obvious, but I figure it'd be nice to document it for operators | |
| 17:02:02 | artom | I think what confused me is you initially said in a review comment that the whitelist had nothing to do with VDPA | |
| 17:05:54 | sean-k-mooney | well the PF should not nessisaryly be what you whitelist it could be but you could whitelist the VFs | |
| 17:06:23 | sean-k-mooney | the imporant part is we are not changing how the whitelist currenlty works | |
| 17:07:16 | sean-k-mooney | it declare which pci device can be passthough, we then check if any of those have vdpa devices assocated with them and if they do we mark them as type-VDPA | |
| 17:07:28 | sean-k-mooney | instead of type-VF | |
| 17:07:58 | sean-k-mooney | that is part o fthe code i still need to merge | |
| 17:08:03 | sean-k-mooney | *write | |
| 17:08:27 | efried | sean-k-mooney: Yeah, lived just outside of London from 84-87 and 89-94. | |
| 17:08:27 | efried | OpenShift is fun. I'm not loving the devops side of things, but it's tolerable. | |
| 17:09:02 | sean-k-mooney | efried: have you managed to fine a way to do upstream work or still more on the support side | |
| 17:09:18 | efried | For some value of "upstream". | |
| 17:09:43 | sean-k-mooney | well i basicaly ment coding/bugfixing/feature design | |
| 17:09:50 | efried | Yeah, I'm getting to write code. | |
| 17:10:06 | sean-k-mooney | that good that they are not wasting your experince then at least | |
| 17:10:10 | efried | This is my baby: https://github.com/openshift/boilerplate/ | |
| 17:10:39 | sean-k-mooney | kind of like cookiecutter? | |
| 17:11:39 | sean-k-mooney | efried: ah not quite | |
| 17:11:48 | efried | Similar spirit. Doesn't cookiecutter play just at the birth of a repo? Boilerplate continues to evolve and subscribers get updates as they go. | |
| 17:11:53 | sean-k-mooney | efried: its more vendorisizng the standard deps | |
| 17:12:12 | efried | not deps in the package sense. | |
| 17:12:35 | efried | But yeah, kinda like vendoring standard workflows, make targets, build scripts... | |
| 17:12:37 | sean-k-mooney | well you use the term artifacts | |
| 17:12:49 | sean-k-mooney | so im thinking of them as a stanard libviar of things you can use | |
| 17:14:12 | efried | Yeah, something like that. Except the default is *must* use; we make it hard to switch pieces off. | |
| 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. | |