| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-12 | |||
| 16:25:24 | bauzas | we'll run the job as non-voting first | |
| 16:25:27 | fwiesel | bauzas: I haven't looked at the root cause yet, as I thought a working CI has priority. Then we tackle the bugs one by one. | |
| 16:25:35 | bauzas | fwiesel: cool, no worries | |
| 16:25:41 | sean-k-mooney | fwiesel: third party ci cannot be voting | |
| 16:25:51 | bauzas | fwiesel: in case you need help, we can discuss those in your topic next weeks | |
| 16:25:53 | fwiesel | bauzas: But yes, we will be able to provide the bug fixes. It should be not terribly difficult | |
| 16:25:55 | sean-k-mooney | you can leave code review +1 or -1 | |
| 16:26:04 | sean-k-mooney | but never verifed +1 or -1 | |
| 16:26:19 | sean-k-mooney | or at least in a way that will prevent a patch merging | |
| 16:26:22 | fwiesel | sean-k-mooney: Ah, thanks for the explanation. Then I got the terminology wrong. | |
| 16:26:32 | sean-k-mooney | no worries | |
| 16:26:39 | bauzas | sean-k-mooney: I think we had 3rd-party CI jobs voting before ? (with zuul 2) | |
| 16:26:45 | sean-k-mooney | no | |
| 16:26:47 | sean-k-mooney | never | |
| 16:27:02 | sean-k-mooney | we disucssed it in the past and said that was not ok | |
| 16:27:10 | sean-k-mooney | as we cant have the gate blocked by a third party ci | |
| 16:27:39 | sean-k-mooney | if we are revieing a vmware patch and it breaks the vmware ci | |
| 16:27:44 | fwiesel | I meant, it probably shouldn't even leave a -1 in the beginning | |
| 16:27:44 | sean-k-mooney | we are very unlikely to merge it | |
| 16:27:52 | sean-k-mooney | but htat was left to cores to judge | |
| 16:27:59 | clarkb | you can haev a third party CI -1 and +1 without blocking anything. Only -2 blocks | |
| 16:28:00 | bauzas | okay, maybe this was in 2015 or earlier, but IIRC we had a job that was testing the DB time when upgrading and it was a 3rd-party CI | |
| 16:28:18 | sean-k-mooney | clarkb: we can yes | |
| 16:28:28 | sean-k-mooney | since gate only looks form verified form zuul | |
| 16:28:30 | bauzas | but maybe it never voted, can't exactly remember the details | |
| 16:29:02 | sean-k-mooney | bauzas: as far as i am aware we have never had third party voting ci and | |
| 16:29:16 | sean-k-mooney | i am not sure i want to change that in the future | |
| 16:29:16 | bauzas | anyway, this is not a problem | |
| 16:29:29 | sean-k-mooney | sure we just need to see the logs and if it passed or failed | |
| 16:29:51 | bauzas | let's see what fwiesel and grandchild can do with their CI and what they can provide for regression bugfixes | |
| 16:30:15 | fwiesel | That's from my side. Any questions? | |
| 16:30:15 | sean-k-mooney | yep | |
| 16:30:24 | sean-k-mooney | fwiesel: just one thing | |
| 16:30:28 | bauzas | fwiw, I'm okay with verifying some link every week during our meeting about how many job runs failed | |
| 16:30:31 | sean-k-mooney | you said local images dont work | |
| 16:30:39 | sean-k-mooney | did you make sure to use vmdks | |
| 16:30:42 | sean-k-mooney | instead of qcow | |
| 16:30:46 | bauzas | so even if we don't make them voting, we could continue to check those jobs continue to work | |
| 16:31:08 | fwiesel | sean-k-mooney: Sure, we only run with vmdks. | |
| 16:31:25 | sean-k-mooney | ok i was wondering if it was a simple format issue | |
| 16:31:35 | sean-k-mooney | feel free to file a bug with details when you have time | |
| 16:31:49 | bauzas | fwiesel: do you know we changed the VDMK types ? | |
| 16:32:08 | sean-k-mooney | o we blocked one of the times right | |
| 16:32:15 | bauzas | https://bugs.launchpad.net/nova/+bug/1996188 for the context | |
| 16:32:24 | fwiesel | bauzas: No, I don't. Thanks for the info | |
| 16:32:34 | bauzas | so you now need to pass an allowed list of vdmk types | |
| 16:32:50 | fwiesel | Ah, no. That one is fine... The same check is in cinder, and it works with boot from volume | |
| 16:32:55 | bauzas | maybe this is the root cause, maybe not | |
| 16:33:16 | bauzas | fwiesel: nova has its own config option | |
| 16:33:29 | bauzas | https://review.opendev.org/c/openstack/nova/+/871612 | |
| 16:33:41 | fwiesel | Sure, but we use the image subformat that isn't blocked | |
| 16:33:49 | bauzas | cool | |
| 16:33:57 | fwiesel | (streamOptimized or something) | |
| 16:34:01 | bauzas | was more a fyi, just in case | |
| 16:34:16 | bauzas | the vdmk bug hit me before :) | |
| 16:34:45 | bauzas | and when we had it, noone was around for telling us whether it was a problem for vmwareapi :) | |
| 16:34:57 | bauzas | anyway | |
| 16:35:01 | bauzas | shouldn't be a problem | |
| 16:35:19 | bauzas | fwiesel: thanks for the report, greatly appreciated | |
| 16:35:30 | fwiesel | you're welcome | |
| 16:35:36 | bauzas | fwiesel: someone also freaked out in the mailing list | |
| 16:35:45 | bauzas | I haven't replied but you could | |
| 16:35:57 | fwiesel | bauzas: Good idea, I will | |
| 16:36:11 | fwiesel | bauzas: openstack-discuss? | |
| 16:36:18 | bauzas | oh sean-k-mooney did | |
| 16:36:35 | bauzas | fwiesel: yup https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/DLTQ2KHQPFD4S7LLYKTWUPNFXRSTRTHU/ | |
| 16:36:54 | sean-k-mooney | ya i just said what we dicussed before | |
| 16:37:07 | sean-k-mooney | i.e. we wont remvoe anything until at least m2 depending on the ci status | |
| 16:37:17 | sean-k-mooney | and advies that while peopel can deprecate support | |
| 16:37:18 | bauzas | fwiw, I see a good progress | |
| 16:37:20 | sean-k-mooney | they shoudl not remove it | |
| 16:37:28 | bauzas | but let's continue to discuss it every week | |
| 16:37:33 | sean-k-mooney | yep | |
| 16:37:44 | bauzas | anyway, good talks | |
| 16:38:54 | bauzas | fwiw, I also advertised in the previous OpenInfraLive episode about what we agreed at the PTG and I explained verbally our current state, which is good for telling 'if you care about something, come tell us' | |
| 16:39:22 | bauzas | taking vmwareapi non-removal as an example of a working effort | |
| 16:39:46 | bauzas | anyway, time flis | |
| 16:39:50 | bauzas | flies* | |
| 16:39:53 | bauzas | #topic Open discussion | |
| 16:39:58 | bauzas | we have two topics | |
| 16:40:07 | bauzas | that we punted from last week | |
| 16:40:12 | bauzas | (artom) Specless blueprint for persistent mdevs | |
| 16:40:17 | bauzas | https://blueprints.launchpad.net/nova/+spec/persistent-mdevs | |
| 16:40:24 | bauzas | artom: around ? | |
| 16:40:40 | artom | Heya | |
| 16:41:16 | artom | To basically yeah - from memory, this would be limited to the libvirt driver, the idea is to persist mdevs when an instance is booted that uses an mdev | |
| 16:41:24 | bauzas | I'm maybe opiniated, so I won't really tell a lot, but I think this is a simple specless feature that only touches how our virt driver is creating a mdev | |
| 16:41:32 | artom | So that in case of a host reboot, the instances can come back without operator intervention | |
| 16:42:02 | artom | There might be operator intervention necessary to manually clean mdevs in certain cases | |
| 16:42:04 | bauzas | I don't see any upgrade concerns about it, the fact is that we will start persisting mdevs upon reboot by every compute that's upgraded | |
| 16:42:15 | artom | Because the mdevs would outlive their instances and host reboots | |
| 16:42:37 | artom | So for instance, changing the enabled mdev types (after draining the host), the operator would need to clean up the old mdevs | |
| 16:42:52 | sean-k-mooney | one thing you need to be careful of | |
| 16:42:56 | bauzas | artom: surely this will require a releasenote and some upstream docs, but this doesn't require to add a new DB model or anything about RPC | |
| 16:42:57 | gibi | as draining the host will not remove mdevs? | |
| 16:43:08 | sean-k-mooney | is on restating nova to a version with this support | |
| 16:43:19 | sean-k-mooney | if we have vms using mdevs created via sysfs | |
| 16:43:49 | sean-k-mooney | we need to supprot cretign the libvirt nodedev object to persist them | |
| 16:44:05 | bauzas | sean-k-mooney: I see the upgrade path for persisting the mdevs to restart the instances | |
| 16:44:12 | sean-k-mooney | i.e. we need to supprot upgrade in place without restarts | |