Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-06-15
07:52:32 bauzas then, personnally I feel the problem solved.
07:52:41 jkulik but not auto-bfv
07:52:56 bauzas then patch the client
07:53:11 jkulik yeah, I can do that. again, doesn't help my customers ;)
07:53:14 bauzas and patch any other fancy client
07:53:18 jkulik I'll patch Nova instead thus. downstream
07:53:47 sean-k-mooney[m] we have openstack server create —boot-form-volume <size> today
07:54:54 sean-k-mooney[m] so ^ is our baseline in terms fo client just incase you were not aware bauzas
07:55:02 bauzas sean-k-mooney: thanks, appreciated
07:55:07 bauzas I was looking at the client docs
07:55:23 sean-k-mooney[m] its here https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-create
07:55:40 bauzas sean-k-mooney: we can move on the etherpad and propose the CLI usage
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.

Earlier   Later