Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-12
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: Block rebuild when NUMA topology changed https://review.opendev.org/703116
13:45:50 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703117
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
15:06:22 sean-k-mooney that might be better in some ways
15:06:29 dansmith if they wanted another ARQ bound to the new host and a switch, or whatever
15:06:40 dansmith that's not what he's asking though I assume
15:06:41 sean-k-mooney ya like we now do with neutron ports
15:06:45 dansmith right
15:06:50 Sundar dansmith, sean-k-mooney: It may be simpler to delete and re-create, similar to the rest of the patches.
15:07:03 dansmith yeah, that's fine
15:07:07 Sundar Yes, I am not talking about migration, which is out of scope for now
15:07:08 sean-k-mooney Sundar: i think dansmith and i both think thats fine
15:07:23 Sundar Cool, thanks, dansmith and sean-k-mooney.
15:08:49 sean-k-mooney if delete and recreate makes runing through the cyborg state machicne to prepare the device on the dest simpler i think it also makes sense to just do that
15:09:38 sean-k-mooney i.e. for that reason on its own in addtion to the fact thats what the other patches do and the workflow you have been using
15:11:28 Sundar sean-k-mooney: The Cyborg state machine can technically handle ARQ_UNBOUND state, which is reached when you unbind an existing ARQ without deleting it (and distinct from Initial state). That may be of use in the future, but for now it is simpler IMHO to just delete and recreate.
15:11:59 sean-k-mooney cool works for me
15:12:20 sean-k-mooney Sundar: speaking of delete where you able to repoduce the vm delete issue i hit
15:12:38 Sundar I am not hitting it even after reboots.
15:12:50 sean-k-mooney with the fake driver
15:13:30 Sundar I mostly used the real FPGA driver, but shouldn't matter, one would think. But let me try with the fake anyway.
15:14:00 sean-k-mooney its a keystone auth issue so the driver should not make a difference but i dont know
15:14:49 sean-k-mooney i do now have access to a system with the same fpga you have. but 1 im not sure what image to use and 2 it currently has rhel 7.7 so i have not figured out how to deploy opensatck on it yet
15:15:15 sean-k-mooney i might see if it can be reinstalled with centos 7.7 or ubuntu 18.04 so that i can use devstack
15:18:28 Sundar What's the issue with RHEL 7.7?
15:19:15 Sundar I am using Centos 7.7
15:21:02 sean-k-mooney its not supported by devstack and im not sure i will be able to get it to install with out enable eple and rdo repos which dont technicaly support RHEL
15:21:36 sean-k-mooney im going to try and stack in a vm first with RHEL 7.7 but im expecting the subsription manager to get in the way
15:21:59 sean-k-mooney tl;dr im expecting missing packages
15:22:09 Sundar Got it.
15:22:49 sean-k-mooney if your using centos 7.7 and i have to reinstall ill just use that
15:30:27 sean-k-mooney huaqiang: some minor nits to clean up in a follow up patch but im +1 on the mixed cpu spec
15:31:35 sean-k-mooney stephenfin: i think you are probaly the best person to be the final +2 on https://review.opendev.org/#/c/668656/19 if you think its ready.
15:55:55 efried stephenfin: yes please, what sean-k-mooney said ^

Earlier   Later