13:00:13 <baoli> #startmeeting PCI Passthrough
13:00:14 <openstack> Meeting started Tue Apr  1 13:00:13 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:18 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:32 <baoli> Hi there
13:00:37 <irenab> hi
13:01:02 <BrianB_> Hello
13:01:36 <sadasu> Hello
13:01:43 <heyongli> hello,
13:02:05 <baoli> irenab, thanks for trying the patch. I will work on updating the patch to the latest branch, and also include the migration script, and some  other fixes.
13:02:30 <baoli> I just heard that Juno is open
13:02:46 <rkukura> hi
13:02:52 <baoli> Hi rkukura
13:02:56 <beagles> o/
13:03:08 <irenab> baoli: thanks
13:05:58 <baoli> Now that Juno is open, we probably should work on the nova BPs, trying to get them approved soon
13:06:24 <heyongli> hope more than anyone -:)
13:06:33 <rkukura> note that binding:vif_details is now availalbe to nova’s VIF driver: https://review.openstack.org/#/c/83190/
13:06:43 <irenab> baoli: +1
13:07:04 <irenab> rkukura: great job on convincing the community to take this approach
13:07:12 <sadasu> can we discuss the section added by Yongli in the use cases google doc?
13:07:43 <sadasu> rkukura: thanks
13:07:53 <irenab> I want also to dicuss the plans for Juno summit sessions and see that all aspects are covered
13:08:12 <irenab> sadasu: link?
13:08:33 <sadasu> #link https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit
13:09:52 <baoli> yongli, thanks for adding those cases
13:10:03 <beagles> please note that the blueprint review process has changed in nova for juno
13:10:08 <heyongli> welcome
13:10:23 <heyongli> thanks beagles, does nova spec open ?
13:10:38 <beagles> (wiki https://wiki.openstack.org/wiki/Blueprints#Nova)
13:11:06 <beagles> heyongli, not 100% sure on that. Last I noticed there were some details being worked out
13:11:16 <rkukura> also, neutron is adopting similar blueprint review process - details soon
13:11:41 <irenab> beagles: there are lalready number of blueprints submitted there
13:11:44 <baoli> beagles, thanks for the pointer.
13:13:10 <irenab> I think that sessions for cross project track should be submitted till  April 10  and not 20 as others
13:13:58 <sadasu> must say idea of a design template is a good one
13:14:24 <sadasu> now we know what the cores are looking for
13:14:46 <irenab> shall we discuss nova api as part oft the cross project topic together with nova and neutron interaction? I think it is worth to disuss the full story. What do you think?
13:14:52 <heyongli> definitely,  it will speed up review, and not lost some aspect of one design
13:15:49 <heyongli> irenab, the API might fine, but if use aggregate , there is already api avaliable
13:16:25 <sadasu> by Nova api do you mean, how we handle PCI device lists?
13:16:37 <heyongli> recently i considerate it again
13:16:48 <heyongli> sadasu, what is pci device list?
13:17:12 <irenab> heyongli: we need the way to request vnic_type per network required by VM, and John rejected the plain vnic_type for nova boot command, so we need some suggestion here
13:17:13 <sadasu> how we group PCI devices
13:17:47 <heyongli> sadasu, how we group pci, is not a part of pci API, is it?
13:18:08 <sadasu> no...it is not
13:18:26 <irenab> sadasu: also we need suggestion for what you raised
13:18:26 <sadasu> that is why I am suggesting that it should be part of the joint session discussion
13:18:34 <heyongli> irenab, for nova, we should paid attention to the design
13:18:39 <irenab> sadasu: +1
13:18:48 <sadasu> to make sure we handle sr-iov and non sr-iov cases
13:18:54 <irenab> baoli: do we need session in neutron?
13:19:17 <irenab> currently we do not have cross project session proposed
13:19:42 <baoli> irenab, I agree to have a joint session.
13:19:56 <heyongli> another drop of discuss point: aggregate is used to partition the machines in one zones, the pci flavor will break this layer principle
13:20:05 <sadasu> irenab: agreed, I think John had suggested using commonly used terms like "fast" , "medium" etc to describe vnic_type at the API level
13:21:24 <rkukura> isn’t the point of vnic_type to match with the driver inside the VM? Generic terms like “fast” don’t help with that!
13:21:24 <sadasu> +1 for joint session and separate sessions for Nova and Neutron respectively
13:21:29 <irenab> shall we open wiki page and put there all issues to raise?
13:21:44 <heyongli> and aggregate partition the machine by it's attr, and flavor is something user 'created' , sound no so 'aggregate' style.
13:21:54 <heyongli> irenab, the wiki might not be noticed,
13:22:05 <heyongli> suggest put it to session etherpad
13:22:21 <irenab> baoli: do you plan to resubmit the session and depricate the neutron one?
13:22:43 <baoli> Irenab, let me note it down and update it today
13:23:10 <irenab> heyongli: etherpad sounds good
13:23:15 <irenab> baoli: thanks a lot
13:24:20 <irenab> heyongli: do you know where to open the etherpad? IT maybe good idea to notify on ML that there is one for others to contribute too
13:24:41 <heyongli> wait
13:24:59 <heyongli> https://etherpad.openstack.org/p
13:25:04 <heyongli> i think it's ther
13:25:07 <heyongli> e
13:25:09 <irenab> thanks!
13:25:52 <sadasu> rkukura: John does not approve of terms like macvtap, direct etc which are networking specific to be part of the nova api
13:26:44 <sadasu> we might have to come up with a 1 -1 mapping between ^ terms and some other nova approved terms
13:27:15 <irenab> we may need some NIC Flavor tha t admin can create and Tenant may use
13:27:50 <sadasu> heyongli: cool thanks!
13:28:01 <rkukura> sadasu: This might be a situation where writing the docs first would pay off
13:29:47 <heyongli> baoli, i change the interface of my patch, the last 2, and it's almost your idea, check it, i hope it help
13:29:54 <sadasu> rkukura: ok
13:30:33 <baoli> heyongli, i will check it out. What's the interface are you referring to?
13:30:39 <irenab> let's try to put all question/issues we have for end 2 end support on ehterpad first and see if we can cover them with clear proposals or even patches towards the summit
13:30:58 <heyongli> baoli: creat pci request,  find which device have the request id
13:31:22 <baoli> heyongli, sounds good. I'll check it out.
13:31:52 <baoli> Can we focus on yongli's use case for a bit?
13:32:34 <irenab> heyongli: itzikb is currently trying baoli's patch, let us know when we can try your patches
13:32:54 <heyongli> for use case, once everyone notice it, i think it's enough, right, we list them there want to get core easy to involved to review our bp
13:33:53 <heyongli> irenab, i suggest partition the common pci support from the --nic things, ie, my patch +baoli's patch form a whole nova side support.
13:34:37 <irenab> heyongli: ok
13:35:21 <baoli> Yongli, your first use case. By fasterNIC, do you mean to distinguish card types from the same vendor?
13:36:16 <heyongli> baoli: it might be, might not, ie, you can define  'fast' thing is a device who had attr, ie, 10G
13:36:30 <irenab> regarding the use cases, its quite difficult to follow, since you cover the changes. Are these admin use cases?
13:37:13 <heyongli> irenab: might admin and user, cause i put them there to show the design reason
13:37:53 <heyongli> irenab: what you mean about the 'cover the changes'?
13:38:39 <baoli> Yongli, 10G doesn't mean it's fast, and 1G is slower than 10G
13:38:40 <irenab> seems it covers the changes in design comparing previous implementation
13:39:30 <heyongli> baoli: yeah, i just say, a attr different to phy_network
13:39:46 <baoli> Yongli, but my understanding with the first use case is that extra tag may be useful in identifying extra requirement
13:40:20 <heyongli> baoli, right,
13:40:37 <baoli> yongli, the second use case is not specific to SR-IOV
13:41:06 <heyongli> yeah, my section point this out
13:41:37 <heyongli> i want to ensure common pci case is also should be considerated.
13:44:40 <irenab> heyongli: is there a plan to manage PCI flavors via API?
13:44:49 <heyongli> irenab, yeah
13:45:23 <heyongli> and i also try to show aggregate seems not a suit solution, if i'm luck
13:45:56 <heyongli> not a very good choice for flavor i post 2 new reason  above
13:46:05 <irenab> Would it be the correct use case: Admin need to provide thenant with different PCI flavor based on certain capabilities?
13:46:48 <heyongli> irenab: right see my use case 3, it's almost same thing? what do you think
13:48:09 <irenab> heyongli: yes, its seems so.
13:48:25 <baoli> My thought was that the third use case seems to be a good fit for host aggregate.
13:49:10 <baoli> Certainly, it would be combined with pci request
13:49:12 <heyongli> baoli: john argue aggregate for flavor , and for this one, aggregate also work,
13:50:51 <baoli> yongli, your use cases seem to demonstrate that multiple tags are useful for user to select a particular PCI device. But implementation could be quite different
13:51:31 <heyongli> baoli, sure
13:51:44 <irenab> so what we basically need to complete for use cases, is that it is defined from admin/tenant perspective and we propose the way to achive it, from API level, configs,...
13:52:00 <heyongli> i just choose a straightforward one
13:52:40 <heyongli> irenab: more complex use case might lead to miss understanding our intention and distract the review process
13:54:59 <irenab> heyongli: I think we just need to consider that eventually we need to document the steps that admin and tenent should do to achive each use case, so it is good way to separate 'what to do' from 'how it is done'
13:55:01 <beagles> heyongli, I think you have to find a balance.. go too simple and you have to explain "okay, why?" or "how do you seem people being able to use this?" "Why do people want this?"
13:55:28 <heyongli> beagles, +1
13:55:31 <beagles> heyongli, if you cannot explain the part something plays in a big picture, people will want to know why it needs to be done
13:56:12 <beagles> the admin and user perspectives provide a framework for that.
13:56:21 <beagles> here's the other thing
13:56:40 <beagles> if someone asks "How do I write a functional test for this"
13:56:56 <beagles> the admin and user use cases pretty much define that from the get-go
13:57:00 <irenab> we have 5 mins, any plan to achive for coming week?
13:57:16 <heyongli> beagles, if we must get a perfect design , that might be a chanlenge for everyone,  we can fit the design template at least and if some one want to know more, we ensure we had the things somewhere
13:57:51 <beagles> I don't think that's a design .. that's a how we want it to work from a higher level
13:57:55 <beagles> the design falls out of that
13:57:55 <irenab> I can open etherpad for cross project session topics, so we can put any issue there
13:58:11 <heyongli> irenab: at least work for the patch? and get a work combine patch set
13:59:00 <heyongli> thanks irenab, that's a good idea
13:59:07 <irenab> my feeling, we need to invest into sesssion preparation: etherpad, use cases and blueprints
13:59:19 <baoli> let's work on the use cases, please add any you can think of, and we can comment on them. We really need to find some common grounds to move forward.
14:00:00 <irenab> greate, will email the link to etherpad in few mins
14:00:08 <irenab> ^great
14:00:25 <heyongli> sure, let do more mail threading discuss if possible
14:00:35 <baoli> thanks everyone.
14:00:40 <irenab> thanks a lot
14:00:46 <baoli> #endmeeting