Posted	Nick	Remark
#openstack-nova - 2019-08-15
16:13:35	openstackgerrit	Akihiro Motoki proposed openstack/nova master: DNM: WIP: PDF documentation build https://review.opendev.org/676730
16:13:44	stephenfin	I have no idea. sean-k-mooney and I have been discussing that
16:13:49	dansmith	melwitt: I agree with tssurya that archive should not look at the disabled flag
16:14:07	stephenfin	I'm not even sure how reshapes and FFU work in general
16:14:08	efried	stephenfin: My point, when you write the NUMA reshaper, is it also going to account for VCPU->PCPU-ness?
16:14:14	stephenfin	Ah, gotcha
16:14:16	efried	well... they don't, yet.
16:14:33	stephenfin	I guess we could just do it in order?
16:15:08	efried	yeah. Though we don't yet have any kind of infrastructure set up for "do these reshapes in this order".
16:15:18	efried	Like what happens for db migrations (right?)
16:15:20	stephenfin	So as we add reshapers, we follow the pattern started with vgpu and keep adding new '_update_provider_tree_for_foo' functions
16:15:26	stephenfin	i.e. https://review.opendev.org/#/c/674895/8/nova/virt/libvirt/driver.py@6926
16:15:29	mriedem	stephenfin: replied
16:15:55	stephenfin	*adding new functions below the existing functions
16:16:11	melwitt	dansmith: ack, thanks
16:16:48	stephenfin	mriedem: ta
16:17:37	efried	stephenfin: Yes, that's the idea. I suppose it would be nice to have it more codified. Especially since we're going to want some way to invoke these generically (i.e. from a non-virt-driver-specific engine) for FFU.
16:18:12	melwitt	and..... she left
16:18:17	efried	stephenfin: I draw your attention to http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004204.html
16:18:18	mriedem	efried: the FFU support for VGPU never happened right?
16:18:23	efried	mriedem: jinx
16:18:47	mriedem	wonder if anyone has hit the reshape for vgpu in stein - mnaser, did vexxhost have vgpu resources in rocky?
16:18:59	mnaser	no, we do not use vgpus, sorry
16:19:02	mriedem	or only physical gpu passthrough
16:19:03	mriedem	ok
16:19:07	mnaser	only physical passthrough
16:19:18	mriedem	have you ever heard of anyone providing vgpus?
16:19:29	mnaser	someone contributed a patch to OSA to enable vgpu support
16:19:36	mnaser	and it seemed like they knew what they were doing in it, maybe i can find them
16:19:43	mnaser	(osa does the whole mdev lookup and stuff)
16:19:50	mriedem	i think i remember hearing cern didn't use them b/c they didn't get the performance needed compared to physical passthorugh
16:20:23	mriedem	though people have been pushing the patches to hide the hypervisor in the guest to hack around nvidia licensing stuff
16:20:37	mnaser	https://review.opendev.org/#/c/597183/
16:20:56	mnaser	looks like that person was testing it with the i915 gvt stuff
16:20:59	mnaser	according to the review
16:20:59	mriedem	maybe that was OVH?
16:21:08	mnaser	Valentin Boucher <valentin.boucher@kontron.com>
16:21:22	mriedem	ok i'm thinking ovh was checking out vgpus
16:21:28	mriedem	but not sure how to ask, amorin ^?
16:21:32	mnaser	valentin lives in montreal
16:21:32	mnaser	oh look at that
16:21:34	mriedem	*who
16:21:51	mriedem	mnaser: i may be 'merican but i know montreal != france :)
16:21:56	melwitt	dansmith, mriedem: what do you think about moving onto the next cell if anything fails (down cells)? on the surface, it seemed like a good idea to me but now I'm wondering if that could possibly mislead anyone by making them think archive "completed" when it didn't?
16:22:02	mnaser	oh no i was just surprised he's a local :)
16:22:27	mriedem	melwitt: can we avoid handling down cells in that already too big patch?
16:22:43	melwitt	sure
16:22:52	mriedem	e.g. leave a todo in the code where a down cell thing could be handled, which is either log and continue or fail
16:22:58	dansmith	agree
16:23:07	dansmith	but also, yes I think skip/warn unreachable cells
16:24:05	melwitt	yeah, I was thinking just "except Exception" log continue
16:26:33	mriedem	stephenfin: i'm guessing i just ruined your day with the "what about pending resizes and migration allocation consumers" thing
16:26:35	mriedem	you're welcome
16:26:51	stephenfin	yeah, way to bum me out
16:34:51	mriedem	dansmith: before i address my comments in https://review.opendev.org/#/c/645611/14 do you want to make a pass?
16:35:01	mriedem	s/do you want to/will you please/
16:35:52	dansmith	mriedem: I read your comments before and commented on that physical thing, are there other questions?
16:36:12	mriedem	not questions no,
16:36:15	dansmith	because tbh, it's fine enough for me and I'd just merge it to claim the version and then address the nits and otherthings later
16:36:22	mriedem	but if you have comments on the diff itself, make them now before i make changes
16:36:35	dansmith	oh are you pushing the next verison?
16:36:35	mriedem	ok i'll start updating then
16:36:38	mriedem	yes
16:36:40	mriedem	surya is gone
16:36:58	dansmith	oh, sorry, she pushed again, my bad
16:37:02	dansmith	been distracted
16:39:15	mriedem	efried: do you want me to respin for that unrelated change in https://review.opendev.org/#/c/675218/4 ?
16:39:36	dansmith	mriedem: there was one legit test failure in the last run, IIRC, but I didn't look into it.. is that fixed?
16:39:46	dansmith	otherwise, yeah, I'm fine with current plus your planned changes
16:40:07	efried	mriedem: Might as well, it doesn't seem worth a whole fup. I'm here to re+2 it quick.
16:40:31	mriedem	dansmith: idk, but i can test locally https://logs.opendev.org/11/645611/13/check/openstack-tox-py27/7deb014/testr_results.html.gz
16:40:51	mriedem	efried: ack will do
16:40:55	efried	coo
16:41:00	dansmith	ookie
16:43:23	openstackgerrit	Matt Riedemann proposed openstack/nova stable/rocky: Restore soft-deleted compute node with same uuid https://review.opendev.org/676514
16:43:23	openstack	bug 1839560 in OpenStack Compute (nova) stein "ironic: moving node to maintenance makes it unusable afterwards" [High,In progress] https://launchpad.net/bugs/1839560 - Assigned to Matt Riedemann (mriedem)
16:43:23	openstackgerrit	Matt Riedemann proposed openstack/nova stable/rocky: Add functional regression recreate test for bug 1839560 https://review.opendev.org/676513
16:50:51	openstackgerrit	Matt Riedemann proposed openstack/nova master: Re-use DB MetaData during archive_deleted_rows https://review.opendev.org/675218
16:57:32	artom	dansmith, mriedem, hey, you guys were the main reviewers of NUMA LM in Stein, will have bandwidth to do the same in Train, or should I be sucking up to other cores? ;)
16:57:40	artom	*will you have
16:58:08	dansmith	I will try
16:58:26	artom	dansmith, ack, thanks :)
16:58:48	openstackgerrit	sean mooney proposed openstack/nova master: Libvirt: add support for vPMU configuration. https://review.opendev.org/671338
17:01:52	mriedem	artom: not today
17:02:05	mriedem	artom: you should also beat down the starlingx people's door,
17:02:12	artom	mriedem, I wasn't really expecting today :)
17:02:14	mriedem	because at the ptg and last summit they were saying this was the big ticket thing they needed
17:02:15	artom	I meant in general
17:02:28	mriedem	so if this is so critical for starlingx they should have people reviewing and testing it
17:02:30	artom	mriedem, yeah, I emailed the ML, and dtroyer and Gerry personally
17:02:40	artom	Radio silence :/
17:03:00	mriedem	cfriesen is probably the best starlingx person to review the series but he's been out of nova for awhile now
17:03:08	sean-k-mooney	well that and sriov numa policies was on the list too.
17:03:25	sean-k-mooney	i think we almost have everything this cycle?
17:03:35	artom	Gerry Kopec (not upstream as far as I can tell, though he did leave some reviews) tested it
17:03:41	artom	And found some problems
17:03:50	artom	Was hoping he'd step up again
17:04:03	artom	Radio silence so far. Which is weird, because Dean actually emailed me first
17:04:06	artom	Asking how it was going
17:05:12	sean-k-mooney	artom: i need to set up a second node but when im done testign a sriov thing i plan to test your numa live migration code with stephens cpu pinning stuff and my sriov migration code and report back

Earlier   Later