| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-11 | |||
| 13:35:50 | stephenfin | I set an away message, but no one except me seems to be able to see it :/ | |
| 13:35:57 | jaypipes | lol | |
| 13:37:07 | cdent | ✔ | |
| 13:39:54 | bhagyashris | json file for both testing and api-ref doc? | |
| 13:39:54 | bhagyashris | cdent: Hi, I have just thought instaed of creating the new response.json file we will use the response json filr from placement-api-ref to test the response objcet with expected response json but there are two problems that are we can not access response json file outside nova/tests/functional/api/openstack/placement/gabbits folder and second one is "uuid" and "name" are newly generated every time. So is there any way we can use same response | |
| 13:48:40 | moshele | jaypipe, stephenfin: hi, I would appreciate if you can review the nova side of the ovs hw offload patches https://review.openstack.org/#/c/398265/ | |
| 13:48:50 | moshele | jaypipes, stephenfin: hi, I would appreciate if you can review the nova side of the ovs hw offload patches https://review.openstack.org/#/c/398265/ | |
| 13:49:02 | jaypipes | moshele: on my list for this morning sir :) | |
| 13:49:07 | stephenfin | moshele: Yup, on my backlog :) | |
| 13:49:25 | jaypipes | moshele: trying to get through avolkov`'s api-ref series and then will get to that one. | |
| 13:49:32 | cdent | bhagyashris: you could try symlinking the doc sample into the gabbits directory (or vice versa), but I'm not sure you want to create that kind of coupling the docs and the tests, especially since the tests allow for substitutions, but the docs do not (and I don't think should, we'd like to keep them a simple as possible) | |
| 13:56:34 | moshele | thanks :) | |
| 13:57:12 | cdent | jaypipes: is this the main next thing for claims: https://review.openstack.org/#/c/476632/ ? | |
| 13:57:50 | jaypipes | cdent: no. | |
| 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. | |