| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-07 | |||
| 20:20:40 | bauzas | is efried still on PTO ? | |
| 20:21:10 | bauzas | I was considering to work on a spec for providing NUMA affinity using nested RPs, and AFAIR he told me there was already a spec | |
| 20:21:21 | bauzas | am I wrong? | |
| 20:21:40 | mriedem | he is | |
| 20:21:49 | artom | So this might be a question for neutron, but... In the case of trusted VFs (and passthrough of whole PFs), what the actual cable going from the card is connected to at the other end is kinda important | |
| 20:22:01 | artom | How is that expressed when creating the neutron port? | |
| 20:22:22 | dansmith | mriedem: as bauzas would say... "le woot": http://logs.openstack.org/94/550194/6/check/nova-next/0842c76/job-output.txt.gz#_2018-03-07_20_06_24_926495 | |
| 20:22:38 | artom | Or put differently, how does the port become associated with the right hardware? | |
| 20:23:08 | artom | Maybe a question for sean tomorrow morning | |
| 20:23:36 | bauzas | dansmith: \o/ | |
| 20:25:53 | mriedem | le woff | |
| 20:25:55 | mriedem | *woof | |
| 20:26:08 | mriedem | bauzas: artom: ok i dumped some placement thoughts in https://review.openstack.org/#/c/485522/ | |
| 20:26:28 | mriedem | i'm sure the response will be, "well this 'works' with code we have up for review today and placement isn't done yet" | |
| 20:26:49 | mriedem | it doesn't, at all, address the scheduling issue of finding a host that allows nova to configure VFs as trusted | |
| 20:26:55 | artom | Which is *technically* true :/ | |
| 20:27:02 | dansmith | I assume the pci filter can do that kind of thing, | |
| 20:27:10 | dansmith | if we extend the data structure to have a trusted flag or something | |
| 20:27:14 | dansmith | but that's the thing I think we should avoid | |
| 20:27:22 | artom | I thought that's what he did? | |
| 20:27:27 | dansmith | building more cruft on that crap is not the way we should go, IMHO | |
| 20:27:28 | mriedem | i don't really know anything about the pci filter | |
| 20:27:40 | artom | dansmith, https://review.openstack.org/#/c/458820/ ? | |
| 20:27:41 | mriedem | does the pci filter get information off the pci request spec? | |
| 20:27:56 | dansmith | artom: right, but that's not merged | |
| 20:27:58 | bauzas | dansmith: le woof is victory https://scontent-cdg2-1.xx.fbcdn.net/v/t1.0-9/28577622_10213176224494032_6122884744312777644_n.jpg?oh=e91e488a77ace375c978611b0964e159&oe=5B39D007 | |
| 20:28:07 | artom | dansmith, right, but it's what's being proposed | |
| 20:28:12 | dansmith | bauzas: I said "le woot" not "le woof" | |
| 20:28:18 | dansmith | artom: right, that's what I was saying | |
| 20:28:26 | artom | dansmith, oh you were saying that? right | |
| 20:28:29 | dansmith | artom: mriedem sounded like he didn't see the connection for the scheduler | |
| 20:28:35 | cdent | that's an awesome dog | |
| 20:28:58 | dansmith | bauzas: my understanding is I can make any word french by putting "le" in front... | |
| 20:29:12 | mriedem | dansmith: artom: ok i didn't realize the connection with the pci filter | |
| 20:29:16 | bauzas | it can work with "le café" | |
| 20:29:22 | bauzas | "le budget" | |
| 20:29:25 | artom | dansmith, ah, and your response was "there's the connection, by having the PCI filter work with this new trusted thing in pci requests" | |
| 20:29:30 | dansmith | yes | |
| 20:29:58 | bauzas | yeah the spec was unclear, I asked for details | |
| 20:30:02 | mriedem | so the api calls create_pci_requests_for_sriov_ports which gets the binding profile off the port and gets the pci request spec with the new trusted attribute | |
| 20:31:15 | mriedem | ok and then the pci filter magically picks a host based on the pci request spec for a trusted vf, tied via flavor extra spec? | |
| 20:31:33 | dansmith | not just that, it picks an _actual_ pci device I think | |
| 20:31:35 | dansmith | it's AWESOME | |
| 20:33:34 | mriedem | PciPassthroughFilter right? | |
| 20:34:04 | mriedem | man i'm confused | |
| 20:34:20 | mriedem | good thing the release note would have documented how all of this works for a deployer that wants to use it | |
| 20:34:30 | mriedem | artom: i guess? | |
| 20:34:48 | mriedem | the spec just says, "operators will have to use host aggregates" | |
| 20:35:19 | artom | I sort of assumed it would be in the same way that we have pinned CPUs now | |
| 20:35:31 | artom | Aggregates for trusted VFs and aggregated for normal VFs | |
| 20:35:46 | artom | So that any VF in a 'trusted' aggregate is, err, trusted | |
| 20:38:27 | dansmith | that would kindof suck | |
| 20:39:40 | mriedem | the PciPassthroughFilter is looking at HostState.pci_stats, but i don't know what goes into that thing saying "this host reported it supports trusted VFs" | |
| 20:40:09 | openstackgerrit | Merged openstack/nova master: Only attempt a rebuild claim for an evacuation to a new host https://review.openstack.org/546268 | |
| 20:42:13 | mriedem | i guess https://review.openstack.org/#/c/458514/13/releasenotes/notes/trusted-vfs-abee6dff7c9b6940.yaml ? | |
| 20:42:27 | mriedem | so the pci passthrough_whitelist has to report the devices that are trusted, | |
| 20:42:37 | mriedem | and the PciPassthroughFilter links those to the ports in the pci request spec? | |
| 20:43:25 | mriedem | and pci passthrough_whitelist is our poor man's placement inventory system yes? | |
| 20:43:26 | mriedem | jaypipes: ^? | |
| 20:43:47 | openstackgerrit | Dan Smith proposed openstack/nova master: Make nova-manage db purge take --all-cells https://review.openstack.org/550502 | |
| 20:44:52 | dansmith | mriedem: this ^ passed, so I converted the hook to run --all-cells on the purge | |
| 20:45:20 | dansmith | all the other patches have a clean swath of green from zuul too | |
| 20:45:22 | mriedem | +2 on the bottom change in the series | |
| 20:46:06 | dansmith | the other guy hasn't updated the archive patch yet, but if he has tomorrow I'll rebase on this and convert that part of the hook too | |
| 20:46:26 | mriedem | Kevin_Zheng ? | |
| 20:46:34 | dansmith | someone else was responding right? | |
| 20:46:39 | mriedem | oh idk | |
| 20:47:06 | dansmith | also downstream QE here is going to try to get some real world database snapshots and run archive/purge against them | |
| 20:48:51 | bauzas | jaypipes: mriedem: dansmith: as we discussed at the PTG, I'm about to provide a new spec for NUMA topology, should I use that one https://review.openstack.org/#/c/543062/1 or just a new one given we agreed on a different way | |
| 20:49:00 | tssurya | dansmith : Zhenyu Zheng is Kevin_Zheng :) | |
| 20:49:14 | dansmith | tssurya: oh, hah | |
| 20:49:57 | dansmith | I stopped pattern matching at "Z != K; break" | |
| 20:50:25 | tssurya | dansmith: :D | |
| 20:54:34 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Update the nova-manage db archive_deleted_rows description https://review.openstack.org/550600 | |
| 20:54:48 | artom | dansmith, actually, about that, if we grab that mitaka dump from the "original" bug a long time ago, and just run it through nova-manage db-sync...? | |
| 20:55:06 | dansmith | artom: it was newton I think | |
| 20:55:13 | dansmith | artom: we could, but it'd be nicer to have something a little fresher | |
| 20:55:17 | jaypipes | mriedem: yes, you are correct. (about the pci_passthrough_whitelist and PciPassthroughFilter cruft. | |
| 20:55:19 | dansmith | but if nothing else, that will work | |
| 20:55:40 | jaypipes | bauzas: definitely a new one. | |
| 20:55:56 | bauzas | jaypipes: roger. | |
| 20:58:18 | mriedem | jaypipes: ok cool, | |
| 20:58:28 | mriedem | it's about time, since juno, that i start to try to understand how that stuff works | |
| 20:58:39 | mriedem | i would really rather not have to though | |
| 20:59:06 | openstackgerrit | Merged openstack/nova stable/queens: Check for multiattach before removing connections https://review.openstack.org/550221 | |
| 21:03:27 | bauzas | just to make it clear : "le"/"la" | |
| 21:03:36 | bauzas | le woof, la bye | |
| 21:03:50 | bauzas | :p | |
| 21:09:39 | mriedem | maybe in le france | |
| 21:09:42 | mriedem | i'm in 'merica | |
| 21:18:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Rename the 'recreate' param in rebuild_instance to 'evacuate' https://review.openstack.org/508190 | |
| 21:22:45 | bauzas | oh man, getting mad with the imagebackend | |
| 21:30:28 | mriedem | dansmith: not sure if you want to clean up the nits in https://review.openstack.org/#/c/550182/ before i +W? | |
| 21:31:16 | mriedem | bauzas: https://i.chzbgr.com/full/6425329152/hA7A48AD5/ | |
| 21:32:03 | bauzas | meh | |
| 21:32:14 | bauzas | trying to understand spaghetti code | |
| 21:32:36 | mriedem | i think mdbooth said the libvirt imagebackend code was done | |
| 21:36:12 | bauzas | mriedem: man, it's your fault | |
| 21:36:39 | bauzas | mriedem: I need to understand why we preallocate LVM volumes | |
| 21:36:41 | bauzas | :p | |