| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-19 | |||
| 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. | |
| 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 | |