| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-23 | |||
| 16:08:25 | gibi | so yes | |
| 16:08:39 | gibi | bauzas: sure | |
| 16:08:48 | bauzas | ok, if this is done, let's move on | |
| 16:08:56 | bauzas | #info Please look at the gate failures, file a bug, and add an elastic-recheck signature in the opendev/elastic-recheck repo (example: https://review.opendev.org/#/c/759967) | |
| 16:09:06 | bauzas | any other gate issue to mention ? | |
| 16:10:07 | bauzas | looks not | |
| 16:10:13 | bauzas | #topic Release Planning | |
| 16:10:23 | bauzas | Yoga-1 was Nova 18th#link https://releases.openstack.org/yoga/schedule.html#y-1 | |
| 16:10:27 | bauzas | dang | |
| 16:10:37 | bauzas | link https://releases.openstack.org/yoga/schedule.html#y-1 | |
| 16:10:43 | bauzas | Yoga-1 was Nova 18th | |
| 16:10:50 | bauzas | #info Spec review day helped to merge 3 specs | |
| 16:11:06 | bauzas | thanks people who reviewed them | |
| 16:12:34 | bauzas | #info at Yoga-1 timeframe, Nova already accepted 7 specs and 4 specless BPs | |
| 16:12:44 | bauzas | (sorry, was counting) | |
| 16:13:06 | bauzas | anything to mention about the pace we have ? | |
| 16:13:50 | bauzas | #info reminder that we plan another spec review day mid-Dec, exact date to be discussed in a next meeting | |
| 16:14:03 | bauzas | moving on ? | |
| 16:14:40 | bauzas | I guess so | |
| 16:14:46 | bauzas | #topic Review priorities | |
| 16:14:56 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement)+label:Review-Priority%252B1 | |
| 16:15:02 | bauzas | #link https://review.opendev.org/c/openstack/nova/+/816861 bauzas proposing a documentation change for helping contributors to ask for reviews | |
| 16:15:11 | bauzas | that reminds me I need to update this change | |
| 16:15:52 | bauzas | #action bauzas to update his change to reflect the consensus about non-ownership ask for this label | |
| 16:16:42 | bauzas | but then, I'll ask next week what and how people feel about how to asynchronously ask reviewers (cores and non-cores) to look at changes | |
| 16:16:53 | bauzas | or the other way, how reviewers can discover changes | |
| 16:17:47 | bauzas | we have room for contributors happy to review that we can help them how to do this | |
| 16:18:19 | gibi | bauzas: btw, can we remove review priority from https://review.opendev.org/c/openstack/nova/+/810220 it is in -1 since 5th of Nov | |
| 16:19:06 | bauzas | gibi: fair enough, you provided good comments on it, and I didn't added my ones since I agree with you | |
| 16:19:16 | gibi | and I have the same feeling about https://review.opendev.org/c/openstack/nova/+/810849 too | |
| 16:19:27 | bauzas | even if I'd like this bugfix to be merged somehow | |
| 16:19:54 | gibi | and this too https://review.opendev.org/c/openstack/nova/+/803713 | |
| 16:21:22 | bauzas | #info we removed the Review-Priority flag from a few changes as they were lacking updates | |
| 16:21:48 | bauzas | I added a comment to each of the changes explaining to ping me again once they revise the change | |
| 16:22:07 | bauzas | gibi: thanks for the cleanup | |
| 16:22:33 | bauzas | I should somehow think about how to periodically check this | |
| 16:22:59 | bauzas | that's it for the RP labelling and usage ? | |
| 16:24:32 | bauzas | I guess so | |
| 16:24:37 | bauzas | #topic Stable Branches | |
| 16:24:44 | bauzas | elodilles: the mic is yours | |
| 16:24:52 | elodilles | #info stable gates are not blocked | |
| 16:24:58 | bauzas | woow | |
| 16:25:00 | elodilles | #info Ussuri transitioned to Extended Maintenance for nova projects \o/ | |
| 16:25:09 | elodilles | and that's it i think | |
| 16:25:25 | elodilles | i have no updates for the intermittent failures on stable gates :( | |
| 16:25:47 | bauzas | elodilles: don't wanna release any stable branch as we're around yoga-1 ? | |
| 16:26:04 | elodilles | good question | |
| 16:26:25 | bauzas | we could do a xena .z release | |
| 16:26:33 | elodilles | i haven't checked how much new content we have on stable branches | |
| 16:26:35 | bauzas | not sure if people want it tho | |
| 16:26:48 | bauzas | I'm pretty sure gibi would like a release, nope? | |
| 16:26:53 | bauzas | given of the backports | |
| 16:27:14 | bauzas | or do people want to stack a bit more until we release ? | |
| 16:27:28 | elodilles | i can prepare some if there is need :) | |
| 16:29:04 | gibi | bauzas: no hard push on a release | |
| 16:29:07 | bauzas | I have no personal interest beyond curiosity | |
| 16:29:20 | bauzas | ok, we can wait them | |
| 16:29:23 | bauzas | then* | |
| 16:29:41 | gibi | bauzas: the waiting for plug fix needed on victora / pike for my downstream counterpart | |
| 16:29:43 | elodilles | (i don't see much merged content) | |
| 16:29:54 | opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | |
| 16:30:23 | bauzas | gibi: well, for us, wallaby and train, but whatever | |
| 16:30:44 | gibi | yeah probably train too | |
| 16:30:49 | bauzas | I guess we're done with this topic, we can rediscuss about the opportunity to release a bit later in the cycle | |
| 16:31:44 | elodilles | yes, let's discuss later | |
| 16:32:00 | bauzas | ++ | |
| 16:32:08 | bauzas | #topic Sub/related team Highlights | |
| 16:32:14 | bauzas | Libvirt (lyarwood) | |
| 16:32:19 | lyarwood | We are tracking a QEMU 6.1.0 regression downstream with [libvirt]num_pcie_ports >= 15 when using the q35 machine type, we aren't hitting it yet upstream in Nova itself as we only use q35 in nova-next but TripleO is seeing it with centos 8 and 9 stream after a QEMU rebase. The workaround is to lower the port count to <=14. Just a heads up for now, I've got a TODO to create a known issue release note in Nova for the time being while we | |
| 16:32:19 | lyarwood | wait on a fix in QEMU. | |
| 16:32:57 | bauzas | ouch. | |
| 16:33:00 | lyarwood | and that's all I have this week | |
| 16:33:27 | sean-k-mooney | ack so noting to do in nova other then the known issue | |
| 16:33:35 | bauzas | ack, I also saw some bad libvirt modification that creates problems for our vgpu support | |
| 16:33:39 | sean-k-mooney | and perhaps change job config if needd | |
| 16:33:50 | lyarwood | sean-k-mooney: ack pretty much | |
| 16:33:55 | bauzas | https://bugs.launchpad.net/nova/+bug/1951656 | |
| 16:34:27 | bauzas | the fix is easy but that makes me worried about the fact that the namings we have are not a public API | |
| 16:35:06 | sean-k-mooney | its not the first time we have been broken by such name changes | |
| 16:35:45 | bauzas | can't imagine what would happen if the drivers can also change their mdev type names | |
| 16:36:04 | bauzas | we're a bit fragile | |
| 16:36:08 | bauzas | anyway | |
| 16:36:12 | bauzas | let's not overdiscuss this | |
| 16:36:26 | bauzas | we have a few specless bps requests again this week | |
| 16:38:10 | bauzas | #info QEMU 6.1.0 regression downstream with [libvirt]num_pcie_ports >= 15 requires for the moment to work around by lowering the port count to <=14. lyarwood will provide a relnote for it until the QEMU regression is fixed | |
| 16:38:27 | bauzas | moving on | |
| 16:38:31 | bauzas | #topic Open discussion | |
| 16:38:35 | bauzas | #topic Open discussion | |
| 16:38:44 | bauzas | (dasp) Blueprint for review: "Make no_compression_image_types configurable" -- https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types | |
| 16:38:49 | bauzas | dasp: around ? | |
| 16:38:57 | bauzas | Rationale: hardcoded behavior slows down cold migrations with local RAW disk images to 8 mbps and maxes CPU. It might be a good idea to change the default value as well or disable compression for all types. | |
| 16:39:58 | dansmith | this is compression of just the stream? | |
| 16:41:24 | dansmith | I assume the original thought is that raw disks *might* be mostly zeroes which compress to nothing during transfer, | |
| 16:41:38 | dansmith | but that probably falls apart over time and makes it compression for no reason | |
| 16:41:41 | bauzas | that's my general assumption | |
| 16:42:06 | sean-k-mooney | for ssh | |
| 16:42:09 | dansmith | ideally libvirt would just do hole detection and not transfer the holes, I think, but... | |
| 16:42:10 | sean-k-mooney | it just adds -C | |
| 16:42:19 | sean-k-mooney | for rsync it enable rsync compression | |
| 16:42:20 | dansmith | sean-k-mooney: ah, right | |