| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-05 | |||
| 14:02:03 | gibi | but what is divers might be not universal | |
| 14:02:55 | gibi | like ir RP2 is remote_managed=True in nova then placement still sees the same symmetry but the two RP is not equivalent from nova perspecgive | |
| 14:02:59 | gibi | perspective | |
| 14:04:12 | sean-k-mooney | right so we want to ignore order when lookign at equvialce provided the request group is the same | |
| 14:04:40 | sean-k-mooney | i feel likel there is definetly a way to optimise so that we dont generate a product | |
| 14:04:51 | sean-k-mooney | that is goign to over produce results | |
| 14:05:19 | sean-k-mooney | but off the top of my head im not sure the correct way to proceed | |
| 14:05:41 | gibi | bauzas: I've created https://etherpad.opendev.org/p/nova-antelope-ptg | |
| 14:06:34 | sean-k-mooney | lookingat https://docs.python.org/3/library/itertools.html#itertools-recipes | |
| 14:06:34 | gibi | sean-k-mooney: I agree on the second part "but off the top of my head im not sure the correct way to proceed" but I'm not sure we can have better than actually iterating the product | |
| 14:07:44 | sean-k-mooney | maybe take(per_host_limit, random_product(...)) | |
| 14:09:30 | gibi | yeah random is a way out even if a dirty one | |
| 14:09:38 | sean-k-mooney | gibi: if we cant avoid the need to generate the product im wonderign if we can break the implict lexegfacical ordering | |
| 14:10:14 | opendevreview | Amit Uniyal proposed openstack/nova master: add regression test case for bug 1552777 https://review.opendev.org/c/openstack/nova/+/855900 | |
| 14:10:14 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check for instance resizing https://review.opendev.org/c/openstack/nova/+/855901 | |
| 14:10:50 | gibi | if nova could define a requested order based on information that nova has but placement doesnt, then yes, ordering can be a solution. that is basically nova asking placement to generate diverse candiates with a definition of divers provided by nova in the a_c query | |
| 14:18:30 | gibi | OK I tried to document this issue on the PTG etherpad and by that I will move this to background processing :) | |
| 14:34:55 | opendevreview | Balazs Gibizer proposed openstack/nova master: Fix fair internal lock used from eventlet.spawn_n https://review.opendev.org/c/openstack/nova/+/855717 | |
| 14:36:38 | opendevreview | Balazs Gibizer proposed openstack/nova stable/yoga: Fix fair internal lock used from eventlet.spawn_n https://review.opendev.org/c/openstack/nova/+/855718 | |
| 16:22:06 | gibi | bauzas, sean-k-mooney: ML thread about the fair lock issue https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030325.html | |
| 16:22:13 | bauzas | gibi: thanks | |
| 16:23:58 | sean-k-mooney | cool | |
| 16:26:43 | gibi | I did find any direct evidence that other projects than nova and taskflow are affected | |
| 16:26:47 | gibi | I did not | |
| 16:30:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Fix fair internal lock used from eventlet.spawn_n https://review.opendev.org/c/openstack/nova/+/855717 | |
| 16:31:16 | opendevreview | Balazs Gibizer proposed openstack/nova stable/yoga: Fix fair internal lock used from eventlet.spawn_n https://review.opendev.org/c/openstack/nova/+/855718 | |
| 17:24:07 | sean-k-mooney | gibi bauzas https://blueprints.launchpad.net/nova/+spec/non-admin-hw-offloaded-ovs | |
| 17:24:47 | sean-k-mooney | i can proably hack up a poc of that this week i guess but im unsure if i will have time to take that to completion | |
| 17:26:07 | bauzas | cycle highlights ready to review https://review.opendev.org/c/openstack/releases/+/855974 | |
| 17:28:03 | sean-k-mooney | do we have any features to highlight for non libvirt drivers | |
| 17:28:15 | sean-k-mooney | were there any imporant ironic improvmements | |
| 17:28:19 | sean-k-mooney | or hyperv | |
| 17:29:25 | sean-k-mooney | based on https://docs.openstack.org/releasenotes/nova/unreleased.html#new-features i guess not | |
| 18:05:58 | sean-k-mooney | gibi: bauzas ... so there is alos a libvirt bug at play for hardwaore offloaded ovs | |
| 18:06:00 | sean-k-mooney | https://github.com/libvirt/libvirt/commit/8708ca01c0dd38764cad3e483405bdeb05ac2e96 | |
| 19:03:15 | whoami-rajat | bauzas, hey, we're past client freeze but my API feature is in and just wanted to mention the OSC and novaclient patches required by my feature | |
| 19:03:19 | whoami-rajat | novaclient https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 19:03:25 | whoami-rajat | OSC: https://review.opendev.org/c/openstack/python-openstackclient/+/831014 | |
| #openstack-nova - 2022-09-06 | |||
| 07:05:14 | bauzas | good morning Nova | |
| 09:18:32 | whoami-rajat | hi bauzas | |
| 09:19:31 | whoami-rajat | wanted to reiterate about the client and OSC patches required by my feature | |
| 09:33:45 | opendevreview | Balazs Gibizer proposed openstack/nova master: fixup https://review.opendev.org/c/openstack/nova/+/856033 | |
| 09:37:47 | bauzas | whoami-rajat: yup, will look | |
| 09:37:53 | bauzas | and thanks | |
| 09:38:16 | whoami-rajat | thank you :) | |
| 09:38:56 | whoami-rajat | for reference novaclient https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 09:38:57 | whoami-rajat | OSC: https://review.opendev.org/c/openstack/python-openstackclient/+/831014 | |
| 10:30:17 | bauzas | whoami-rajat: could you please explain me why you remove the reimage_boot_volume from the kwargs here https://review.opendev.org/c/openstack/python-novaclient/+/827163/11/novaclient/v2/servers.py#1750 ? | |
| 10:33:36 | bauzas | because by default, we say Yes for 2.93 https://review.opendev.org/c/openstack/nova/+/830883/32/nova/api/openstack/compute/servers.py | |
| 10:48:18 | whoami-rajat | bauzas, yes, so the current design accepted was to add a check on the client side, i will remove the check altogether from novaclient to clear the confusion | |
| 10:49:46 | whoami-rajat | also i just realized we changed the parameter name in current spec to "confirm-reimage", will update that as well | |
| 10:49:56 | sean-k-mooney | whoami-rajat: i just looked at the osc patch and that is not checkign properly | |
| 10:50:15 | bauzas | whoami-rajat: I think we have a bug with the nova patch | |
| 10:50:41 | bauzas | whoami-rajat: well, not a bug but some behavior that's different from the spec | |
| 10:50:45 | sean-k-mooney | the check that was ment to be added to osc was ment to check that if you use the new microversion that you also passed the new paramter if the instance was BFV | |
| 10:50:53 | sean-k-mooney | bauzas: how so? | |
| 10:51:04 | bauzas | whoami-rajat: if you use 2.93, you'll opt-in for reimage anyway | |
| 10:51:12 | bauzas | you can't tell no | |
| 10:51:16 | sean-k-mooney | bauzas: correct | |
| 10:51:20 | sean-k-mooney | bauzas: that is intentional | |
| 10:51:32 | whoami-rajat | sean-k-mooney, ack, will take a look at the osc patch | |
| 10:51:33 | bauzas | sean-k-mooney: then the spec was telling other thing | |
| 10:51:44 | bauzas | sean-k-mooney: the spec will telling you were able to opt-out | |
| 10:51:46 | sean-k-mooney | bauzas: then the spec is wrong | |
| 10:52:06 | bauzas | sean-k-mooney: see https://review.opendev.org/c/openstack/nova-specs/+/840155/5/specs/zed/approved/volume-backed-server-rebuild.rst#143 | |
| 10:52:36 | bauzas | we were keeping the original behavior with 2.93 if the user was passing a parameter | |
| 10:52:53 | bauzas | actually, no | |
| 10:53:05 | sean-k-mooney | no that is discribibg the osc change | |
| 10:53:10 | bauzas | the spec was saying that 'reimage is opt-in with 2.93' | |
| 10:53:16 | sean-k-mooney | no | |
| 10:53:22 | sean-k-mooney | that is client side only | |
| 10:53:28 | bauzas | and here we're discussing of "no reimage is opt-out with 2.93' | |
| 10:53:32 | sean-k-mooney | the nova api will not provde a way to opt in or out | |
| 10:53:44 | sean-k-mooney | other then the micorverions | |
| 10:53:45 | bauzas | oh you're right | |
| 10:53:52 | bauzas | "on the client side" | |
| 10:53:55 | sean-k-mooney | yes | |
| 10:54:00 | bauzas | so | |
| 10:54:05 | bauzas | 2.93 makes it default | |
| 10:54:24 | bauzas | and users can say no just by a client parameter | |
| 10:54:35 | sean-k-mooney | no | |
| 10:54:46 | bauzas | then clarify the spec | |
| 10:54:55 | sean-k-mooney | 2.93 makes it unconditional because we wanted rebuild to mean rebuild | |
| 10:55:02 | bauzas | which I understand | |
| 10:55:06 | sean-k-mooney | if you want the old behaivor you use the old microversion | |
| 10:55:14 | bauzas | yes | |
| 10:55:20 | sean-k-mooney | the client check was ment to prevent the request if you did not pass the parmater | |
| 10:55:28 | bauzas | so I don't see a need for an extra param on the client | |
| 10:55:31 | sean-k-mooney | not downgrade the microverios | |
| 10:55:39 | bauzas | ok, then I understand | |
| 10:55:50 | bauzas | you need to say "yes, I understand I'll reimage" | |
| 10:55:55 | sean-k-mooney | exactly | |
| 10:55:57 | whoami-rajat | sean-k-mooney, bauzas , as i see, the novaclient changes are not even needed i guess, just bumping the version to 2.93 should be enough right? | |
| 10:56:14 | sean-k-mooney | whoami-rajat: yep just bumping the max version | |
| 10:56:19 | sean-k-mooney | the rest is not needed | |
| 10:56:24 | bauzas | whoami-rajat: correct | |
| 10:56:27 | whoami-rajat | ack, will update | |
| 10:56:48 | bauzas | well | |
| 10:56:49 | bauzas | sec | |
| 10:57:02 | bauzas | sean-k-mooney: we also need a param on the python bindings | |