| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-07 | |||
| 20:08:38 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034 | |
| 20:08:50 | hrw | stephenfin, mriedem: fixed rev | |
| 20:11:19 | bauzas | mriedem: dansmith: I'll be on PTO tomorrow afternoon UTC | |
| 20:11:23 | mriedem | artom: so -1 on https://review.openstack.org/#/c/485522/ since the spec doesn't say anything | |
| 20:11:35 | bauzas | in case you need me | |
| 20:11:45 | mriedem | bauzas: i need you right now | |
| 20:11:47 | mriedem | to remove your -W on https://review.openstack.org/#/c/550259/ | |
| 20:12:03 | artom | And to stop forest fires? | |
| 20:12:10 | artom | Am I mixing up my references? | |
| 20:12:17 | artom | mriedem, fair, I expected nothing less | |
| 20:12:31 | bauzas | mriedem: just did | |
| 20:12:54 | bauzas | mriedem: I was looking at today's discussions | |
| 20:13:56 | mriedem | dansmith: can you +W https://review.openstack.org/#/c/550259/ | |
| 20:14:00 | mriedem | that backport | |
| 20:14:01 | artom | mriedem, to be fair, maybe there just isn't that much to do in Nova for trusted VFs (if doing it without placement), in which case maybe it would have needed to be a Neutron spec? | |
| 20:14:15 | mriedem | artom: well, look at 'work items' | |
| 20:14:22 | artom | In any case, I still agree that we're better off tracking them in placement | |
| 20:14:23 | mriedem | "something something pci request spec, and libvirt driver, done!" | |
| 20:14:30 | openstackgerrit | Surya Seetharaman proposed openstack/nova-specs master: Support disabling a cell https://review.openstack.org/546684 | |
| 20:14:41 | mriedem | don't look behind the curtain | |
| 20:14:54 | artom | But it's cloud! | |
| 20:15:07 | artom | You're not *supposed* to look behind the curtain | |
| 20:15:15 | mriedem | ew https://review.openstack.org/#/c/458513/11/nova/network/linux_net.py | |
| 20:15:36 | mriedem | ^ should happen in os-vif i'm pretty sure | |
| 20:15:39 | artom | The hell, we did that in nova-network?! | |
| 20:15:40 | dansmith | mriedem: yes | |
| 20:15:50 | mriedem | artom: that's common 'networking' code | |
| 20:15:57 | artom | Ah, sorry | |
| 20:16:31 | mikal | So are we deleting nova-network this release? Can I ignore that stuff for the purposes of privsep? | |
| 20:16:50 | artom | I think we said we're getting rid of cellsv1 first? | |
| 20:17:01 | mriedem | mikal: yes | |
| 20:17:07 | mriedem | artom: other way around | |
| 20:17:09 | dansmith | artom: other way around | |
| 20:17:10 | dansmith | heh | |
| 20:17:13 | mriedem | artom: you were there, in the room! | |
| 20:17:28 | artom | Oh so other way round? | |
| 20:17:31 | mriedem | so i think i get what the trusted VFs thing is now | |
| 20:17:31 | mikal | I'd like to be core for just the one review to +2 the removal of nova-net please. For old times sake. | |
| 20:17:43 | mriedem | 1. create port in neutron with a trusted attribute | |
| 20:17:56 | mriedem | 2. nova takes that off the port binding profile and shoves into the pci request spec, | |
| 20:18:19 | artom | (Oh right, your action item was to make cellsv1 work with Neutron) | |
| 20:18:26 | mriedem | 3. libvirt driver reads that off the pci request spec and shells out to set the vf to trusted on the host | |
| 20:18:42 | mriedem | why do we need the virt driver doing this? | |
| 20:18:49 | dansmith | mriedem: but in reality, it should be "2. nova takes that and shoves it into traits" | |
| 20:19:01 | dansmith | mriedem: then placement weeds everything we can't land on for us | |
| 20:19:18 | mriedem | dansmith: yeah that's what i was thinking the spec (and asked) - how to get go through scheduling to find a host that handles this type of port | |
| 20:19:23 | mriedem | since we don't have network-aware scheduling | |
| 20:19:33 | mriedem | jesus words | |
| 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 | |