Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-23
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
16:42:35 dansmith well, I see no reason to prevent people from choosing this, so seems okay to me
16:42:40 bauzas oh the ssh transfer itself ?
16:42:47 sean-k-mooney yes
16:42:56 bauzas I guess the proposal is to make it configurable ?
16:43:01 dansmith yeah
16:43:10 bauzas but that would be for all images of the same type
16:43:18 dasp I'm here
16:43:18 dansmith default to the same behavior it looks like, so no change unless you want change
16:43:21 bauzas (I guess)
16:43:37 sean-k-mooney its this https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/volume/remotefs.py#L192-L193
16:43:50 bauzas dansmith: if this is opt-in for uncompress, that's OK
16:43:55 dansmith bauzas: right
16:44:07 bauzas dansmith: if that's changing the default to *not* compress raw images, I'm -1
16:44:14 sean-k-mooney so the current patch if they have not reviesed it maintianed the exsting behavior
16:44:19 dansmith bauzas: no, it's keeping the same default, just allowing people to control it
16:44:34 sean-k-mooney and i was suggesting we would not change the default without more dicussion
16:44:47 bauzas then it looks to me a simple configurable ask, which doesn't require a spec provided they don't break existing behaviour
16:44:49 sean-k-mooney although both rsync and ssh recommend it only for slow connections
16:45:09 dasp yes, changing default is not in scope right now as it comes from me. However, based on my tests, the default behavior is very bad unless I'm doing something unusually wrong.
16:45:37 dasp So I'm likely going to propose another future spec to change the default separately.
16:45:44 sean-k-mooney dasp: right so for now i think we shoudl add the option and consider changing the default after we get some operator input
16:45:53 bauzas what sean-k-mooney said
16:45:56 dansmith I dunno if discard will cause qemu to zero sections of a raw disk, but if not, over time your raw disk of zeroes becomes not that, so compression becomes useless after a point
16:45:57 bauzas expose the new knob
16:46:02 bauzas let operators play with it
16:46:17 bauzas and give us figures about why this is helpful to change the default
16:47:54 bauzas anyone having concerns about https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types NOT being a specless BP ?

Earlier   Later