Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-15
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 mriedem maybe that was OVH?
16:20:59 mnaser according to the review
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 oh look at that
16:21:32 mnaser valentin lives in montreal
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 mriedem ok i'll start updating then
16:36:35 dansmith oh are you pushing the next verison?
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: Add functional regression recreate test for bug 1839560 https://review.opendev.org/676513
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: Restore soft-deleted compute node with same uuid https://review.opendev.org/676514
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
17:05:26 sean-k-mooney eta on that is sometime next week
17:06:06 artom sean-k-mooney, my series has conflicts with stephenfin's, so not sure how you'll test those together
17:06:12 artom Well, resolve manually, I suppose
17:06:33 mriedem cpu pinning stuff == PCPU?
17:06:33 sean-k-mooney ya i was thinking of doign that but if there are a lot ill test them seperatly
17:06:38 sean-k-mooney yes
17:06:57 sean-k-mooney i would also like to test gibis bandwith stuff
17:07:01 mriedem if it were me, i'd test artom's numa live migration stuff w/o trying to wrangle the PCPU stuff in

Earlier   Later