Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-03
14:26:40 luyao sean-k-mooney: you can use a normal file as a fake pmem
14:26:41 sean-k-mooney luyao: any progress on the intel ci for pmem
14:26:58 sean-k-mooney luyao: yes so if i spin up a vm with pme via the file backend
14:27:15 sean-k-mooney i could deploy devstask inside and test "hardware" pmem supprot
14:27:28 luyao sean-k-mooney: CI is in good process, they are testing the tempest plugin
14:27:36 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Make scheduler filters customizable https://review.opendev.org/679745
14:27:37 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671793
14:27:37 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693
14:27:38 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs https://review.opendev.org/671800
14:27:38 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait https://review.opendev.org/675571
14:27:39 openstackgerrit Stephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta https://review.opendev.org/671801
14:27:39 sean-k-mooney are we adding file backed pmem support this cycle to nova
14:27:39 openstackgerrit Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895
14:27:48 sean-k-mooney or jsut hardware pmem
14:28:34 efried luyao: I'm pretty sure there's no reasonable way to get an outsider access to the internal lab. At least not in a reasonable time frame to make it worthwhile.
14:28:40 efried stephenfin: those two reviews are done
14:29:01 stephenfin ta
14:29:29 efried stephenfin: unused model fields are okay as long as we've got the series baked enough to be pretty sure we're going to use them.
14:29:58 efried stephenfin: We had a bit of a miscue on vpmem and merged a field we ended up redesigning out, so had to do an ugly migration patch.
14:29:58 artom efried, FWIW, given the amount of (very justifiable, I should say) grief I got over NUMA LM CI, I'd feel betrayed if something else got merged without seeing it run in public CI somewhere
14:30:59 stephenfin bauzas: Have respun https://review.opendev.org/#/c/679745/
14:31:13 efried artom: heard and understood. Though arguably vpmem (niche specialized hardware) is different from NUMA+LM.
14:33:09 artom efried, that's also a good point - still, releasing "we support vpmem now!" only to find out it doesn't work because the dev testing it missed a thing (no shade on luyao or you) doesn't look good :)
14:33:31 artom Anyways, just I'm just grumpy. We all know there's a pressing lack of specialized hardware in CI
14:33:46 artom And with things going more telco (at least from an RH customers POV), that's only going to get worse
14:34:08 efried agreed on all counts.
14:34:21 luyao sean-k-mooney: We don't support normal file backend. So there will be so many details. You can use a part of memory to simulate a pmem device, and specific kernel , libvirt and qemu are needed, so it may take long time to setup.
14:34:40 sean-k-mooney artom: if we support file backed pmem in nova we can emulate the specialised hardware in ci using file backed pemem on the node pool vms
14:34:47 artom I was in an interesting convo with an RH consultant posted at Bell, our local massive telco
14:34:58 artom There was some interest on their part to become more than a pure consumer
14:35:22 sean-k-mooney luyao: ok
14:35:32 artom This is all very very preliminary, not even sure I should be talking about it, but I'd love it if that kinds of thing a. actually went somewhere and b. was more widespread in the telco world
14:36:00 donnyd sean-k-mooney: couldn't we attach like an ephemeral disk to the instance and use that as "fake pmem"
14:36:23 sean-k-mooney donnyd: no at least not the way you suggest
14:36:34 donnyd How about block storage?
14:36:45 sean-k-mooney donnyd: pmem device are exposed as dimms to the guest kernel
14:37:10 donnyd yea I know nothing about how it all works - /me goes to the corner to be quiet
14:37:16 sean-k-mooney so attaching block device ephemer or volumes wont present it to the guest correclty
14:37:17 aspiers kashyap: you around?
14:37:23 kashyap aspiers: Yep
14:37:36 aspiers kashyap: I've split out _guest_machine_type_for_sev(), but ...
14:37:36 sean-k-mooney donnyd: what we can do is have wemu use a file on the host disk to emulate pmem
14:37:43 kashyap (Although, I need to head out in an hour)
14:37:44 sean-k-mooney donnyd: libvirt/qemu support that
14:37:50 aspiers kashyap: now it occurs to me that this and the caller probably both belong in libvirt.utils
14:37:51 sean-k-mooney donnyd: nova does not currently
14:37:57 kashyap aspiers: :-)
14:38:05 aspiers does that make sense?
14:38:11 kashyap aspiers: I was also thinking something like that, sitting on _guest_machine_type_for_secure_boot() :D
14:38:12 aspiers all the rest of the machine type calculation is already in utils
14:38:15 sean-k-mooney donnyd: if we had that support we would jsut set some flave extra specls liek we did for numa sutff
14:38:37 aspiers kashyap: hell, we could even have machine_types.py
14:38:40 kashyap aspiers: Yeah, I think it does make sense -- keeps all the machine type-related context in the same place.
14:38:59 aspiers utils.py is a random mix of crap anyway
14:39:07 sean-k-mooney donnyd: pmem emultaion in qemu is really reall new however so even if openstack could do it most deploymes likely would not have a knew enough version
14:39:19 kashyap aspiers: Haha, "utils" is so generic, it's beyond description
14:40:24 kashyap aspiers: More seriously, bearing future work in mind, I _guess_ there will be more special-casing based on machine types. So a machine_types.py doesn't sound far-fetched to me
14:40:49 kashyap (Thoug, I _was_ serious on "utils" being generic :D)
14:40:50 aspiers kashyap: maybe I could do that after this SEV change
14:41:02 kashyap aspiers: Yeah, don't let that bog you down, though.
14:42:18 kashyap (It's a nice-to-have for now; and I'd rather let the "Apply SEV-specific guest config when SEV is required
14:42:24 kashyap " through the finish line.)
14:43:50 aspiers kashyap: yeah I'm working on that patch now
14:51:55 sean-k-mooney artom: http://paste.openstack.org/show/770137/
14:52:38 sean-k-mooney almost everything is working at this point
14:53:19 sean-k-mooney what does not work is the case where the source and dest nodes dont have the same numa nodes available
15:03:08 openstackgerrit Balazs Gibizer proposed openstack/nova master: unit test: do not fill rp mapping for failed re-schedule https://review.opendev.org/679653
15:05:39 sean-k-mooney artom: so ya if i use code with the same vcpu pin set on both host so both numa nodes are valid i can live migrate an instance with (pinning, hugepages, sriov, realtime, shared emulator threads) enable all at the same time
15:06:17 sean-k-mooney ill repoduce the failing case in the ci for you now
15:08:45 brtknr i need someone who uses fedora-coreos on openstack to tell me why the --keypair argument doesnt get respected
15:15:29 openstackgerrit sean mooney proposed openstack/nova master: [DNM] test non overlaping vcpu pin sets. https://review.opendev.org/679805
15:17:05 artom sean-k-mooney, are you using the code I pushed earlier this morning?
15:17:18 sean-k-mooney yes
15:17:28 sean-k-mooney that fix everything except this last edgecase
15:17:43 artom You mean "hugepages: node 1 not found" is till happening?
15:17:49 sean-k-mooney yes
15:19:18 openstackgerrit sean mooney proposed openstack/nova master: [DNM] test non overlaping vcpu pin sets. https://review.opendev.org/679805
15:19:29 sean-k-mooney i for got to disable the other jobs in ^ so now its fixed
15:21:05 openstackgerrit Merged openstack/nova master: Add and to config.py https://review.opendev.org/636318
15:21:58 artom I'm trying to understand what that error means
15:22:48 openstackgerrit sean mooney proposed openstack/nova master: [DNM] test migration with pinning https://review.opendev.org/679754
15:23:37 sean-k-mooney artom: by the way the non WIP/DNM patches have the job in the perodic and experimental pipline so you need to use check experimenttal or somthing like that not recheck
15:24:29 sean-k-mooney artom: ill repoduce it locally again and dump the migration xml
15:26:44 artom sean-k-mooney, I *think* I'm getting it
15:26:57 artom I'll poke danpb downstream to make sure
15:27:11 sean-k-mooney ok
15:46:24 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: Use Claims to update numa-related XML on the source https://review.opendev.org/635229
15:46:24 openstackgerrit Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606
15:46:25 openstackgerrit Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021
15:46:25 openstackgerrit Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595
15:49:34 efried dustinc: Three sdk patches merging; problems on 4 & 5.
16:01:51 openstackgerrit Merged openstack/nova master: libvirt: Simplify 'fakelibvirt.HostInfo' object https://review.opendev.org/678861
16:02:01 openstackgerrit Merged openstack/nova master: libvirt: Start checking compute usage in functional tests https://review.opendev.org/678902
16:24:03 donnyd sean-k-mooney: Ok FN should have the right stuff to run the NUMA jobs now
16:24:20 donnyd https://review.opendev.org/#/c/679789/
16:26:07 sean-k-mooney donnyd: cool
16:26:31 sean-k-mooney ill try and swap the jobs over to use those during the week
16:28:25 mriedem gibi: i left comments on https://review.opendev.org/#/c/655113/23 but will withold voting for now
16:28:37 mriedem *withhold
16:30:18 mriedem https://review.opendev.org/#/c/679651/ and https://review.opendev.org/#/c/679653/ are pretty simple if another core can hit those - i'm going to have to rebase the cross-cell-resize series and i'd like to wait until after those are merged since they are going to merge conflict me as well

Earlier   Later