12:59:55 #startmeeting PCI Passthrough 12:59:56 Meeting started Mon Feb 10 12:59:55 2014 UTC and is due to finish in 60 minutes. The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:59:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:00 The meeting name has been set to 'pci_passthrough' 13:00:08 Hi 13:00:58 hi 13:01:01 Hello 13:02:30 hi 13:02:37 Hi Everyone 13:02:59 I can attend only 1/2 hour today 13:03:15 Saw messages from you guys. looks like that we are making a lot of progress 13:03:21 irenab, sure 13:03:27 just pushed the patch for vnic_type as WIP https://review.openstack.org/#/c/72334/ 13:03:50 Cool, I'll take a look at it. 13:04:32 Irenab, saw your eamil about the getting the physical network info on the nova side 13:04:32 irenab: thanks will take a look 13:04:34 ithe bp is still blocked, need rkukura to resolve it 13:04:51 baoli, sadasu: thanks 13:05:14 I've been trying to discuss this with markmclain. Should be able to today. 13:05:31 it is just the initial patch, so maybe reworked, but think we need some code to understand better what to do 13:05:39 rkukura: hi 13:05:48 I'll review it ASAP. 13:06:30 I am not sure it is the best way to add vnic_type in current implementation, had to do some stuff to pass unit tests... 13:06:38 Any comments are more than wellcome 13:06:50 and need to add more unit tests too 13:07:29 Ok, can we talk about nova getting the physical network information? 13:07:40 rkukura: any updates on your side? 13:08:31 The binding:vif_details patch is almost ready - definitely today. 13:09:03 rkukura: thanks! 13:09:07 I haven't started on binding:profile yet, but that is next. 13:09:43 rkukura: would it be possible to put physicla network in vif_details dict? 13:09:57 rkukura, cool, I think that we'd like to see the patches ASAP. 13:10:07 baoli: agreed 13:10:24 also, is there bp/bug in nova to make it available to VIFDriver? 13:10:40 #topic nova getting physical network information 13:10:41 irenab: I think that is needed - see the email with baoli 13:11:21 As I understand it, nova uses non-admin user priviledge to access the neutron network. 13:11:29 We want to make the entire binding:vif_details dict available to the VIF driver, right? 13:11:29 I think baoli needs it on port create, but not mandatorily to propagate to VIFDriver 13:11:44 baoli: exactly 13:11:48 https://review.openstack.org/#/c/59093/ 13:11:51 rkukura: yes 13:11:58 baoli: It does currently use admin to create/update port with binding:host_id 13:12:53 rkukura: its for port, not network 13:13:28 I think we can rework the bug https://review.openstack.org/#/c/59093/ to propogate vif_details 13:13:51 this but is driven by Itzik from my team to enable current Mellanox MD 13:14:04 ^bug 13:14:39 baoli: Right about needing admin for the providernet (or multiprovidernet) network attributes 13:15:30 after inspecting the neutronV2/api, for network it used caller context and for port it uses admin context 13:15:35 Is there any easy way to have nova only access the [multi]providernet details when SR-IOV has been requested? 13:16:08 rkukura, I think that the issue is: nova needs to enforce the rule that you can only create ports on the networks that the user owns. 13:17:01 baoli: Good point, but that really should be enforced by neutron, not nova, right? 13:17:02 baoli: still not sure that nova cannot get access to read attributes that should be seen by admin only... 13:17:27 but it seems quite a change to current implementation 13:18:01 Therefore, if nova needs to get the physcial net infor for a non-admin user, it may need to call neutron twice: once to make sure that the user owns the net, second to use admin context to retrieve the physical net infor 13:18:42 rkukura, neutron is enforceing it, but nova needs to choose the user context (admin or non-admin) when sending requests to neutron, right? 13:18:43 baoli: possible, just adding another call to neutron 13:19:25 baoli: It seems to me that nova should do the port-create with user context, then set binding:host_id (and binding:profile) separately as admin 13:20:04 and also get vif_details as admin 13:20:09 I'd think the enforcement would be inside port_create 13:20:09 guys, we assume that port-create is done by neutron at this point, right? we plan to do "neutron port-create" for SRIOV in the initial release 13:20:28 baoli: yes 13:20:43 Right, admin is needed to get vif_details from the port and to get physical_network(s) from the port's network 13:20:56 still for virtio port, it is possible to create usually 13:21:05 irenab, that's right 13:24:05 I need to get more familiar with the current nova code to be of much help here. I'll try to do that today. 13:24:18 During port create, is it possible for neutron to set the physical net name(s) in the port object? 13:24:54 coming to back to the https://review.openstack.org/#/c/59093/, we can either add there another call to neutron with admin or get vif_details and propagate to VIF Driver 13:25:22 baoli: for Mellanox plugin we added it in binding:profile 13:25:22 baoli: Are you asking about setting a physical network name in binding:profile on the port? 13:25:41 irenab, vif_details is not available when binding hasn't occured as rkukura has pointed out. 13:26:23 baoli:I think its fine, since if binding hasn't occur, there is no need for VIFDriver part 13:26:24 rkurura, I actually don't mind where it stores, I simply ask if it makes sense to do that. 13:26:54 Nova will need to get binding:vif_details from the port at the same time it currently gets binding:vif_type. Both require it to be bound, and need admin. 13:26:55 irenab, nova need that info for scheduling if we are all on the same page 13:27:09 rkukura: do you think binding:profile will be available if port is not bound? I do not think so 13:27:53 baoli: I think we need nova to tell neutron which (of possibly several) physical networks it has allocated a SR-IOV VF for, right? 13:28:03 baoli: seems the best is to get it from network... 13:28:24 irenab: Yes, binding:profile is input to the plugin, so whatever is set by a client is readable (by admin) 13:28:43 rkukura, yes. But that's after the scheduing has occured, And scheduling needs the physical net infor. 13:29:30 so binding:profile is not a candidate to contain the physical network info 13:29:37 baoli: Right. Weren't we agreeing nova would need to use the [multi]providernet attributes on the network as admin to get the possible physical networks for the port? 13:29:38 rkukura, so scheduling needs to know all the physical nets before scheduling, and then tell neutron which physical net is chosen 13:30:02 baoli: That was my interpretation based on the IRC chat and email thread 13:30:29 rkukura, if it's ok for everyone to make the two calls in order to retrieve the physcial net(s), it is still the plan. 13:30:56 so are we agree the nova will need to call neutron with admin context to get network [provider:physical_netowrk]? 13:31:17 baoli: So either nova will make one get-network call as admin, or two, first as user, second as admin, right? 13:31:40 sorry, need to swtich to another meeting, will follow up 13:31:49 rkukura, that's what I thought 13:32:18 because nova really need to make sure that the user owns the net(s) 13:33:20 baoli: I'm not sure why get-network has to be called as the user. Isn't tenant_id returned either way? 13:36:47 baoli: I need to [re-]read the nova code to see how it currently works, including how the owenership is enforced. 13:39:08 baoli_: I see you just rejoined 13:39:16 I got disconnected. Not sure if I missed anything 13:39:24 Not much... 13:39:30 ok 13:39:40 rkukura: baoli: I'm not sure why get-network has to be called as the user. Isn't tenant_id returned either way? 13:39:43 rkukura: baoli: I need to [re-]read the nova code to see how it currently works, including how the owenership is enforced. 13:40:08 ok 13:40:52 Anything else critical to cover here, or should we get back to coding up patches, etc.? 13:41:36 rkukura, the other issue is what fields should be there in binding:profile for SRIOV. We need to nail that down. 13:43:32 baoli_: Agreed. Is this covered in the wikis? 13:43:34 since irenab is not here, I think that we can resume tomorrow. We should resolve two things: 1) nova gets physical net infor 2) what fields are there in binding:profile and binding:vif_details for SRIOV 13:43:53 baoli_: Makes sense to me. 13:44:18 rkukura, our original doc and irenab's wiki touched upon this, and I think Irenab's wiki should be considered lastest. 13:44:37 ok 13:44:59 https://docs.google.com/document/d/1RfxfXBNB0mD_kH9SamwqPI8ZM-jg797ky_Fze7SakRc/edit 13:45:19 So, we'll resume tomorrow? 13:46:22 OK. Its possible I'll be a few minutes late, assuming I head to the office after dropping kids off at school, depending on traffic. 13:48:24 ok, that should be fine. We'll exchange emails as well. 13:48:52 #endmeeting 13:49:49 baoli_: Thanks. Not sure if the MeetBot will recognize you as baoli_. 13:50:14 right, can you do #endmeeting to collect logs? 13:50:23 #endmeeting 13:50:49 #endmeeting