Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-11
20:01:09 sean-k-mooney well require=!HW_NUMA_ROOT would be the detla form train i guess
20:01:22 sean-k-mooney but if no host reports numa thats a noop
20:01:55 efried In this new picture, I'm not sure we need/want to forbid that trait.
20:02:09 sean-k-mooney we dont
20:02:16 sean-k-mooney if we are allowed to invent numa toplogies
20:02:26 sean-k-mooney we could specificly to land on un upgraded hosts
20:02:30 sean-k-mooney but it has no other use
20:02:55 efried in this case we don't *want* to target un-upgraded hosts.
20:03:05 efried we want to *allow* landing there, but not *force* it ever.
20:03:18 sean-k-mooney sure
20:04:08 efried hum, but what we don't want is to land across numa nodes on an upgraded host. So yeah, I think the 'fallback' query in both cases should have !HW_NUMA_ROOT.
20:04:23 sean-k-mooney so [scheduler]max_implicit_numa_nodes=0 means dont add HW_NUMA_ROOT or granular groups, anyting above 0 is the amount of numa nodes to try for progressive spliting
20:04:51 efried yeah. But only for NUMA-agnostic flavors. For NUMA-aware flavors, we have an explicit number of nodes we're trying for.
20:05:03 sean-k-mooney yes
20:05:09 efried Do you have it in you to write this up, sean-k-mooney?
20:05:27 efried I made a start on it, but I need to step away for... possibly the rest of the day.
20:05:32 sean-k-mooney ill start a second etherpad.
20:05:45 sean-k-mooney or if you have a start put it in one and i can extend it.
20:06:01 sean-k-mooney efried: do we still need teh per host config option in this model
20:06:15 sean-k-mooney i think no if we do the progressive spliting
20:06:34 sean-k-mooney but we might want to for perfomcne reasin if we jsut want to turn it off
20:06:58 efried yes we do, because sometimes the progressive splitting won't get a result, and they want to force a host to behave like a Train host.
20:07:15 sean-k-mooney ok
20:07:17 efried but that's why the workaround is *off* by default. You have to really need it to turn it on.
20:07:35 sean-k-mooney ok that makes sense
20:07:59 sean-k-mooney dansmith: would you be oke with a [scheduler]/max_implicit_numa_nodes config option
20:08:13 sean-k-mooney to contol the progessive spliting
20:08:34 efried "config-driven API behavior" warning. Not sure I see a better alternative though.
20:09:26 sean-k-mooney efried: well the virt driver can today dowhatever the hell it like in this case anyway so im not sure its an observable thing
20:09:34 sean-k-mooney at least form the api perspctive
20:09:46 sean-k-mooney but i get where your coming form
20:15:47 dansmith that's totally not config-driven api behavior
20:15:52 dansmith and yes, I think that's fine
20:18:17 sean-k-mooney ok ill try to write this up in a comment to the spec and then ill try not to melt bauzas brain when i try to explain this to him tomorrow in our downstream tech call
20:18:54 sean-k-mooney i think 90% of the spec woudl remain the same we just need to update the section that refence the fallback and upgrade impact
20:22:14 efried sean-k-mooney: I left a comment
20:22:35 efried I think I covered the high points, but I'm pretty fried (*e*fried) so I probably missed some things, if you want to fill in.
20:22:41 efried gtg o/
20:22:57 sean-k-mooney efried_afk: ill review it after coffee
20:23:00 efried_afk thx
20:23:01 sean-k-mooney efried_afk: o/
21:53:38 gmann johnthetubaguy: what you think of passing service as actual target in service policies? - https://review.opendev.org/#/c/676688/8/nova/api/openstack/compute/services.py
22:35:04 artom We should probably address those errors when running func tests:
22:35:05 artom assert len(_active) == 1
22:35:05 artom File "/usr/lib64/python3.7/threading.py", line 1373, in _after_fork
22:35:05 artom Traceback (most recent call last):
22:35:05 artom Exception ignored in: <function _after_fork at 0x7f6382a2ed40>
22:42:35 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Skip all integration jobs for policies only changes. https://review.opendev.org/707268
22:43:20 gmann efried_afk: stephenfins dansmith gibi melwitt ^^ this will speed up the gate for policy BP changes.
22:43:33 gmann alex_xu: ^^
22:44:26 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Skip to run all integration jobs for policies-only changes. https://review.opendev.org/707268
22:44:53 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Skip to run all integration jobs for policies-only changes. https://review.opendev.org/707268
23:06:01 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Skip to run all integration jobs for policies-only changes. https://review.opendev.org/707268
23:06:16 gmann melwitt: updated ^^
23:06:31 melwitt ack
23:23:10 sean-k-mooney dansmith: efried_afk: i did a thing. https://review.opendev.org/#/c/552924/17/specs/ussuri/approved/numa-topology-with-rps.rst@516
23:23:38 sean-k-mooney dansmith: efried_afk its a trivial poc of the progresive generation of the numa toplogies for a non numa vm
23:24:19 sean-k-mooney just the toplogy object not the queries but i could proably hack that up tomorrow
#openstack-nova - 2020-02-12
09:02:31 gibi efried_afk, sean-k-mooney, dansmith: read up on the numa fallback discussion from yesterday. impressive work. I need to digest the result
09:30:22 openstackgerrit ZhouHeng proposed openstack/nova-specs master: Support set port vnic type to create server https://review.opendev.org/672400
09:38:36 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Fix attached encrypted LUKSv1 volume extension https://review.opendev.org/706900
09:44:21 openstackgerrit Guo Jingyu proposed openstack/nova-specs master: Proposal for a safer noVNC console with password authentication https://review.opendev.org/623120
10:00:57 bauzas gibi: yeah I did it too
10:01:06 bauzas I'll work on a new revision
10:14:40 bauzas gibi: honestly, I'm looking at https://review.opendev.org/#/c/552924/17/specs/ussuri/approved/numa-topology-with-rps.rst@516 and I don't know what the outcome consensus...
10:14:49 bauzas what is*
10:15:39 bauzas gibi: efried_afk tried to summarize but that's still a bit confusing for me
11:26:25 gibi bauzas: I had a doctors appointment until now and now jump on the meeting. After that I will try to summarize how I understood the consensus
11:26:40 gibi and crosscheck it with your summary
11:26:42 bauzas merging two calls AFAIK
11:26:58 bauzas AFAICU*
11:27:13 bauzas anyway, i'll try to provide a new revision
11:46:24 sean-k-mooney bauzas: gibi im just going to grab a coffe but do you want to have a quick bluejeans call to recap on where we are with the numa spec
11:47:09 sean-k-mooney i can explain what the alternitive is in more detail. i think the last sticking point is just the default and how the query is done
11:48:01 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.opendev.org/552924
11:48:07 bauzas sean-k-mooney: sorry but no
11:48:18 bauzas I need to go lunch and then I'll have a doctor appointment
11:48:28 bauzas at 2pm
11:48:33 bauzas (my time)
11:48:45 bauzas remember, not all people work after 6pm
11:49:20 bauzas sean-k-mooney: and when i read your comments that are around 3am your time, my point is : 'heh, Sean, please go to bed!" ;)
11:49:35 sean-k-mooney hehe
11:49:48 sean-k-mooney i did whihc is why i started at 11
11:50:04 bauzas I was a night owl
11:50:16 bauzas but then my brain fried 4 years ago
11:50:21 bauzas or maybe 3
11:50:29 bauzas actually, 3
11:50:54 sean-k-mooney i can try and sumerises in the spec but and in our internal tech call what i discussed with dansmith and efried_afk last night
11:51:25 sean-k-mooney i was fine with the pervisous revision with the fallback query
11:51:46 openstackgerrit ZhouHeng proposed openstack/nova-specs master: Support set port vnic type to create server https://review.opendev.org/672400
11:52:19 sean-k-mooney but the alternitive is to enable numa reporting by default and then make all non numa instance have a numa toplogy dynamicaly by makeing multiple queries with differnt numa toplogies upt to a max numer of numa nodes
11:53:06 sean-k-mooney so large instance that cant fit on one numa node would dynamicaly get split across up to X numa nodes as defiend in the schduler config
11:54:06 sean-k-mooney if you set the max to 0 it disabel the implcit numa creation and large non numa guest could only land on hosts with numa reporting disabled or train hosts during an upgrade
12:11:04 sean-k-mooney bauzas: also not sure if you saw ^ we can talk about it in the tech call too if you can make that
12:43:34 bauzas sean-k-mooney: thanks, I need to be in a doctor's appointment in 15 mins, back around 1.45pm UTC I think
12:54:14 openstackgerrit ZhouHeng proposed openstack/nova-specs master: Support set port vnic type to create server https://review.opendev.org/672400
13:32:00 stephenfin efried_afk, bauzas, gibi, others: I hope I'm not overstepping things by -2ing this, but it seems clear to me that we've decided not to do orchestration stuff, right? https://review.opendev.org/#/c/672400/
13:32:52 gibi stephenfin: I support your -2
13:33:27 gibi stephenfin: a similar spec for port mac address https://review.opendev.org/#/c/700429/
13:37:43 stephenfin gibi: I've also -2'd that. Happy to take the backlash

Earlier   Later