Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-10-03
16:20:36 Uggla I can try to accommodate the timeslot as much as possible with your timezone.
16:20:36 Uggla @nisha04 I think we could find a slot at the OpenInfra Summit to do some kind of pre-check.
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 I will also try to find you in the hallway during the summit and hope to have a quick chat sometime.
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: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 optimize_for_wide_provider_trees https://review.opendev.org/c/openstack/nova/+/963036
11:02:31 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: test with placement fix https://review.opendev.org/c/openstack/nova/+/963035
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 optimize_for_wide_provider_trees https://review.opendev.org/c/openstack/nova/+/963036
14:48:15 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: test with placement fix https://review.opendev.org/c/openstack/nova/+/963035
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 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.
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
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
12:02:06 sean-k-mooney gibi: i noticed you commented on your inlining patches that they dont seam to provide a benifit
12:02:27 sean-k-mooney gibi: do you think that is a dead end or are you plannign to do more expermients in that direction
12:03:22 gibi unfortunately the randomize_allocation_candidates option defined as
12:03:23 gibi If True, when limiting allocation candidate results, the results will be a random sampling of the full result set.
12:03:34 gibi *full result set* :/
12:03:59 gibi sean-k-mooney: the first inlining helps, the second not much
12:04:05 sean-k-mooney right but it does not define what the full result set is
12:04:36 gibi this helps If True, when limiting allocation candidate results, the results will be a random sampling of the full result set.
12:04:39 gibi sorry
12:04:41 gibi wrong buffer
12:04:47 gibi this helps https://review.opendev.org/c/openstack/placement/+/963052/1/placement/tests/functional/test_allocation_candidates.py#265
12:05:08 gibi this does not really help https://review.opendev.org/c/openstack/placement/+/963053/2/placement/tests/functional/test_allocation_candidates.py
12:05:10 sean-k-mooney gibi: so inlining _consolidate_allocation_requests helps but not exceeds_capacity
12:05:14 gibi yep
12:06:30 sean-k-mooney i see form the comment you have been trying to use some profiles to help with this, have you found that useful
12:06:41 gibi I will not trying to inline more, the profiler shows that the time is spent on hashing and eqality checking the building blocks but I don't see easy moves there
12:07:02 gibi I used just the built in cProfiler
12:07:09 gibi as you can see in the commented out code
12:07:22 sean-k-mooney ya i was just wondering if the output was useful
12:07:32 sean-k-mooney i have never used that before hence the question
12:08:04 gibi it tells you what called how much and what time it took so it shows you where your spending your execution time
12:08:43 gibi it showed that consolidate is more expensive than exeeced_capacity
12:08:57 sean-k-mooney ack, i have used flamegraph profilers in other lanaguges in the past just never really used those types of tools much with openstack because they hate eventlets
12:09:13 sean-k-mooney placement fortunetly does not use eventlet so that is not an issue
12:09:22 gibi yeah, I just enabled it in athe _merge_candidate call so no parallism was involved
12:09:33 sean-k-mooney but i tried to use them on nova once on the schduler and they were not really that useful when used as external tools
12:10:19 gibi I'm now providing test coverage for the prune patch and we can decide together when dansmith is up that which inlining patch if any we want to take in
12:10:41 sean-k-mooney how do you feel about this overall approch for the current bug. are you happy that it gives us enough breathing room for the current reproted edgecase to move forward with for now?
12:12:23 gibi I think the prune patch already give us time to re-thing the modeling. I think the inlining of the _consoliodate call is still have a good ROI on code complexity. I would at least merge these two optimization. I will then go and update our backlog space about the problem with the new learning and we can discuss on the PTG. My attached customer case probably closable with only the prune patch in
12:12:43 gibi s/space/spec/
12:12:45 sean-k-mooney im kind of suprised that manual function inlineing has such an effect in a dynmic language like python. what python version were you testing with out of interest?
12:13:15 gibi Python 3.12.10 (main, Apr 9 2025, 04:44:59) [GCC 14.2.0] on linux
12:13:36 sean-k-mooney ack i wonder if the impact is large on say 3.10 or 3.9
12:13:43 gibi note that it wasn't pure inlining, it was actually using the commulative nature of the call to save actual steps
12:14:02 gibi cumulative
12:14:24 sean-k-mooney ah ok i was actully trying to pull up the orginal code to comare whiel we were chatting but i have not fond that yet
12:14:47 sean-k-mooney wel i have not been trying very hard :)
12:15:42 sean-k-mooney oh its in your previous patch
12:15:45 gibi consolidate merges the allocations of the different request groups, with the new product algo this was done on each prefix of those groups. but merging G1 + G2 and G1 + G2 + G3 can be optimized if G1 + G2 is only calculated once not twice
12:15:52 sean-k-mooney that explains why it was not in github https://review.opendev.org/c/openstack/placement/+/962776/5/placement/objects/allocation_candidate.py#850

Earlier   Later