| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-11 | |||
| 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 | |
| 16:04:51 | openstackgerrit | Jay Pipes proposed openstack/nova master: scheduler: alternates for filter scheduler https://review.openstack.org/482381 | |
| 16:04:51 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: claim resources in filter scheduler https://review.openstack.org/482383 | |
| 16:10:59 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for allocations https://review.openstack.org/470933 | |
| 16:10:59 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for allocation_candidates https://review.openstack.org/481112 | |
| 16:11:00 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Make placement_api_docs.py failing https://review.openstack.org/480924 | |
| 16:11:00 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for usages https://review.openstack.org/480563 | |
| 16:11:01 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for RP allocations https://review.openstack.org/450550 | |
| 16:11:01 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for RP usages https://review.openstack.org/450105 | |
| 16:11:30 | openstackgerrit | Matt Rabe proposed openstack/nova master: Query deleted instance records during _destroy_evacuated_instances https://review.openstack.org/467774 | |
| 16:13:06 | dansmith | mdrabe: gonna backport that? | |
| 16:13:37 | mdrabe | dansmith: I can, to ocata? | |
| 16:14:03 | dansmith | at least yeah.. I guess newton is in security-only mode probably | |
| 16:17:28 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.49 - Virt device tagged attach https://review.openstack.org/480392 | |
| 16:20:10 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.50 - List/Show all server migration types https://review.openstack.org/430839 | |
| 16:20:19 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.50 - Enable cold migration with target host https://review.openstack.org/406707 | |
| 16:21:51 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Stop using mox stubs in cast_as_call.py https://review.openstack.org/477730 | |
| 16:25:34 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add abstract OVSDB API https://review.openstack.org/476612 | |
| 16:25:35 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 16:26:54 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform HostAPI-set_enabled notifications https://review.openstack.org/482622 | |
| 16:38:34 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform compute_task notifications https://review.openstack.org/482629 | |
| 16:46:05 | ildikov | mriedem: I guess it does not make too much difference by now, but I updated the priorities etherpad with the current state of reviews | |
| 16:46:19 | ildikov | mriedem: let me know if there's anything I else I could/should do | |
| 16:56:06 | mriedem | dansmith: mdrabe: the deleted instances on evacuate thing? | |
| 16:56:16 | dansmith | mriedem: yeah | |
| 16:56:17 | mdrabe | ya | |
| 16:56:21 | mriedem | ildikov: honestly i'm not looking at the review priorities etherpad, but ok | |
| 16:56:35 | mriedem | ildikov: with <3 weeks i've got my list of priority changes to review starred already | |
| 16:57:19 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform compute_task notifications https://review.openstack.org/482629 | |
| 16:57:25 | ildikov | mriedem: just like how others do I guess... | |
| 16:57:31 | mriedem | ildikov: that does remind me though that i/we need to reach out to claudiub on hyperv and the xenapi team about checking out stvnoyes' change for live migration | |
| 16:57:43 | mriedem | since that also has to be done in those other drivers that support live migration | |
| 16:58:16 | claudiub | o/ | |
| 16:58:41 | ildikov | mriedem: Steve has changes in those parts too, but definitely needs a double check | |
| 16:58:46 | ildikov | claudiub: hi :) | |
| 16:58:52 | claudiub | hello. :) | |
| 16:59:05 | mriedem | ildikov: there are no hyperv/xenapi changes in https://review.openstack.org/#/c/463987/ | |
| 16:59:09 | mriedem | claudiub: see ^ | |
| 16:59:21 | mriedem | that's the change to use the new cinder volume attach flow for live migration | |
| 16:59:46 | mriedem | the hyperv and xenapi drivers would need to do something for that too, building on that patch, as that's only the libvirt driver and the framework code in the compute manager | |