| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-24 | |||
| 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=[{...},{...}] | |
| 09:46:20 | sean-k-mooney | but ok i can propose that as a specless blueprint some time | |
| 09:47:15 | gibi | OK, I think the list part can be a separate small thing | |
| 09:48:40 | stephenfin | If we got rid of MultiStrOpt, IMO we should look at what we did for the NUMA network affinity spec, where we dynamically generated configuration sections/options and flattened the list | |
| 09:49:11 | sean-k-mooney | stephenfin: no i dont really like that either | |
| 09:49:24 | sean-k-mooney | we could | |
| 09:49:34 | sean-k-mooney | but it woudl be non trivial to do | |
| 09:49:53 | sean-k-mooney | we dont have a name for thses to key off | |
| 09:50:16 | sean-k-mooney | they are already json strings | |
| 09:50:18 | gibi | didn't we had some race condition issues with dynamic opts? | |
| 09:50:26 | stephenfin | [pci] device_specs = foo, bar | |