| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-11 | |||
| 11:22:34 | openstackgerrit | Andrey Volkov proposed openstack/nova master: Update pci device fields from deleted object https://review.openstack.org/426243 | |
| 11:27:57 | masber | mkucia, thank you and sorry for using this channel inappropriately | |
| 11:55:58 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/477091 | |
| 12:22:59 | kaisers | sfinucan: Hi! Would you mind revisiting https://review.openstack.org/#/c/428646/ ? There were some additions (relnote) and a rebase in the last weeks. | |
| 12:32:46 | stephenfin | kaisers: Sure, I'll take a look now | |
| 12:33:38 | kaisers | stephenfin: great, thanks | |
| 12:53:54 | mdbooth | I've just been testing my auto-revert on failure patch: https://review.openstack.org/#/c/462521/ | |
| 12:54:40 | mdbooth | Although I was careful in the patch to ensure instance faults are added, after the auto-revert completes successfully I can't seem to find it using either nova client or openstack client | |
| 12:54:45 | mdbooth | Am I missing a trick? | |
| 12:54:48 | mdbooth | dansmith: ^^^ ? | |
| 13:00:16 | openstackgerrit | Moshe Levi proposed openstack/nova master: hardware offload support for openvswitch https://review.openstack.org/398265 | |
| 13:03:07 | openstackgerrit | Andrey Volkov proposed openstack/nova master: PoC: Select PCI devices with distinct tag values https://review.openstack.org/448008 | |
| 13:10:19 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Transform instance.resize_confirm notification https://review.openstack.org/482557 | |
| 13:16:02 | openstackgerrit | sahid proposed openstack/nova master: libvirt: fix memory locking limit https://review.openstack.org/472633 | |
| 13:26:39 | ftersin | mdbooth: hi. could you say whether you'll have time to work with ScaleIO review? | |
| 13:27:48 | mdbooth | ftersin: Yes, sorry. It seems I've been very downstream focussed for a long time. | |
| 13:28:34 | mdbooth | ftersin: I'll look this afternoon (after a coffee). | |
| 13:28:47 | ftersin | good, thx | |
| 13:29:19 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Support tag instances when boot(4/4) https://review.openstack.org/469800 | |
| 13:33:44 | openstackgerrit | Anthony PERARD proposed openstack/nova master: Skip boot from encrypted volume on Xen+libvirt https://review.openstack.org/481627 | |
| 13:35:18 | jaypipes | sfinucan: are you stephenfin? | |
| 13:35:27 | jaypipes | seeing double today... | |
| 13:35:38 | stephenfin | jaypipes: Yup | |
| 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 | 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:39:54 | bhagyashris | json file for both testing and api-ref doc? | |
| 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 | jaypipes | ok, I'll send a hangout invite. | |
| 14:16:41 | ralonsoh | jaypipes: he will be there too | |
| 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.... | |