13:03:09 #startmeeting PCI Passthrough 13:03:10 Meeting started Tue Feb 4 13:03:09 2014 UTC and is due to finish in 60 minutes. The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:03:13 The meeting name has been set to 'pci_passthrough' 13:03:36 Hi 13:03:41 Hello 13:03:58 hi 13:04:23 rkukura said he maybe late ~10 mins 13:04:29 ok 13:04:59 baoli: can we discuss you wiki page https://wiki.openstack.org/wiki/Nova-neutron-sriov? 13:05:10 sure. 13:05:20 I just came in and didn't have time looking at your comments 13:05:31 I have entered comments with irenab 13:06:16 first for vif_type section 13:06:19 Ok I just saw that. I was about to send you an email asking your about the new vif type 13:07:13 Sounds like that you do need a new vif type like VIF_TYPE_HW_VEB 13:07:43 currently, we use VIF_HOSTDEV, it is defined on Plugin level 13:07:50 but sice need to add it to the common definitions anyway, maybe VIF_HW_VEB 13:08:08 I'll add that, and keep 802_1GBG as it is 13:08:09 ^since 13:09:02 yes, QBG is another case, but seems currently no one supports it with neutron 13:09:34 Is you bp approved? 13:10:04 my bp is blocked on discussion 13:10:31 I went through the email thread between Yunhong and you. Seems like no compromise can be easily reached even though we'd like to get something done in Icehouse 13:12:19 I thought that for short term it can be OK to go without PCI flavors 13:12:57 That's what I thought too, especially it's not approved yet and major design issues raised but not addressed 13:13:17 Not sure if my bp is going to be approved 13:14:16 what is required in order to approve it? 13:15:33 I am not exactly sure. definitely it needs a core to ok it. I had John Garbutt as approver of mine 13:16:48 I think that at least we can get something working, and change its implementation as the design gets mature with more input from people 13:16:55 if new bp that Yunhong registered is approved, we have all the pieces? 13:17:57 He said he was not optimistic (about the bp? or about the coding? I'm not exactly sure) in one of our exchanges. 13:18:00 baoli, irenab: what discussion between irenab and Yunhong are you talking about? 13:18:37 sadasu, there is an email thread in the openstack alias I started a while back 13:18:41 irenabb, Yonghong discussion/email thread I mean? 13:19:06 ok...I didn't see anything yesterday, so was wondering. 13:19:17 sorry, not on the alias. But you are one of the receipients 13:20:13 sadasu: he sent questions, I just went through baoli's wiki. I thought we have all pieces at place .... 13:20:46 baoli: ok...I saw those 13:21:07 I have also question regarding if normal user may set vnict_type via neutron port is use case you need or its OK that only admin user can do it? 13:21:21 ireanb: ok... 13:22:08 irenab: yes, I think that question still remains...I think it should have the same access as a nova boot command 13:22:38 and with that reasoning should be all allowed even for non-admin access 13:22:44 Irenab, how do we define a normal user? 13:23:40 I am not sure, the one that is not admin ... 13:24:53 Ok, then, the notion that a normal user has no notion of SRIOV ports seems to be in the way of allowing him/her to request one 13:25:43 Then a normal user would say I need a fast port? And what does a fast port mean? As a normal user of wirelese, do we know hat wifi means? 13:26:54 The question is what level of API abstraction is needed for a normal user to incorporate SRIOV 13:27:06 baoli: just to be sure, you say that normal user should understand "flavors", not specific vnic_types? 13:27:34 irenab, no. 13:28:03 from our earlier discussion with John Garbutt, it appears that if we let the user pick based on more friendlier terms, it can be a non-admin user input 13:28:03 My question is should a normal user has the notion of SRIOV ports 13:28:49 normal user is the one who asks for VM, right? 13:28:56 irenab: no flavors....just terms like "fast_no_migration", "fast_with_migration" for example 13:29:01 yes 13:29:46 sadasu: yes, but this will be via nova api, and nova will go to neutron and create port. nova is admin user 13:30:34 or the user can call create port first too 13:30:38 so the question is if normal user will create be allowed to create neutron port and ask for vnic_type 13:30:56 Help me understand this: a normal user can issue 'nova boot ..... --nic vnic-type=direct 13:31:27 but he can not: neutron port-create .... vnic-type=direct, and nova boot ... --nic port-id= 13:31:45 probably with some vnic-type=fast_with_migration 13:31:55 on nova 13:32:33 what is fast_with_migration 13:32:41 macvtap 13:33:02 is it simply the naming? 13:33:08 yes 13:33:08 'nova boot ..... --nic vnic-type=fast_with_migration' 13:33:11 yes 13:33:45 finally here - sorry I'm late 13:33:49 so it's not a issue of normal user using vnic-type, but the naming of the available vnic types? 13:33:52 hi 13:33:58 rkukura, hi 13:34:29 welcome rkukura. we are discussiong vnic_types here 13:34:34 rkukura: trying to close if vnic_type should be exposed to normal user 13:34:45 rkukura, how do you define a normal user? 13:35:16 A normal user is a tenant of the (private or public) cloud, as opposed to an administrator/provider of the cloud 13:36:01 does each tenant have an admin role? 13:36:56 No, tenants are usually not given any unnecessary privileges that would allow them to influence other tenants 13:37:50 a normal user can issue 'nova boot ..... --nic vnic-type=direct 13:37:50 but he can not: neutron port-create .... vnic-type=direct, and nova boot ... --nic port-id= 13:38:01 I was asking that question earlier 13:38:40 baoli: Why could the normal user not do the port-create in this case? 13:39:11 Is this with vnic-type requiring admin privileges? 13:39:21 rkukura, are we talking about that normal user is not allowed to use vnic-type in the port-create command? 13:39:24 baoli: I think John has strong objections to --nic vnic_type option 13:40:21 irenab, ok, then the question is does a normal have the notion of SRIOV ports, and there he/she can request them 13:40:45 ^normal user 13:40:56 based on earlier discussion with rkukura, we need to be quite confident what to expose with API, because it is not easiliy changed in the future 13:41:42 Seems to me a normal user should have visibility/control over what their VM sees, but not how that is accomplished internally to the cloud 13:42:48 rkukura: so you are in favor of axposing vnic_type to the user, right? 13:42:54 irenab: Who is it that objects to the --nic vnic_type nova option? 13:43:59 rkukura: requested network 13:45:01 irenab: Not to be intentionally indecisive on this, but I really don't have a strong opinion. I'd probably prefer to see nova handle the user's choice of how the interface looks to the VM, which would mean neutron could require nova to set this as admin. 13:45:24 rkukura: I think irenab was referring to an earlier comment from John Garbutt, a nova core 13:45:43 he was briefly involved in this effort 13:46:03 this was a few weeks ago 13:46:37 so is it ok for an admin to do port-create --vnic-type? 13:46:57 to summarize I think, it was ok to use --nic vnic_type as long as vnic_type did not have terms like macvtap, direct etc 13:47:04 till we will figure out how nova API should look like, we want to have oprtion to set vnic_type via neutron port 13:47:12 Then we can do --vnic-type on 'nova boot' with normal user, and admin on port-create --vnic-type 13:47:14 ^option 13:47:38 baoli: that would be inconsistent correct? 13:48:35 sadasu, to me it's inconsistent since the same APIs are exposed to all the users. it's just that some users don't see some of the options available to the APIs. 13:48:42 If macvtap, direct, etc. are internal details of the cloud deployment, then I think these should not be exposed directly to normal users. 13:48:44 I agree, that we should 1st only look at how we should pass it as a parameter to port-create and then worry about nova boot 13:49:58 baoli: yes. I am specifically talking about this -vnic_type option..I think we cannot call it admin in one command and user-level in another 13:50:00 We need to define the right abstraction for the normal user to specify what the NIC looks like to the VM and what QoS is provided, then decide whether that abstraction is provided in the nova API or in the neutron API. 13:50:11 Basically, are we saying a normal user has no notion of SRIOV Ports? Or as a normal user of cellphone, he should have no notion of 3G or 4G ? 13:51:22 rkukura: you suggested to take it to core discussion 13:52:14 keep in mind that SRIOV ports is a limited resources available in a cloud 13:52:48 baoli: correct and the user is paying a premium to get access to it 13:52:59 Can we separate the user-level abstraction from the admin-level detail of SR-IOV? 13:53:01 I think user should understand that he gets different types, and pays differently for them. 13:53:47 As long as a normal user can request a port either in the form of --nic or port-create, he should be aware what he is requesting for, one way or the other 13:53:54 yes. we only need to hide implementation specifics...we don't need to hide the service itself from the user, IMHO 13:54:41 we should be able to present the service in abstract terms (I am repeating myself here) 13:55:01 I agree with what sadasu just said. I'm not clear if the set of values for vnic_type are "implementation specifics" or "service itself". 13:55:11 like maybe "fast_with_migration" for macvtap and "fast_no_migration" for direct 13:55:54 that way the user knows understands that there is "fast" and vm migration is another knob 13:56:08 keep in mind that people are working to support live migration even with direct passthrough without macvtap. Technology advances 13:56:22 sadasu: so on neutron port, need to be user accessable with changed names? 13:57:11 baoli: exactly...our underlying implementation can change 13:57:26 I'm not sure its just the names. I think their is a question of whether its nova or neutron that controls the decision. 13:57:30 but the user facing service might not 13:57:59 rkukura, a normal user can use both 'nova boot' and 'neutron port-create", right? 13:58:08 baoli: yes 13:58:10 rkukura: for this question, I think the answer is, for icehouse, it will be all neutron 13:58:29 in juno, nova would expose it too via nova boot 13:58:42 rkukura, when you say it's nova that controls the decision, ultimately, isn't; the user who issued the command in control? 13:58:43 sadasu: Then that's what we need to make work. 13:58:57 this is based on baoli's wiki 13:59:02 rkukura: agreed 13:59:53 time is over, any conclusion how to proceed? 14:00:33 Thanks everyone 14:00:40 I'm OK with making vnic_type top-level and user-accessible if that's the only way we are going to get this into icehouse 14:00:42 continue tomorrow? 14:00:51 sure 14:00:54 I can be on time tomorrow 14:00:55 rkukura : +1 14:01:09 yes. will be there 14:01:10 rkukura: thank 14:01:14 thanks all. 14:01:21 see you tomorrow 14:01:28 cool. Let's go over the logs and think about it. Maybe we can find some lights in the tunnel tomorrow morning! 14:01:36 #endmeeting