Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-11
13:58:00 jaypipes cdent: I had to rework it all last night.
13:58:06 jaypipes cdent: one sec, abandoning that.
13:58:13 jaypipes with a note pointing to the new stuff.
13:58:17 cdent cool, thanks
13:59:53 jaypipes cdent: bottom two patches starting here are ready for review: https://review.openstack.org/#/c/482381/
14:00:02 cdent ✔
14:00:09 bhagyashris cdent: yeah it's difficult to make coupling between docs and the tests, i mean using the same response.json file for both doc and tests purpose because doc json contains the static data.
14:00:11 jaypipes cdent: the top patch I'm still fixing up but you should be able to look at the ideas in it and verify.
14:00:14 jaypipes edleafe: ^^
14:01:30 bhagyashris cdent: what will be your opinion i mean we should maintain separate response json both for api-ref and tests
14:02:29 cdent bhagyashris: I think the way to start is to use different files, and then once we've had some experience with it, we should evaluate how things look and change if it seems like it would be a win
14:03:05 edleafe jaypipes: meeting hell this morning. Will look as soon as I can
14:05:35 jangutter jaypipes: would you have a sec to discuss os-traits newbie questions?
14:05:47 jaypipes jangutter: for you? any time :)
14:07:13 jangutter jaypipes: it boils down to the good-old-stupid "how does nova/network/neutronv2/api.py" pick the correct VF from a list question...
14:07:59 jangutter jaypipes: the way I looked at it, the "tag" mechanism in the pci whitelist doesn't seem to handle a list well...
14:08:16 bhagyashris cdent: ok. agree with your point but there will problem just as we are using getting the uuid as "$ENVIRON['RP_UUID']" so in that case the doc will print same like "$ENVIRON['RP_UUID']" instead of actual uuid thats one doubt in my mind.
14:08:48 jaypipes jangutter: do you mean "how does nova/network/neutronv2/api.py pick the correct *VIF plugin*"?
14:09:31 jangutter jaypipes: what I'd really like to do is add a {capabilities: ["NET_TYPE_OVS_VNIC_TYPE_DIRECT", "NET_TYPE_OVS_VNIC_TYPE_WHATEVER"]} to the PCI whitelist....
14:09:34 cdent bhagyashris: I think we should try to address those issues a bit later in the process. At this stage I think the right thing is to experiment, see what's possible, and work iteratively.
14:09:54 jaypipes jangutter: that's precisely what ralonsoh is working on right now :)
14:10:03 jaypipes ralonsoh: gotta link for jangutter?
14:10:31 jangutter jaypipes: and in the api generate the capability like so: "NET_TYPE_ (net_type) _VNIC_TYPE_ (vnic_type)".
14:10:33 jaypipes jangutter: though slightly different.
14:10:44 bhagyashris cdent: ok. Thanks for opinion and suggestion. :)
14:11:05 jaypipes jangutter: what do you mean by "the api generate the capability like so..."?
14:11:12 jaypipes jangutter: the Neutron API?
14:12:32 ralonsoh jaypipes, jangutter: https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/enable-sriov-nic-features
14:12:37 jaypipes jangutter: is there any way you can push the code that you've got so far so we can discuss the code?
14:12:38 jangutter jaypipes: Yeah, in nova/network/neutronv2/api.py, when create_pci_requests_for_sriov_ports runs, it currently tries finding the PCI devices by the physical_network tag.
14:12:45 jaypipes ralonsoh: ty sir :)
14:13:25 ralonsoh jaypipes, jangutter: but there is a possible problem with this feature. I need to talk to Matt first (https://review.openstack.org/#/c/449257/31/nova/network/neutronv2/api.py)
14:13:34 jangutter jaypipes: the stuff is in a very broken state now, and it _looks_ like I'll have to muck around with nova/objects/pci_device_pool.py as well.
14:13:55 jaypipes jangutter: don't do that (muck around with the device pool stuff)
14:14:07 jaypipes jangutter: I don't mind if your code is messy or broken :)
14:15:17 jangutter jaypipes: I should get the clearance to upload tomorrow. Yeah, when I hit the device pool stuff, I knew I was going down to R'lyeh.
14:15:40 jaypipes heh
14:16:02 jangutter jaypipes, ralonshoh: This sort-of overlaps.
14:16:08 jaypipes jangutter: how about you, me, mriedem and ralonsoh do a hangout either tomorrow or Thursday to discuss this?
14:16:27 ralonsoh jaypipes: perfect! any time
14:16:30 jangutter That would suit me 100%.
14:16:31 jaypipes possibly bring in sean-k-mooney too.
14:16:41 ralonsoh jaypipes: he will be there too
14:16:41 jaypipes ok, I'll send a hangout invite.
14:16:42 jangutter jaypipes: yeah, and maybe moshel
14:16:48 jaypipes jangutter: what's your email?
14:17:26 jangutter jaypipes: jan dot gutter at netronome dot short-for-commercial
14:18:15 jaypipes jangutter: cool, thanks.
14:18:54 jangutter jaypipes: thanks! I think this is basically the second-to-last piece of the puzzle to link up everything.
14:19:04 ralonsoh jaypipes: thanks!
14:20:52 jaypipes moshele: what's your email?
14:21:02 jangutter jaypipes: my completely odd idea was that, create_pci_requests_for_sriov_ports should take the network_info and assemble a "NET_XXX__YYY" capability for it.
14:22:03 jangutter jaypipes: And the pci_whitelist should have some form of "capability list" so you can add multiple capabilities to a PCI device.
14:24:16 jaypipes jangutter: well, technically, there should be discovery code that essentially runs ethtool -k <NIC> on a particular device to determine enabled features. The PCI whitelist is just the (hacky) way to limit devices that are assignable to a guest. The PCI whitelist is *not* for specifying PCI device inventory.
14:24:50 jaypipes jangutter, sean-k-mooney, ralonsoh: k, hangout invite sent for tomorrow 11am EDT
14:25:33 ralonsoh jaypipes: it's mriedem in the meeting?
14:25:48 jaypipes I've invited him, yes ralonsoh
14:26:31 moshele jaypipes: moshele@mellanox.com
14:26:44 jaypipes moshele: you want to be on above hangout?
14:27:03 moshele jaypipes: sure
14:27:09 jaypipes moshele: done :)
14:27:22 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Canary https://review.openstack.org/473565
14:28:17 jangutter jaypipes: I understand, _but_ for virtio-forwarder operation, the capability is not exposed by ethtool at all, but rather by the bridge....
14:28:39 jaypipes jangutter: how can you query for the capability? can you?
14:29:41 jangutter jaypipes: you could add it to ovsdb (and that's the way it looks to be heading), but currently we do it via the whitelist.
14:32:25 jangutter jaypipes: there's another reason I wanted to hack it into pci_whitelist. it means you can theoretically extend the sriov mechanism driver in order to do virtio-forwarder.
14:33:07 jaypipes jangutter: but like I said, the whitelist isn't for setting inventory :) it's for filtering for guest use only those PCI devices that *match* a particular capability or vendor/product ID.
14:33:33 jaypipes jangutter: it's the hypervisor driver that does the inventory setting for PCI devices.
14:34:46 jangutter jaypipes: yep... the hairy bit is that the hypervisor now needs to know more and more about the bridges.
14:36:08 jaypipes jangutter: for example, the libvirt driver calls listDevices("pci") to get PCI inventory: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L852
14:36:50 jaypipes jangutter: so the first thing you need to do is ensure that capability information can be returned from that call for the Netronome bridge adapters.
14:40:46 jangutter jaypipes: yeah, that we should be able to do for VF's. there's still a bit of an issue: currently create_pci_requests_for_sriov_ports uses the "physical_network" tag in the whitelist to select the VF's for the SR-IOV mechanism.
14:41:31 jangutter jaypipes: with OVS, the VM ports connect to br-int, not the physical network.
14:41:32 jaypipes jangutter: yeah, it was a hack :(
14:41:59 jaypipes this is the problem with using the pci_passthrough_whitelist CONF option as a way of setting inventory information on the host. :(
14:42:14 jaypipes in any case, jangutter, we'll discuss this tomorrow, ya?
14:42:22 jangutter jaypipes: aaah, and here I was assuming the hack was the normal way to operate.
14:42:37 jangutter jaypipes: thanks! I think you've given me enough to think.
14:42:51 jangutter jaypipes: bother you again tomorrow!
14:43:06 jaypipes jangutter: geen probleem :)
14:59:56 kashyap jaypipes: You're speaking Dutch?!
15:00:16 jaypipes kashyap: Afrikaans for our friend jangutter ;)
15:00:24 sean-k-mooney jaypipes: rodolfo and i may need to join from our personal account but we will be able to attend. intel changed its policy google account to be a luxuary and our team lost our access
15:00:38 kashyap jaypipes: Ah, yeah, they're similar. I can manage to speak enough Dutch to confuse coffee baristas that I'm a native speaker
15:00:41 kashyap :P
15:00:46 jaypipes sean-k-mooney: cool with me. send me your personal emails.
15:00:54 jaypipes kashyap: :)
15:06:09 jangutter kashyap: Afrikaans is Dutch where the guys decided to throw away most of the language rules and accent...
15:06:38 kashyap jangutter: Heh
15:06:59 jangutter kashyap: If you want to completely confuse an Afrikaans engineer, you should speak pure technical Afrikaans. Nobody will understand you.
15:07:16 jaypipes IIRC kashyap is an Indian speaking with a British accent living in Amsterdam. :)
15:07:29 kashyap jaypipes: Jeez, you got the Amsterdam part wrong
15:07:36 jaypipes oh shit.
15:07:37 kashyap jaypipes: I'm in Ghent.
15:07:39 kashyap :-)
15:07:42 jaypipes sorry, I meant oh sheet.
15:08:00 jaypipes or whatever is Dutch for shit.
15:08:02 jaypipes :P
15:08:22 kashyap :-)
16:04:50 openstackgerrit Jay Pipes proposed openstack/nova master: placement: add claim_resources() to report client https://review.openstack.org/482382

Earlier   Later