| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-07 | |||
| 19:59:26 | mnaser | it's a thing in glance v2 i'm pretty sure | |
| 20:00:21 | mriedem | whatever this is https://github.com/openstack/devstack-plugin-ceph/blob/master/devstack/lib/ceph#L683 | |
| 20:00:34 | mnaser | https://developer.openstack.org/api-ref/image/v2/index.html#show-image-details | |
| 20:00:42 | mnaser | yeah that is the direct_url and locations[] in the api there | |
| 20:01:17 | mriedem | ok i thought they weren't going to carry that forward to v2 | |
| 20:01:36 | mriedem | but if they did, then i don't have to worry about us breaking the direct snapshot rbd stuff that a lot of people wanted and are using | |
| 20:03:02 | mnaser | mriedem: afaik we're using v2 with nova and direct snapshot is working here .. under pike at least | |
| 20:03:19 | mriedem | ok i'll not worry about this then | |
| 20:03:41 | cfriesen | mnaser: mriedem: if you enable "show_multiple_locations" then the direct snapshot stuff will work. it's just that glance tells you that turning that option on is a security risk | |
| 20:04:20 | mriedem | cfriesen: i know, i just thought it was a v1 only thing | |
| 20:04:24 | hrw | stephenfin: sorry but r14 got wrong in one place during merge and I did not noticed | |
| 20:04:32 | mriedem | nova dropped support for glance v1 in ocata, so it's further back than i thought | |
| 20:04:58 | mnaser | oh yeah, nope, its fine, glance says its a security risk but i'd argue with that in ceph's case .. but i don't have the time to discuss that :D | |
| 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 | |