Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-06-15
07:55:45 bauzas and see what people think
07:55:52 sean-k-mooney[m] i thikn since walaby when stepehnfin pushed to get parity
07:55:58 bauzas yay
07:56:02 bauzas again, see the metrics
07:56:06 bauzas Queens and beyond
07:56:13 sean-k-mooney[m] honestly i dont think that helps in any way
07:56:24 sean-k-mooney[m] i was assumeing they already had that and it was not sufficent
07:56:33 sean-k-mooney[m] but sure they may be on old clouds
07:56:37 sean-k-mooney[m] so maybe its enough
07:56:56 jkulik I get the approach of keeping the scope small and saying "we support osc, everything else is out of scope". But adding features like this only to osc will keep them away from a lot of customers on our side, so it might as well not be there. No hard feelings.
07:56:58 bauzas trust me, they use very old relases
07:57:34 bauzas jkulik: we support any client able to access our REST API
07:58:02 sean-k-mooney[m] well technially we supprot the apis not the client
07:58:02 bauzas we even support clients that aren't able to negociate with the API about new microversions
07:58:27 sean-k-mooney[m] we dont supprot any client excpet nova client from a project perspective
07:58:28 bauzas here, we're not brainstorming about a lack in our APIs
07:58:55 jkulik then I don't get why you would propose to add the feature to a single client instead
07:58:59 bauzas and again, I'm afraid bfv-auto would generate kind of a config-driven API
07:59:29 bauzas jkulik: I'd propose other clients to do the same, to be precise
07:59:29 sean-k-mooney[m] well that is why i suggested the falvor
07:59:34 jkulik config-driven API is where the values, the API should get via request comes in from other sources e.g. flavor or config?
07:59:57 sean-k-mooney[m] no it explcitly refer to useing nova.conf values to alter behavior
08:00:04 jkulik ah, thanks
08:00:15 bauzas like, delete_on_termination
08:00:28 sean-k-mooney[m] that is not a config value is it
08:00:34 sean-k-mooney[m] i did not think it was
08:00:43 bauzas ah my bad, bad example
08:00:53 sean-k-mooney[m] the option i normall think of is force_configdrive
08:01:04 sean-k-mooney[m] which is a config value
08:01:31 bauzas honestly, I'm not opposed to add a way to describe automatic bfv, but we seriously need to consider the impacts
08:01:59 bauzas and I personally have concerns with the solution be a flavor extraspec
08:02:06 sean-k-mooney[m] ack
08:02:12 sean-k-mooney[m] ya thats fair
08:02:33 sean-k-mooney[m] i think i would want to see the last partity gaps get closed which i think is just rebuild first
08:02:50 bauzas agreed
08:03:25 sean-k-mooney[m] up until this cycle the delta for bfv and non bfv was too much to not have teh user be aware of which it was going to use ectra.
08:03:37 jkulik hm ... if not flavor extraspecs where else? we also have baremetal flavors, which can't even use volume storage in our cloud
08:03:58 bauzas sean-k-mooney: that's the problem with operator feedback
08:04:04 sean-k-mooney[m] jkulik actully they could depending on yoru release
08:04:15 sean-k-mooney[m] ironic support boot form cinder via iscsi
08:04:19 bauzas sean-k-mooney: ideally I think we should propose a talk or some live thing about what nova can do with bfv noxw
08:04:36 jkulik sean-k-mooney: not in our cloud. all volume-types are in some vmware datastores ... :(
08:04:36 bauzas to let people know about what BFV is today
08:05:11 sean-k-mooney[m] jkulik its pretty new too only like 2-3 relases i think
08:05:32 sean-k-mooney[m] bauzas ya a general bfv talk woudl be good
08:06:22 sean-k-mooney[m] basically a bfv “state of the union” talk of hay with z this is how it can now be used
08:06:23 bauzas Vancouver is too far away
08:06:46 sean-k-mooney[m] i would wait for vancouver honestly
08:06:54 sean-k-mooney[m] well
08:06:59 sean-k-mooney[m] at least for zed to release
08:07:07 bauzas after Zed, this is fair
08:07:15 sean-k-mooney[m] but maybe as a follow up to the project highlights
08:07:17 bauzas I should run a project update thing anyway
08:07:54 sean-k-mooney[m] ok brb
08:17:15 opendevreview Balazs Gibizer proposed openstack/nova master: Optimize numa_fit_instance_to_host https://review.opendev.org/c/openstack/nova/+/845896
08:17:43 gibi sean-k-mooney: ^^ let me know what you think. I might missed some side effect in the algo that makes this optimization actually breaking change
08:20:19 sean-k-mooney gibi: have not read it yet but when i see cache are you assume all instance numa ndoes will have the same requirements
08:20:41 sean-k-mooney oh you are caching the pairs
08:20:45 sean-k-mooney ok that should work
08:20:48 sean-k-mooney ill read the rest
08:20:52 gibi sean-k-mooney: I cache the result of the _numa_fit_instance_cell for host_cell instance_cell pairs
08:21:15 sean-k-mooney yep pairs are fine to cache
08:22:25 sean-k-mooney that break will jsut break the inner loop right
08:22:55 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/845896/1/nova/virt/hardware.py#2376
08:23:14 gibi yepp break jumps out from the inner loop
08:23:34 sean-k-mooney then i dont see why this would not work
08:23:34 gibi if you look at the except: branch it uses there too with the same effect
08:23:59 sean-k-mooney and its just storing pairs of ints so the memory overhead will be trivial
08:24:20 gibi yepp it is len(host_cells) * len(instance_cells) * 2 integeres
08:24:52 gibi that is a lot lest than then n!/(n-k)! number of fit calls the algo made
08:25:01 sean-k-mooney so like with comptueing factorial this shoudl reduce to the cell checks to linear
08:25:09 sean-k-mooney form O(n^2)
08:25:20 gibi it is actuall O(n!/(n-k)!)
08:25:34 gibi I mean it was
08:25:38 sean-k-mooney ya just realised that it much large then n^2
08:26:09 sean-k-mooney its n choose m
08:26:29 gibi yeah we generate k long permutations from N items
08:26:51 sean-k-mooney so even with that optimiasation do we still want to change the default on mater
08:27:04 gibi sean-k-mooney: yepp, probably
08:27:17 sean-k-mooney with the sperad default it found a candiate on the first iteration
08:27:35 sean-k-mooney did you try thet repoducer with your chage
08:27:45 sean-k-mooney if not i was going to try that now
08:27:47 gibi the cache change helps with the forst case, the default change only helps in some case
08:28:13 gibi the reproduce took 6 mins for me without the cache, with the cache it took 3 seconds
08:28:33 gibi s/forts/worts/
08:28:34 sean-k-mooney nice
08:29:08 sean-k-mooney so still double spreaing but much much more reasonable
08:31:03 sean-k-mooney gibi: so other then a releasenote im not sure what elese to add to that patch.
08:31:19 sean-k-mooney im not sure we want to unit test using a cache
08:31:38 sean-k-mooney and fucntional test should not be able to tell the differnce
08:31:52 gibi yepp I hope functional will tell me that everything works as is
08:32:20 gibi I can add a unit test that shows that the cache works by mocking and counting the _numa_fit_instance_cell inner calls
08:32:27 sean-k-mooney they should i don tthink you have change the outcome in anyway
08:33:03 sean-k-mooney gibi i woudl only do that if you pull out that code into its own fucntion
08:33:13 sean-k-mooney that code bing the inner loop
08:33:47 sean-k-mooney i think this is too much of an implemation detail to asser for the top level numa_fit_instance_to_host fucntion as it is
08:34:01 opendevreview ribaudr proposed openstack/nova master: Allow unshelve to a specific host (Compute API part) https://review.opendev.org/c/openstack/nova/+/831507
08:34:02 opendevreview ribaudr proposed openstack/nova master: Allow unshelve to a specific host (REST API part) https://review.opendev.org/c/openstack/nova/+/845897
08:34:14 sean-k-mooney espically since its a function scoped cache
09:33:08 gibi yeah I dropped the unit test idea. after played around it a bit it seems very artifical

Earlier   Later