| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-10-03 | |||
| 10:34:40 | sean-k-mooney | i do think thses woudl be good enachnmemnt however so if there isnt a comunity effort to move them forward ill see if i can help more directly | |
| 11:12:55 | noonedeadpunk | yeah, I think I should be able to pull couple of them | |
| 13:01:43 | opendevreview | Merged openstack/python-novaclient master: Use pre-commit for lint jobs https://review.opendev.org/c/openstack/python-novaclient/+/952987 | |
| 13:10:56 | opendevreview | Merged openstack/python-novaclient master: tests: Remove use of ddt https://review.opendev.org/c/openstack/python-novaclient/+/953193 | |
| 13:35:32 | opendevreview | Ian Watson proposed openstack/nova master: Changing how placement updates are triggered in RT https://review.opendev.org/c/openstack/nova/+/955687 | |
| 14:59:13 | opendevreview | Balazs Gibizer proposed openstack/placement master: Prune a_c search space by invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776 | |
| 15:00:10 | gibi | sean-k-mooney[m]: dansmith: ^^ now with a long commit message and a workaround flag | |
| 15:03:31 | sean-k-mooney | gibi: so you runign with 21 because well that is what the bug report used. have you tried bumping to 32 PFs | |
| 15:03:44 | sean-k-mooney | gibi: basiclly im wondering how much headroom this is geting us | |
| 15:04:05 | sean-k-mooney | 7 seconds for the 21_21 case is not bad | |
| 15:04:11 | ratailor | sean-k-mooney, gibi elodilles could you please review https://review.opendev.org/q/I04f6e1ba3eff443d40a13c6fe2d0b77a78a020e6 | |
| 15:04:35 | sean-k-mooney | much better thne before you started im juust wonderign if it will explode at say 24_24 or can we push to 32+ | |
| 15:06:27 | gibi | sean-k-mooney: yeah 21 is the magic number from the customer. I can add more cases. | |
| 15:06:39 | gibi | please leave a comment in the review so I won't forget | |
| 15:06:54 | sean-k-mooney | a standard 2U server can typicaly hold 24 2.5" ssd's in the front which woould also need 96 pci lanes to support at full speed. given many chips top out at 96-128 lanes with some going ot the low 160s range 32 device is proably close to the max we woudl expct to see | |
| 15:07:35 | sean-k-mooney | sure i can im ok with the current test uing the reproted worse case i just was wondering if you had playied aroudn with it | |
| 15:07:44 | sean-k-mooney | ill pull it locally and try it | |
| 15:08:22 | sean-k-mooney | but ya 120+ second ot 6.9 is a very nice impovement | |
| 15:08:33 | gibi | sean-k-mooney: if it is two slow for 32/32 then try to decrease the max alocation candidates from 1000 to smaller | |
| 15:08:39 | gibi | s/two/too/ | |
| 15:08:44 | sean-k-mooney | but 120+ to less then one in the non worse case is very promising | |
| 15:09:07 | gibi | I have drop for the weekend in minutes so I won't be able to test it myself today | |
| 15:09:18 | sean-k-mooney | gibi: oh ya that a good poitn if we can provide soem guiance on tuning the values for larger systems than that at least a workaroudn | |
| 15:09:26 | gibi | btw up until 8/8 I tested the logic in devstack as well and the numbers are pretty similar | |
| 15:09:53 | sean-k-mooney | cool ya i was ment to finish an hour ago so ill loop back to this on monday | |
| 15:09:59 | sean-k-mooney | gibi: enjoy your weekend | |
| 15:10:00 | gibi | cool thanks | |
| 15:10:03 | gibi | same to you | |
| 15:35:04 | opendevreview | Nisha Brahmankar proposed openstack/nova master: Add graceful shutdown feature for nova-compute https://review.opendev.org/c/openstack/nova/+/962975 | |
| 15:42:23 | tkajinam | I wonder if anyone disagrees with closing all xen related bugs by setting their status to Won't fix ? | |
| 15:44:37 | sean-k-mooney | well we deleted the driver and the libvirt xen suspprot a few years ago at this point | |
| 15:45:24 | sean-k-mooney | so i dont see why we woudl not set it to wont fix at this point or invlaid | |
| 16:02:01 | nisha04 | Hi nova core members, | |
| 16:02:01 | nisha04 | We have the basic PoC code ready here: https://review.opendev.org/c/openstack/nova/+/962975 | |
| 16:02:01 | nisha04 | This is Nisha from LY Corporation, Japan. We got a green signal in the nova PTG 2025.2 to implement the graceful shutdown feature for nova-compute. (https://etherpad.opendev.org/p/nova-2025.2-ptg#L1088) | |
| 16:02:03 | nisha04 | I want to discuss the design choices and spec requirements. I will be attending the OpenInfra Summit in Paris this month. It would be great if we could discuss them in person during the summit. Are you attending the summit? If so, could you share preferable slots, if any, for a discussion. | |
| 16:14:10 | sean-k-mooney | nisha04: some of the core will be tere i belive Uggla stephenfin and bauzas are trvelign/have talks | |
| 16:14:43 | sean-k-mooney | in general the full core team will not but there shoudl be an opteruntiy to have some level of dicusssion the PTG is the week after as well so there is also that operunity | |
| 16:20:07 | nisha04 | sean-k-mooney: Thanks for the info. I just wanted to have a quick discussion and receive informal feedback. I will try to contact Uggla stephenfin and bauzas if they have any available time slot. | |
| 16:20:36 | Uggla | @nisha04 I think we could find a slot at the OpenInfra Summit to do some kind of pre-check. | |
| 16:20:36 | Uggla | I can try to accommodate the timeslot as much as possible with your timezone. | |
| 16:20:36 | Uggla | But I’d also like to have this as a topic at the PTG, since I know @gibi will be available and deeply involved. | |
| 16:21:13 | sean-k-mooney | nisha04: bauzas is doing a contibuting to nova talk | |
| 16:21:42 | sean-k-mooney | i.e. how to contibute so you might be able to find them in the halway after | |
| 16:21:59 | sean-k-mooney | but ya ptg dicussion after woudl be good to allow all to partipate | |
| 16:22:33 | Uggla | I'll be there too. | |
| 16:24:18 | nisha04 | Thanks a lot! I definitely want to bring this topic in the PTG for collective feedback since we are actively working on it now. | |
| 16:24:18 | nisha04 | I will also try to find you in the hallway during the summit and hope to have a quick chat sometime. | |
| 16:30:07 | Uggla | nisha04, pretty sure we will find a slot to discuss. | |
| 17:28:22 | opendevreview | Merged openstack/placement master: Remove excessive logging from GET a_c https://review.opendev.org/c/openstack/placement/+/962775 | |
| 18:33:14 | dansmith | melwitt: finally got my devstack unfscked.. but now I've deployed without barbican | |
| 18:33:36 | dansmith | I have several things commented out in my local.conf... is enable_service barbican enough or do I need more? | |
| 18:49:01 | opendevreview | sean mooney proposed openstack/placement master: [WIP] Fix copy_arr_if_needed() and add observability https://review.opendev.org/c/openstack/placement/+/963006 | |
| 18:53:27 | opendevreview | sean mooney proposed openstack/placement master: [WIP] Fix copy_arr_if_needed() and add observability https://review.opendev.org/c/openstack/placement/+/963006 | |
| #openstack-nova - 2025-10-04 | |||
| 11:02:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: test with placement fix https://review.opendev.org/c/openstack/nova/+/963035 | |
| 11:02:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with optimize_for_wide_provider_trees https://review.opendev.org/c/openstack/nova/+/963036 | |
| 14:46:34 | opendevreview | Balazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests https://review.opendev.org/c/openstack/placement/+/963052 | |
| 14:48:15 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: test with placement fix https://review.opendev.org/c/openstack/nova/+/963035 | |
| 14:48:15 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with optimize_for_wide_provider_trees https://review.opendev.org/c/openstack/nova/+/963036 | |
| 15:53:57 | opendevreview | Balazs Gibizer proposed openstack/placement master: Inline exceeds_capacity https://review.opendev.org/c/openstack/placement/+/963053 | |
| 18:45:34 | opendevreview | Balazs Gibizer proposed openstack/placement master: Inline exceeds_capacity https://review.opendev.org/c/openstack/placement/+/963053 | |
| #openstack-nova - 2025-10-05 | |||
| 21:20:21 | opendevreview | Steve Baker proposed openstack/nova master: Add VNC console support for the Ironic driver https://review.opendev.org/c/openstack/nova/+/942528 | |
| #openstack-nova - 2025-10-06 | |||
| 07:46:31 | opendevreview | Julien LE JEUNE proposed openstack/nova master: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963156 | |
| 07:49:22 | opendevreview | Julien LE JEUNE proposed openstack/nova master: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963156 | |
| 07:56:38 | nicolairuckel | I'm working on this patch to persist the NVRAM: https://review.opendev.org/c/openstack/nova/+/959682 So far it works for all migrations but I habve to manually add read permissions to `instance-0000003_VARS.fd`. The file for `disk` already has those. In the libvirt IRC they told me that not having global read permissions is intentional and I'm wondering why the disk in Nova has those permissions and how I | |
| 07:56:38 | nicolairuckel | can set them for the NVRAM file as well. I asked this in the libvirt channel and was told that this might be a better place for this question. | |
| 08:48:46 | opendevreview | Julien LE JEUNE proposed openstack/nova master: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963156 | |
| 09:37:23 | opendevreview | Julien Le Jeune proposed openstack/nova master: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963156 | |
| 10:30:00 | sean-k-mooney | gibi: i dont know if you read this comment https://review.opendev.org/c/openstack/placement/+/962776/comment/f68ed8e5_0803b616/ but when i was running the tests locally i noticed that changing the request_limit paramter had no perforncem imporment | |
| 10:30:04 | sean-k-mooney | """ min(conf.max_allocation_candidates, requst_limit) """ | |
| 10:30:15 | sean-k-mooney | i think we are missing ^ somewhere | |
| 11:16:26 | gibi_ | sean-k-mooney: we intentionally not changed the meaning of the limit parameter when max_allocation_candidates was introduced due to | |
| 11:16:29 | gibi_ | Placement generates these candidates fully before applying the limit parameter provided in the allocation candidate query to be able do a random sampling if [placement]randomize_allocation_candidates is True. | |
| 11:16:52 | gibi_ | the limit parameter is applied last | |
| 11:17:01 | gibi_ | if we change that then that changes how randomize_allocation_candidates behave | |
| 11:17:10 | gibi_ | so we did not changed limit | |
| 11:35:43 | sean-k-mooney | hum i see | |
| 11:35:48 | sean-k-mooney | that is unfortunate | |
| 11:36:04 | sean-k-mooney | but i guess that the legacy we are stuck with | |
| 11:37:03 | sean-k-mooney | there are two cases i guess to consdier request_limit < max_allocation_candidates | |
| 11:37:31 | sean-k-mooney | i was hoping in this case we coudl treadt it as if max_allocation_candidates == request_limit | |
| 11:37:55 | sean-k-mooney | in the other case its already going to be enforced | |
| 11:39:09 | sean-k-mooney | i wonder if we coudl implemetn the randomize_allocation_candiates diffently | |
| 11:39:24 | sean-k-mooney | we currently have depthfirst or breathfirst search | |
| 11:39:48 | sean-k-mooney | but couldl we instead do a random search for that usecase. | |
| 11:40:49 | sean-k-mooney | it would not be exactuly the same behavior but the randomisation was really there because of the orginial depth first approch to generating candiates | |
| 11:41:07 | sean-k-mooney | if we are using breathfirst its much less required | |
| 11:41:49 | sean-k-mooney | that a sepreate poblem then the one that your trying to fix but i wonder fi we should conitnue to supprot that if we cant apply optimisation based on teh request limit | |
| 11:42:51 | sean-k-mooney | in otherwords i think we could provide randomness in the generation fo the candiate without needign to generate all of them and doing a random choice at the end | |
| 11:43:20 | sean-k-mooney | that would fulfil the same usecase but with a lot less wasted effort | |
| 11:43:40 | sean-k-mooney | maybe another topic for the ptg dicussion? | |
| 11:46:27 | sean-k-mooney | gibi: basically im not sure that genrating all possible candiate is part of the api contract fo that parmater so we shoudl be free to evolve its meaning over tiem to be more effeictent provided it still has the same overall effect | |
| 11:57:21 | gibi | I'm OK to discuss this on the PTG. But for me this is a small issue that limit and max_allocation_candidates has two different meaning today | |
| 11:58:44 | sean-k-mooney | ya its minor but it means the clinet cant contol the perfoamce of the request by asking for less cnadiates in the responce | |
| 11:59:15 | sean-k-mooney | to me it undermines why the request_limit parmater exists in the api in the first place | |
| 11:59:36 | gibi | that parameter from the start only limited the size of the response nothing lese | |
| 11:59:39 | gibi | else | |
| 12:00:51 | sean-k-mooney | sure but i woudl expect it to do more then that as an end user and it prevent nova for example form being smart and say (i knwo this query might generate a lot of candiate so im going to use a lower limit dynicmicly) | |
| 12:01:01 | sean-k-mooney | not that nova has the intelegents to know when it shoudl do that | |
| 12:01:20 | sean-k-mooney | so its not a blocker but i just find it surprising | |