Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-10-03
09:42:13 bauzas I don't have a lot of context but I'll try to find it :)
09:42:25 gibi that patch removes two debug logs that is it
09:42:26 gibi :)
09:42:41 gibi those debug logs generated gigabyte of logs
09:42:48 gibi in certain queries
09:43:04 bauzas ahah I see, then hopefully it should be simple to review :)
09:43:10 gibi it is :)
09:43:24 gibi the rest is a lot more complex and not ready for final review
09:45:06 bauzas yup, saw it
09:45:07 bauzas +2d
09:45:12 gibi thanks
09:45:17 gibi have a nice session in the gym
09:45:35 Uggla ping sean-k-mooney about https://launchpad.net/nova/2026.1
09:45:43 bauzas well, it will be outside :)
09:45:57 bauzas more a cardio session than a gym
09:48:32 sean-k-mooney[m] Uggla: that looks correct as do the status of the other serise +1
10:05:37 opendevreview Balazs Gibizer proposed openstack/placement master: Reproduce GET a_c slowness bug/2126751 https://review.opendev.org/c/openstack/placement/+/962596
10:05:38 opendevreview Balazs Gibizer proposed openstack/placement master: Prune search space by invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776
10:13:13 opendevreview Balazs Gibizer proposed openstack/placement master: Prune search space by invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776
10:30:07 sean-k-mooney bauzas: the only releationship is the same person was proposing both specs
10:31:11 sean-k-mooney bauzas: masahito was interested in implente iothread, mapping io queue to iothread adnfilterign service by network in the last ptg
10:32:31 sean-k-mooney my io thread spec focuse just on the the simplest useful implemeation of iothread basicly spliting it out form the ioqueue work so it can be delivered independtly and incrementally
10:33:21 sean-k-mooney bauzas: im hoping masahito or noonedeadpunk or anyone else who is interested will have time to work on some of these prosposals this cycle
10:34:06 sean-k-mooney if not i will proably try to impelment one of the propsosal but i woudl prefe to just help them by reviewing there work
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

Earlier   Later