Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-09
15:21:57 bauzas stephenfin: apologies btw. I fucked up with your point, I thought you were arguing about what I fixed in PS11
15:22:11 bauzas looks like multitasking with kids raises bugs
15:22:27 bauzas -ETOOMANYTHINGS
15:23:53 stephenfin bauzas: Um, I am :) I'm saying I think you need to hard fail at https://review.opendev.org/#/c/715490/11/nova/virt/libvirt/driver.py@815 and *not* hard fail at https://review.opendev.org/#/c/715490/11/nova/virt/libvirt/driver.py@6531
15:24:07 bauzas yup, I finally understood
15:27:57 bauzas stephenfin: worth saying, do you think we should return a InvalidLibvirtGPUConfig within https://review.opendev.org/#/c/715490/11/nova/virt/libvirt/driver.py@815 ?
15:28:02 bauzas or another exception ?
15:28:19 stephenfin It's invalid config, so that makes sense IMO
15:28:21 bauzas I honestly think the operator messed up their config if so
15:28:26 bauzas yup, ok
15:30:29 bauzas stephenfin: to answer your last comment on https://review.opendev.org/#/c/715490/11/nova/virt/libvirt/driver.py@815 ,
15:31:05 bauzas if the operator messes up their config and self._get_vgpu_type_per_pgpu(parent) can't find the right vgpu type because $mess
15:31:25 bauzas then we get a None value and the conditional statement fails
15:32:31 bauzas stephenfin: but unless the operator did provided a section for each of the vGPU types and added devices, you're right, we fall back to only supporting one type, like we did previously
15:34:46 stephenfin cool. gtk I was reading that correctly
15:47:28 openstackgerrit Sylvain Bauza proposed openstack/nova master: Functional test with pGPUs https://review.opendev.org/717975
15:47:28 openstackgerrit Sylvain Bauza proposed openstack/nova master: Support different vGPU types per pGPU https://review.opendev.org/715490
15:47:55 bauzas stephenfin: sean-k-mooney: gibi ^
15:49:23 sean-k-mooney i like how gerrit leaves the filtes ticked if they have not changed form the last revision
15:49:27 sean-k-mooney looking now
15:50:49 gibi bauzas: ack
15:50:57 gibi will look shortly
15:51:21 gibi nova meeting starts in 9 minutes on #openstack-meeting-3
15:52:04 bauzas gibi: sean-k-mooney: shit, forgot to remove two things, will provide a FUP if you don't disagree
15:52:33 stephenfin bauzas: https://review.opendev.org/#/c/715490/12/nova/virt/libvirt/driver.py@817
15:52:37 stephenfin ah, guess that's one of them
15:52:57 stephenfin just respin it now? not like it's even in the queue yet
15:52:58 sean-k-mooney the continue
15:52:59 bauzas stephenfin: yup
15:53:06 bauzas stephenfin: okay, just doing
15:53:08 sean-k-mooney i have a commnet i was going to make
15:53:20 sean-k-mooney its just dead code so it wont break anythying but ya
15:54:45 bauzas uploading a new rev as of I speak
15:55:01 openstackgerrit Sylvain Bauza proposed openstack/nova master: Functional test with pGPUs https://review.opendev.org/717975
15:55:01 openstackgerrit Sylvain Bauza proposed openstack/nova master: Support different vGPU types per pGPU https://review.opendev.org/715490
15:55:05 bauzas (live my life, DSL with 1Mbps up)
15:55:21 bauzas stephenfin: sean-k-mooney: gibi: sorry, last rev ^
15:55:32 sean-k-mooney big claime :P
15:55:33 gibi last? are you sure? ;) (just kidding)
15:55:41 bauzas latest*
15:56:21 sean-k-mooney bauzas: so out of scope for this cycle but is there any reason in victora we could not auto report custom triats for the vgpu providres
15:57:07 bauzas sean-k-mooney: it's within the spec, said as "planned"
15:57:17 sean-k-mooney bauzas: so we can skip https://review.opendev.org/#/c/715490/13/doc/source/admin/virtual-gpu.rst@290
15:57:21 sean-k-mooney ok cool
15:57:36 sean-k-mooney doing it manually for now is fine by the way i was just wondering
15:58:07 gibi bauzas: Is there proper 4G coverage where you live? that would be a lot more than 1Mbps
15:58:42 sean-k-mooney gibi: bauzas was ment to be getting fiber a few months ago but there were issues
15:59:24 bauzas sean-k-mooney: I did not implemented it on purpose since mdev types are passed directly from the kernel driver without any kind of abstractional outcome
15:59:49 sean-k-mooney bauzas: sure i dont really thing that is a proablem
15:59:56 bauzas from my position, it is
16:00:11 sean-k-mooney we dont really have an abstration for cpu flags
16:00:20 sean-k-mooney we do some normallisation but very little
16:00:30 sean-k-mooney its basically the same thing
16:00:37 bauzas if nvidia decides that nvidia-31 is no longer a thing and just uses a new typename, say nvidia-mygoo for the same headset etc. then nova would be impacted
16:00:43 openstackgerrit Merged openstack/nova master: Temporarily skip TestNovaMigrationsMySQL https://review.opendev.org/718629
16:01:40 sean-k-mooney bauzas: sure, same is mostly true for cpu flags. we could provide a mapping layer if we wanted via config but anyway some other days problem
16:02:12 bauzas sean-k-mooney: yup, CPU flags are the exact same things
16:02:20 bauzas using traits for them is terrible
16:02:34 sean-k-mooney bauzas: traits exits basicaly because of them
16:02:38 bauzas we somehow need a versioned mapping table
16:02:51 sean-k-mooney we do that in some places but not others
16:02:54 bauzas for managing libvirt versions (and even kernel versions) against trait names
16:03:13 sean-k-mooney bauzas: not really its considerdf part of the public api of the cpu
16:03:28 sean-k-mooney if they change it will break gcc and many many other things
16:06:31 sean-k-mooney bauzas: anyway for what its worth here is the cpu fetaru flag mapping table
16:06:33 sean-k-mooney https://github.com/openstack/nova/blob/c5f3d3b73256ff0d31e1c1a972909228287c3f64/nova/virt/libvirt/utils.py#L51
16:07:08 bauzas sean-k-mooney: tbc, I think cpu flags are considered with more cautiousness than mdev types, y'know
16:07:52 sean-k-mooney bauzas: maybe but if they ever change the mdev type we are already screwed
16:08:05 sean-k-mooney the existing vms wil not be able to boot
16:08:34 bauzas yeah maybe I'm overthinking it
16:09:04 bauzas but at least having some way to prevent a possible API trait explosion in nova would be nice (and that was drafted in the spec likewise)
16:10:04 sean-k-mooney bauzas: but didnt you hear plamcent and traits will solve all problems :)
16:10:41 bauzas this alleviates some problems but raises other concerns, I'd politically say :-)
16:16:48 sean-k-mooney dansmith: thanks for the review on the cyborg stuff
16:16:59 sean-k-mooney i responded to your comments
16:17:05 sean-k-mooney also is nova meeting now
16:17:18 dansmith ack
16:17:19 sean-k-mooney yes ill go join that
16:20:51 bauzas sean-k-mooney: you mean the warning that was filling the logs ?
16:20:58 bauzas (re: policy and olso)
16:21:03 bauzas oslo*
16:21:52 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Change UEFI check to handle AArch64 better https://review.opendev.org/714311
16:22:45 sean-k-mooney bauzas: yes
16:23:20 sean-k-mooney bauzas: i think we have stop it by disabling it entirly a temp messure but gmann is altering oslo to do it properly
16:23:35 bauzas k, thanks for the heads up
16:23:43 sean-k-mooney so if you manually set it you will get the deprecation warning but not for the defualts
16:24:25 gmann bauzas: sean-k-mooney this is nova change to adopt the new flag, waiting for new version of oslo.policy - https://review.opendev.org/#/c/717884/
16:25:17 gmann its working fine so once we have olso release then i will update the lower constraint and remvoe WIP
16:26:18 sean-k-mooney cool. the cyborg patch seres is like 100 commits behind master so i still get the wall fo error if i touch nova manage
16:26:28 sean-k-mooney so it will be nice when that is all resovled
16:31:12 gmann lbragstad: on gate, somehow new flag is not reflecting due to oslo checkout etc but tested localyl and it worked fine - https://review.opendev.org/#/c/717943/2
17:00:43 bauzas gibi: can you put some vote on https://review.opendev.org/#/c/715490/13 before you leave ?
17:00:55 gibi will do
17:01:00 bauzas you already +1d with comment saying you'd want to review the functest
17:01:04 bauzas thanks
17:01:08 bauzas (and I know this is late)
17:01:37 bauzas gibi: working at home btw. during the lockdown or back to the office ?
17:01:39 gibi I will do the cycle highlught patch anyhow
17:03:42 gibi bauzas: I'm home in the last 3 weeks
17:04:01 gibi or 4? I dont even remember

Earlier   Later