Earlier  
Posted Nick Remark
#openstack-nova - 2022-05-24
17:37:59 whoami-rajat sean-k-mooney, ack, happy to have feedback on the test
17:38:02 sean-k-mooney i dont think adding a cleanup that rebuild to the old image is a good idea
17:38:15 sean-k-mooney it just add another failure mode in the test cleanup
17:38:16 dansmith yeah, not sure what that's about
17:38:35 dansmith comment says "not needed"
17:38:52 whoami-rajat dansmith, I did some changes in the nova code so the errors from logs are gone but it still somehow is not able to do it, I tested manually and the file never exists after the rebuild but somehow in this test, it stays there
17:39:13 whoami-rajat I'm working on a new job with two different images and will take input from there to fix it
17:39:25 dansmith whoami-rajat: ack, well, glad to have that assertion in there then :)
17:39:35 dansmith it was not rebuilding when I tried locally - the file was still present
17:40:11 whoami-rajat sean-k-mooney, ack, yeah that i added from the original rebuild test, can remove that part
17:40:24 whoami-rajat i think it was for an instance that is shared so reverted back to original image
17:40:45 whoami-rajat dansmith, if you try with latest code, it should work, at least it works for me and i tried 3-4 times
17:40:55 dansmith whoami-rajat: but not in the gate right?
17:40:59 whoami-rajat from nova side (in-use) and also from cinder side (available volume)
17:41:07 whoami-rajat yep, not in gate
17:41:12 dansmith okay
17:42:28 whoami-rajat thanks sean-k-mooney and dansmith for your feedback, it's a pity that this parameter travels down from api->conductor->compute layer and would require plenty of rework in a cycle where I've less bandwidth
17:42:37 whoami-rajat but i agree with the concerns and issues, so i will try to get it done
17:42:48 dansmith whoami-rajat: we still have to have the parameter on the rpc side
17:42:58 dansmith so that's not a waste :)
17:43:04 whoami-rajat dansmith, i don't understand
17:43:12 whoami-rajat i thought it's not passed at all to the API?
17:43:39 dansmith whoami-rajat: only the api knows whether the client requested the old or new behavior, so you still have to communicate that down to the compute worker
17:45:07 whoami-rajat dansmith, do you mean if microversion >=2.91 then use the ``reimage_boot_volume`` parameter for telling it to conductor and compute ?
17:45:23 dansmith yes
17:45:48 whoami-rajat oh, that reduces huge amount of work then
17:46:30 whoami-rajat thanks for that
17:48:26 sean-k-mooney whoami-rajat: it will be based on the microversion used
17:48:26 sean-k-mooney whoami-rajat: but the way that paramter is set is not based on a new api parmater
17:48:26 sean-k-mooney so the conductor/compute chagne will still be used
17:48:26 sean-k-mooney with the old one it will be false
17:48:26 sean-k-mooney with the new microverion the partmer at teh rpc level wil always be true
17:48:40 dansmith right
17:48:43 whoami-rajat sean-k-mooney[m], yes
17:49:48 sean-k-mooney oh i had an irc diconnect
17:50:22 sean-k-mooney looking at my matix client i see i did not recive a bunch fo messages
17:51:05 sean-k-mooney well 2 or 3 messages i guess
17:51:33 sean-k-mooney anyway whoami-rajat are you ok to update the spec and i can re review
17:52:10 whoami-rajat <whoami-rajat> sean-k-mooney[m], yes
17:52:10 whoami-rajat <dansmith> right
17:52:10 whoami-rajat * sean-k-mooney has quit (Remote host closed the connection)
17:52:10 whoami-rajat <sean-k-mooney> whoami-rajat: it will be based on the microversion used
17:52:10 sean-k-mooney im going to call it a day however so ill review tomorrow
17:52:10 whoami-rajat <sean-k-mooney> whoami-rajat: but the way that paramter is set is not based on a new api parmater
17:52:17 whoami-rajat sean-k-mooney, just for reference ^
17:52:23 whoami-rajat sean-k-mooney, sure, will do that
17:52:30 dansmith thanks whoami-rajat !
17:53:18 whoami-rajat thanks dansmith and other nova folks for this discussion, I will sign out now since it's quite late my time. have a good day :)
18:37:11 opendevreview Merged openstack/placement stable/wallaby: Use 'functional-without-sample-db-tests' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/840718
19:33:01 opendevreview Merged openstack/nova stable/victoria: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/840765
19:43:44 opendevreview Ghanshyam proposed openstack/nova stable/victoria: DNM: Testing https://review.opendev.org/c/openstack/tempest/+/843182 https://review.opendev.org/c/openstack/nova/+/843188
20:10:52 opendevreview Artom Lifshitz proposed openstack/nova stable/wallaby: DNM: Testing live migration with local attach https://review.opendev.org/c/openstack/nova/+/843146
21:32:02 opendevreview Artom Lifshitz proposed openstack/nova stable/wallaby: DNM: Testing live migration with local attach https://review.opendev.org/c/openstack/nova/+/843146
23:21:42 opendevreview Ghanshyam proposed openstack/nova stable/ussuri: DNM: Testing stable/ussuri with tempest fix for constraints mismatch https://review.opendev.org/c/openstack/nova/+/843046
23:37:18 opendevreview Miguel Lavalle proposed openstack/os-vif master: Delete trunk bridges to avoid race with Neutron https://review.opendev.org/c/openstack/os-vif/+/841499
#openstack-nova - 2022-05-25
03:25:13 opendevreview Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228
03:35:05 opendevreview Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228
04:55:18 opendevreview Merged openstack/nova master: libvirt: Add a workaround to skip compareCPU() on destination https://review.opendev.org/c/openstack/nova/+/838926
09:01:23 gibi stephenfin: when you are around, can we discuss the config option open questions in https://review.opendev.org/c/openstack/nova-specs/+/791047 ?
09:09:56 stephenfin gibi: Sure, on the review?
09:10:27 gibi we can talk here :)
09:10:33 gibi that is probably quicker
09:10:41 gibi so my first question is
09:11:03 gibi what is the reason behind you suggest no to rename the whitelist but add a totally new conf option?
09:12:36 stephenfin Oh, I thought that was what you were proposing at the beginning
09:12:40 stephenfin ...of the spec
09:13:58 stephenfin "The ``[pci]passthrough_whitelist`` config option will be deprecated for eventual removal and replaced with the new ``[pci]device_list`` config option."!
09:14:02 stephenfin ^ that threw me
09:14:10 gibi OK so we want to deprecate the old name
09:14:21 gibi but keep the same config opt definition
09:14:31 gibi (+ extend it with resource_class and traits)
09:15:11 stephenfin Okay, gotcha. I misunderstood. Please ignore that comment so
09:15:15 gibi cool
09:15:24 gibi the other is about the naming of the new option
09:15:37 gibi If I understand correctly you would like a singular name
09:15:59 gibi but probably neither singular nor plural is fully correct
09:16:16 gibi as a single entry in the device_list can match to zero, one, or multiple devices
09:16:51 gibi OR we could try to name the option not from the matched device(s) perspective but from the filtering / matching perspective
09:17:09 gibi i.e. device_spec device_filter
09:17:46 stephenfin Yeah, I forgot that it would accept a list. That's a really awful option
09:18:00 stephenfin device_spec or device_filter both wfm
09:18:21 stephenfin so long as it's not device_list really :)
09:18:48 gibi sean-k-mooney[m]: ^^ how do you feel about naming the device_list to [pci]device_spec or [pci]device_filter ?
09:19:17 gibi stephenfin: thanks.
09:31:14 sean-k-mooney1 i think device_filter was what i used in an older version
09:31:26 sean-k-mooney1 so im ok with either device_spec or device_filter
09:33:09 gibi cool
09:34:39 gibi sean-k-mooney1, bauzas: the last thing is the CUSTOM_ prefix. I will keep the normalization and prefixing in the spec as is and we can re-discuss that during code / doc review if needed.
09:35:31 sean-k-mooney gibi: ya im ok to defer that to the code review since bauzas's main ask was to document it properly
09:39:01 gibi yepp, and also bauzas is on PTO for the rest of the week :)
09:39:50 gibi I will update the config naming in the spec today
09:40:01 gibi and then I will ask you and stephenfin to approve it:)
09:42:10 sean-k-mooney ack :)
09:42:31 sean-k-mooney one question
09:42:43 sean-k-mooney do we want to add the json list support to the alas
09:42:55 sean-k-mooney to have partity with the device_filter
09:44:17 sean-k-mooney i personally woudl really like to not have to deal with the multiopt syntax but you dont have to fix that its just on my wishlist for some day
09:44:47 gibi I think it is a better direction to get rid of the multiopt
09:45:03 gibi but that is definitely something that is not in scope now
09:46:04 sean-k-mooney right so not suggesting geting rid of the multiopt just allowing alias=[{...},{...}]

Earlier   Later