13:03:09 <baoli> #startmeeting PCI Passthrough
13:03:10 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:13 <openstack> The meeting name has been set to 'pci_passthrough'
13:03:36 <baoli> Hi
13:03:41 <sadasu> Hello
13:03:58 <irenab> hi
13:04:23 <irenab> rkukura said he maybe late ~10 mins
13:04:29 <baoli> ok
13:04:59 <irenab> baoli: can we discuss you wiki page https://wiki.openstack.org/wiki/Nova-neutron-sriov?
13:05:10 <baoli> sure.
13:05:20 <baoli> I just came in and didn't have time looking at your comments
13:05:31 <irenab> I have entered comments with irenab
13:06:16 <irenab> first for vif_type section
13:06:19 <baoli> Ok I just saw that. I was about to send you an email asking your about the new vif type
13:07:13 <baoli> Sounds like that you do need a new vif type like VIF_TYPE_HW_VEB
13:07:43 <irenab> currently, we use VIF_HOSTDEV, it is defined on Plugin level
13:07:50 <irenab> but sice need to add it to the common definitions anyway, maybe VIF_HW_VEB
13:08:08 <baoli> I'll add that, and keep 802_1GBG as it is
13:08:09 <irenab> ^since
13:09:02 <irenab> yes, QBG is another case, but seems currently no one supports it with neutron
13:09:34 <irenab> Is you bp approved?
13:10:04 <irenab> my bp is blocked on discussion
13:10:31 <baoli> 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 <irenab> I thought that for short term it can be OK to go without PCI flavors
13:12:57 <baoli> That's what I thought too, especially it's not approved yet and major design issues raised but not addressed
13:13:17 <baoli> Not sure if my bp is going to be approved
13:14:16 <irenab> what is required in order to approve it?
13:15:33 <baoli> I am not exactly sure. definitely it needs a core to ok it. I had John Garbutt as approver of mine
13:16:48 <baoli> 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 <irenab> if new bp that Yunhong registered is approved, we have all the pieces?
13:17:57 <baoli> 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 <sadasu> baoli, irenab: what discussion between irenab and Yunhong are you talking about?
13:18:37 <baoli> sadasu, there is an email thread in the openstack alias I started a while back
13:18:41 <sadasu> irenabb, Yonghong discussion/email thread I mean?
13:19:06 <sadasu> ok...I didn't see anything yesterday, so was wondering.
13:19:17 <baoli> sorry, not on the alias. But you are one of the receipients
13:20:13 <irenab> sadasu: he sent questions, I just went through baoli's wiki. I thought we have all pieces at place ....
13:20:46 <sadasu> baoli: ok...I saw those
13:21:07 <irenab> 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 <sadasu> ireanb: ok...
13:22:08 <sadasu> irenab: yes, I think that question still remains...I think it should have the same access as a nova boot command
13:22:38 <sadasu> and with that reasoning should be all allowed even for non-admin access
13:22:44 <baoli> Irenab, how do we define a normal user?
13:23:40 <irenab> I am not sure, the one that is not admin ...
13:24:53 <baoli> 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 <baoli> 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 <baoli> The question is what level of API abstraction is needed for a normal user to incorporate SRIOV
13:27:06 <irenab> baoli: just to be sure, you say that normal user should understand "flavors", not specific vnic_types?
13:27:34 <baoli> irenab, no.
13:28:03 <sadasu> 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 <baoli> My question is should a normal user has the notion of SRIOV ports
13:28:49 <irenab> normal user is the one who asks for VM, right?
13:28:56 <sadasu> irenab: no flavors....just terms like "fast_no_migration", "fast_with_migration" for example
13:29:01 <baoli> yes
13:29:46 <irenab> 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 <sadasu> or the user can call create port first too
13:30:38 <irenab> so the question is if normal user will create be allowed to create neutron port and ask for vnic_type
13:30:56 <baoli> Help me understand this: a normal user can issue 'nova boot ..... --nic vnic-type=direct
13:31:27 <baoli> but he can not: neutron port-create .... vnic-type=direct, and nova boot ... --nic port-id=<port-uuid>
13:31:45 <irenab> probably with some vnic-type=fast_with_migration
13:31:55 <irenab> on nova
13:32:33 <baoli> what is fast_with_migration
13:32:41 <sadasu> macvtap
13:33:02 <baoli> is it simply the naming?
13:33:08 <sadasu> yes
13:33:08 <irenab> 'nova boot ..... --nic vnic-type=fast_with_migration'
13:33:11 <irenab> yes
13:33:45 <rkukura_> finally here - sorry I'm late
13:33:49 <baoli> so it's not a issue of normal user using vnic-type, but the naming of the available vnic types?
13:33:52 <irenab> hi
13:33:58 <baoli> rkukura, hi
13:34:29 <sadasu> welcome rkukura. we are discussiong vnic_types here
13:34:34 <irenab> rkukura: trying to close if vnic_type  should be exposed to normal user
13:34:45 <baoli> rkukura, how do you define a normal user?
13:35:16 <rkukura_> A normal user is a tenant of the (private or public) cloud, as opposed to an administrator/provider of the cloud
13:36:01 <baoli> does each tenant have an admin role?
13:36:56 <rkukura_> No, tenants are usually not given any unnecessary privileges that would allow them to influence other tenants
13:37:50 <baoli> a normal user can issue 'nova boot ..... --nic vnic-type=direct
13:37:50 <baoli> but he can not: neutron port-create .... vnic-type=direct, and nova boot ... --nic port-id=<port-uuid>
13:38:01 <baoli> I was asking that question earlier
13:38:40 <rkukura_> baoli: Why could the normal user not do the port-create in this case?
13:39:11 <rkukura_> Is this with vnic-type requiring admin privileges?
13:39:21 <baoli> rkukura, are we talking about that normal user is not allowed to use vnic-type in the port-create command?
13:39:24 <irenab> baoli: I think John has strong objections to --nic vnic_type option
13:40:21 <baoli> 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 <baoli> ^normal user
13:40:56 <irenab> 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 <rkukura_> 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 <irenab> rkukura: so you are in favor of axposing vnic_type to the user, right?
13:42:54 <rkukura_> irenab: Who is it that objects to the --nic vnic_type nova option?
13:43:59 <irenab> rkukura: requested network
13:45:01 <rkukura_> 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 <sadasu> rkukura: I think irenab was referring to an earlier comment from John Garbutt, a nova core
13:45:43 <sadasu> he was briefly involved in this effort
13:46:03 <sadasu> this was a few weeks ago
13:46:37 <baoli> so is it ok for an admin to do port-create --vnic-type?
13:46:57 <sadasu> 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 <irenab> 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 <baoli> Then we can do --vnic-type on 'nova boot' with normal user, and admin on port-create --vnic-type
13:47:14 <irenab> ^option
13:47:38 <sadasu> baoli: that would be inconsistent correct?
13:48:35 <baoli> 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 <rkukura_> 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 <sadasu> 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 <sadasu> 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 <rkukura_> 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 <baoli> 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 <irenab> rkukura: you suggested to take it to core discussion
13:52:14 <baoli> keep in mind that SRIOV ports is a limited resources available in a cloud
13:52:48 <sadasu> baoli: correct and the user is paying a premium to get access to it
13:52:59 <rkukura_> Can we separate the user-level abstraction from the admin-level detail of SR-IOV?
13:53:01 <irenab> I think user should understand that he gets different types, and pays differently for them.
13:53:47 <baoli> 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 <sadasu> yes. we only need to hide implementation specifics...we don't need to hide the service itself from the user, IMHO
13:54:41 <sadasu> we should be able to present the service in abstract terms  (I am repeating myself here)
13:55:01 <rkukura_> 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 <sadasu> like maybe "fast_with_migration" for macvtap and "fast_no_migration" for direct
13:55:54 <sadasu> that way the user knows understands that there is "fast" and vm migration is another knob
13:56:08 <baoli> keep in mind that people are working to support live migration even with direct passthrough without macvtap. Technology advances
13:56:22 <irenab> sadasu: so on neutron port, need to be user accessable with changed names?
13:57:11 <sadasu> baoli: exactly...our underlying implementation can change
13:57:26 <rkukura_> 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 <sadasu> but the user facing service might not
13:57:59 <baoli> rkukura, a normal user can use both 'nova boot' and 'neutron port-create", right?
13:58:08 <rkukura_> baoli: yes
13:58:10 <sadasu> rkukura: for this question, I think the answer is, for icehouse, it will be all neutron
13:58:29 <sadasu> in juno, nova would expose it too via nova boot
13:58:42 <baoli> 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 <rkukura_> sadasu: Then that's what we need to make work.
13:58:57 <sadasu> this is based on baoli's wiki
13:59:02 <sadasu> rkukura: agreed
13:59:53 <irenab> time is over, any conclusion how to proceed?
14:00:33 <baoli> Thanks everyone
14:00:40 <rkukura_> 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 <baoli> continue tomorrow?
14:00:51 <irenab> sure
14:00:54 <rkukura_> I can be on time tomorrow
14:00:55 <sadasu> rkukura : +1
14:01:09 <sadasu> yes. will be there
14:01:10 <irenab> rkukura: thank
14:01:14 <sadasu> thanks all.
14:01:21 <irenab> see you tomorrow
14:01:28 <baoli> 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 <baoli> #endmeeting