| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-05 | |||
| 13:49:00 | sean-k-mooney | gibi: to porvide all the info we would also need to pass the numa toplogy info which would change the tree structure | |
| 13:49:11 | sean-k-mooney | doable but a lot of work | |
| 13:49:16 | gibi | the perhost limit has the problem that if nova still filters out PCI devices after placement then we need to make sure that placement returns enough candidate to fulfill that extra filtering | |
| 13:49:40 | sean-k-mooney | https://github.com/openstack/placement/blob/c68d472dca6619055579831ad5464042f745557a/placement/objects/allocation_candidate.py#L364-L387 | |
| 13:50:01 | gibi | yeh I linked it above :) | |
| 13:50:05 | sean-k-mooney | gibi: ya its the same issue with the current request limit | |
| 13:50:38 | sean-k-mooney | you linked to the resarch context | |
| 13:50:49 | sean-k-mooney | unless i missed it | |
| 13:51:03 | gibi | ahh sorry yes | |
| 13:51:12 | gibi | in the commit message I linked to the product call | |
| 13:51:26 | gibi | https://review.opendev.org/c/openstack/nova/+/855885/1//COMMIT_MSG#26 | |
| 13:51:34 | sean-k-mooney | ack | |
| 13:54:16 | gibi | at the moment I don't think this is easy to fix and given my time allocation for the next months I won't start on it. | |
| 13:54:35 | gibi | songwenping_ might have time and ideas to hack on it | |
| 13:55:12 | gibi | I left the above functional test top of the PCI series so we will not forget that this needs to be fixed | |
| 13:55:35 | gibi | but this makes me question if we want to merge the scheduling support in AA | |
| 13:55:48 | gibi | it might be useful for small deployments (<8 devs per host) | |
| 13:56:00 | gibi | but it is dangerous for big deployments | |
| 13:56:42 | gibi | bauzas: do we have a PTG etherpad? | |
| 13:56:49 | sean-k-mooney | im wondering if we need to have a way to limit this form the api query | |
| 13:56:59 | bauzas | gibi: not yet, but I can create one | |
| 13:57:08 | gibi | bauzas: I could use one :) | |
| 13:57:19 | bauzas | as you want | |
| 13:58:55 | gibi | sean-k-mooney: if we limit the a_c query then we need to give hints to placement about which order to iterate the candidates to fill the limited response | |
| 13:59:20 | gibi | sean-k-mooney: but I'm not sure I can express what we need | |
| 13:59:59 | gibi | sean-k-mooney: it is skip those candidates that are "too similar" to an already found candidate | |
| 14:01:04 | sean-k-mooney | gibi: im wonderign if we can avoid it by generatting a suffictly diverse set of combinations | |
| 14:01:19 | gibi | i.e. in case RP1(2), RP2(2), G1(1), G2(1) -> (RP1-G1, RP2-G2) and (RP1-G2, RP2-G1) might be too similar if G1 an G2 asks for the same RC and traits | |
| 14:01:52 | gibi | yeah divers set of candidates == skip the too similar ones :) | |
| 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 | |