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