Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-09
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
17:04:31 bauzas gibi: I'm facing my 24th day in paradise
17:04:46 bauzas 25th actually
17:05:10 gibi paradise, lol
17:05:38 bauzas I honestly and frankly enjoy this period
17:05:57 bauzas I don't have to taxi the kids 4 times a day
17:06:07 bauzas I can arrange my worktime like I want
17:06:28 bauzas and my wife is stuck with me and discovering remote work
17:06:35 bauzas what dare could I complain ?
17:08:32 gmann gibi: cycle highlights lines for policy, let me know if it need to be shorten, also feel free to rephrase if needed - http://paste.openstack.org/show/791896/
17:09:19 gibi gmann: thanks a lot! looks good
17:09:36 gmann ok, thanks.
17:09:57 gibi bauzas: I have a fairly small flat in the middle of the capital. Now this place feels too small
17:11:25 gibi bauzas: I'm +2+A on the whole vgpu series
17:17:07 gibi cores: latest cycle highlights patch is up https://review.opendev.org/#/c/712498
17:17:24 gibi bauzas: btw, do you want to add a highlight about the vgpu work?
17:17:38 bauzas gibi: thanks
17:17:54 bauzas gibi: and nope for the highlights, it's a minor thing
17:18:04 gibi bauzas: ack. I just wanted to double check
17:19:40 gibi I think this is it for me today. I will check the gate tomorrow but will not work much

Earlier   Later