Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-11
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
13:37:51 gibi good :) thanks :)
13:45:49 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Remove 'test_cold_migrate_with_physnet_fails' test https://review.opendev.org/703115
13:45:50 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703117
13:45:50 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Block rebuild when NUMA topology changed https://review.opendev.org/703116
13:45:51 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: FUP for in-place numa rebuild https://review.opendev.org/703118
13:45:52 lyarwood sean-k-mooney: ^ just rebasing as stable/rocky should be passing again now and I'd like to land this before we switch over to EM
13:46:22 lyarwood aaaaaand I missed elod's comment
13:56:13 bauzas gibi: sean-k-mooney: I'm back
13:59:42 gibi bauzas: just replied with my understanding of Eric's summary
14:24:19 sean-k-mooney bauzas: just back too
14:24:37 sean-k-mooney had to go to my bank to sort things for the house purchase
14:25:16 bauzas gibi: coolio thanks
14:29:15 sean-k-mooney gibi: ya that is more or less a good summary
14:29:17 gibi bauzas: I think I got enough from efried_afk's summary that I see that my issue is solved by this propsal as well
14:30:05 sean-k-mooney gibi: well this still has the fallback which solves your main issue but also make the numa reporting the default which solve erics main issue of people using the fature after all this work
14:30:06 gibi sean-k-mooney: I treated the splitting algo as an impl detail for now. I think we can make it good enough and if not we have a way out
14:30:49 gibi sean-k-mooney: yeah, I'm OK that U compute is reshape by default
14:30:50 sean-k-mooney gibi: ya honelsty the poc i did would be good enouch in my book
14:30:58 gibi sean-k-mooney: agree
14:31:32 sean-k-mooney i will likely refacto that algoritim and submit a standalone patch later in the week
14:31:56 sean-k-mooney allowing asymetic spliting by default when you just set hw:numa_nodes is a minor change
14:32:03 sean-k-mooney and would be useful for numa instnaces
14:32:55 sean-k-mooney once we do that its just a matter of calling the get_numa_constratis function in a loop and generting the multiple queies and merging the results
14:44:22 huaqiang hi alex_xu
14:44:33 alex_xu huaqiang: i'm here
14:45:53 huaqiang do you mean, in the review of spec https://review.opendev.org/#/c/668656/, we have to mix 'hw:pinned_cpus' with 'resources:P|VCPU'
14:46:20 huaqiang BUT we should avoid the mixing of 'hw_pinned_cpus' with 'resources:xx;
14:46:27 huaqiang right?
14:47:06 alex_xu huaqiang: I mean it have to, althought we don't want that.
14:47:38 alex_xu I don't think we have other choice
14:49:58 huaqiang then there is no problem for setting the 'mixed' policy and cpu bitmask in image properties and then specify the PCPU and VCPU in flavor 'resources:P|VCPU'?
14:54:44 sean-k-mooney i have the mixed cpu spec open by the way so im going to try and finish reviewing it in the next hour or so before my next meeting
14:54:51 alex_xu huaqiang: yes, I think there is no problem
14:55:05 alex_xu sean-k-mooney: thanks
14:55:14 huaqiang sean-k-mooney: thank you :)
14:55:29 huaqiang alex_xu: got. thanks
14:57:01 sean-k-mooney alex_xu: are you largly happy with it?
14:57:19 alex_xu sean-k-mooney: yes, I think so
14:57:46 sean-k-mooney ok just wondering if you had pending comments. ill try and go through it form top to bottom now so
14:58:33 alex_xu no more pending comments.
15:03:26 Sundar gibi, dansmith, efried, sean-k-mooney: Trying to get my head around the rescheduling thing. Previously, the creation and binding of ARQs were happening in the compute manager. So, on failure, we just deleted the ARQs (which will be unbound by Cyborg if needed) and the retry would presumably have created/bound the ARQs on another node. Now the
15:03:27 Sundar create/bind are moved to the conductor, but that is done just before the RPC call to compute manager. So, could we still delete and recreate/rebind the ARQs?
15:04:21 dansmith Sundar: why is it any different?
15:04:52 sean-k-mooney so on a resudue instead of delete and recreate we can just rebind in the conductor
15:05:07 dansmith can we rebind? if so, then sure
15:05:18 sean-k-mooney if we cant delete and recreeate is fine too
15:05:32 sean-k-mooney we can update the host for an exisitng binding
15:05:41 sean-k-mooney it woudl be needed for move opertions anyway
15:05:52 dansmith well, not necessarily
15:05:55 dansmith depends on how they want to do it
15:06:06 sean-k-mooney i guess we could use a souce and dest arg
15:06:12 sean-k-mooney *arq

Earlier   Later