13:01:53 <baoli> #startmeeting PCI Passthrough
13:01:54 <openstack> Meeting started Wed Feb 19 13:01:53 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:57 <openstack> The meeting name has been set to 'pci_passthrough'
13:02:20 <heyongli> hi
13:03:26 <baoli> I don't have a specific agenda
13:03:44 <irenab> let's do update each on on his parts
13:03:51 <heyongli> i release a patch set contain basic support , you can check it
13:04:19 <heyongli> lack of unit test, working on that
13:04:44 <irenab> heyongli: is all needed for pci white list definition with tags already under review?
13:04:58 <baoli> https://review.openstack.org/57860 https://review.openstack.org/63267?
13:04:58 <heyongli> irenab, yes
13:05:12 <heyongli> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/pci-extra-info,n,z
13:05:16 <heyongli> this topic
13:05:39 <baoli> heyongli, I will take a look at it.
13:06:12 <irenab> me too
13:06:23 <heyongli> i hope you can review bp, concentrate to the use case, it's not good now.
13:07:03 <heyongli> baoli, the request mark is also release, maybe a proposal  patch, the last one
13:07:42 <baoli> heyongli, I will look at it the first thing after the meeting
13:08:54 <irenab> my turn?
13:09:20 <heyongli> sure
13:09:25 <baoli> heyongli, I am also working on a patch to support the three neutron sriov requirements. Just so let you know.
13:10:02 <irenab> vnic_type is reworked according to the rkukura and baoli comments, will upload it after the meeting
13:10:06 <heyongli> you can invite me to review that, then i can not miss it
13:10:26 <irenab> rkukura: sorry for messing your patch yesterday...
13:10:50 <sadasu> Hi
13:10:59 <baoli> irenab, I'm hoping to use your patch soon
13:11:01 <rkukura> irenab: No problem
13:11:21 <irenab> also uploaded WIP for ml2 MD to consume all baoli's work
13:11:52 <irenab> just to make it till 18 Feb
13:12:04 <baoli> irenab, that's good news. Once I can get the basics to work, I will publish my patch. Hopefully soon
13:12:22 <sadasu> irenab: link for that BP/review?
13:12:27 <irenab> baoli: have question on you comment regarding the models.py defined lenght
13:13:00 <irenab> vnic_type is currently defined  to be 64 chars
13:13:19 <baoli> irenab, it's a nit. just wondering why it needs 64 chars
13:13:40 <irenab> no special reason, just looked at vif_type
13:13:47 <rkukura> I suspect irenab was following precedent
13:14:22 <baoli> yesterday, I surprisingly found that mysql used up all my disks. I ended up reinstalling it on my server.
13:14:40 <rkukura> probably makes sense to leave some extra room for longer names than are currently needed
13:14:57 <irenab> baoli: I think yesterday was challenging day for many of us...
13:15:20 <irenab> rkukura: have question on DocImpact
13:15:22 <baoli> I think 64 is fine.
13:15:27 <rkukura> sure
13:15:35 <baoli> but 32 would do.
13:15:44 <baoli> Given that this is something internally defined
13:16:05 <irenab> rkukura: I saw it on your patch. Shall I add it for vnic_type
13:16:10 <rkukura> irenab: What's the question?
13:16:15 <rkukura> oh
13:16:44 <rkukura> Yes, a similar comment would make sense
13:16:44 <irenab> is there any instruction what to put there?
13:16:54 <rkukura> maybe it does effect user docs, though
13:17:22 <irenab> I think it may, since this attribute is accesable for user
13:17:27 <rkukura> https://wiki.openstack.org/wiki/Documentation/DocImpact
13:17:42 <irenab> Does it mean I need to update the documentation?
13:18:17 <rkukura> Presumably, there will be a documentation effort covering the SR-IOV effort and this would be part of it, right?
13:18:20 <irenab> rkukura: thanks
13:19:21 <irenab> I think it should be
13:19:29 <rkukura> Just say something like "DocImpact: Update portbindings API docs and include in SR-IOV user docs"
13:19:32 <baoli> sadasu, you can find the link from our meeting wiki
13:19:46 <sadasu> baoli: ok...thanks
13:21:07 <beagles> kind of on that note...
13:21:09 <beagles> Is there an "end-to-end" description of the workflows and how they are implemented around SR-IOV? e.g.: enabling SR-IOV support/configuration, flavor management, tenant/quota relationships, specifiying the resources at instance boot, migration (if supported), compute node restart, etc.
13:21:25 <beagles> I've been looking at doing this, but don't want to repeat work that's already been done.
13:21:43 <beagles> (and yes, I pretyped that question into an editor... I can't type that fast)
13:21:54 <itzikb> :-)
13:22:00 <baoli> beagles, we started up with a google doc
13:22:24 <baoli> I can forward you all the docs folks in this subgroup has been working on
13:22:30 <beagles> that would be cool!
13:22:39 <baoli> after the meeting.
13:22:44 <sgordon> baoli, i think part of the problem at this point is there are too many docs
13:22:59 <beagles> sgordon beats me to the punch
13:23:03 <sgordon> in varying stages of completeness depending on how far through the cycle they were written
13:23:09 <irenab> beagles: I think it will be great if you can put all in one doc
13:23:17 <beagles> I wanted to bring it all under one roof
13:23:20 <sgordon> i think there needs to be a canonical design to get core attention, at least on the nova side
13:23:22 <beagles> (so to speak)
13:23:22 <sgordon> beagles, +1
13:23:43 <beagles> the other aspect...
13:23:46 <baoli> sgordon, I understand. We were trying very hard to converge
13:24:05 <irenab> beagles: There is still work to do to close details for nova APIs
13:24:36 <beagles> is that it will help us define functional subsets so we can say when certain features will be available... and also identify gaps that need to be closed for same.
13:25:02 <irenab> beagles: +1
13:25:52 <baoli> beagles, has you been able to follow the ML on pci passthrough and SRIOV?
13:26:26 <beagles> baoli, I've been playing catchup :)
13:27:00 <beagles> baoli, at the moment I have a bunch of silly stupid questions... each time I write one down, 15 minutes I find the answer somewhere :)
13:27:24 <baoli> I can compile a list and send to you guys. That way, you can see what have been discussed
13:28:28 <baoli> beagles, that's very productive, and I bet they are good questions
13:29:27 <irenab> beagles: you can send these questions to the team
13:29:42 <irenab> anyway, will be glad to help
13:30:15 <beagles> baoli, well... lol I don't know about that. Some are pretty ridiculous, but barring unforeseen stuff I should have a good list at the end of today and I'll send it out tot he ML
13:30:59 <baoli> beagles, looking forward to it.
13:31:57 <sadasu> I had an unrelated question
13:31:59 <irenab> rkukura: for your comment on nova bug, are you ok for now to skip the multi-segment extension and make dict for provider_net extension attributes?
13:32:57 <rkukura> irenab: I'd like the data model exposed within nova to support multiple segments, and include the other attributes
13:33:24 <rkukura> Its OK for now if it only uses the providernet extension and those has at most one segment
13:33:43 <rkukura> But I suspect going from that to the full implementation would only add a couple lines of code.
13:34:02 <rkukura> s/those/thus/
13:34:54 <irenab> rkukura: ok, will see if can support both from day one
13:35:11 <baoli> rkukura, my understanding is that this bug is a temp fix that is only used by mlnx plugin
13:35:22 <irenab> it can be either multi-segment or provider extension, right?
13:35:57 <baoli> once incorporated with the sriov workflow, the fix will no longer be needed
13:36:03 <rkukura> baoli: I wasn't aware this was a temporary fix. How would it differ from the longer term fix?
13:36:28 <baoli> rkukura, did you read my comments in the review?
13:36:40 <irenab> Yes, we need to propagate physical network name to VIF Driver
13:37:15 <irenab> but I think that part that retrives physical network nbames can be added in way it supportes SRIOV scheduling
13:37:16 <rkukura> I see "With understanding that this fix is currently needed for mlnx ML2 plugin, I'm ok with the change."
13:37:47 <irenab> s/nbames/names
13:38:31 <rkukura> baoli: Reading other comments now
13:38:36 <irenab> So the only temporary part is adding physical_network name to network object of the VIF
13:40:15 <rkukura> baoli: your 2/13 comment on the workflow makes sense, I think
13:41:07 <rkukura> irenab: OK, I understand that the VIF driver needs this network info for the mlnx plugin, and the nova scheduler needs it for SR-IOV, right?
13:41:37 <irenab> rkukura: yes
13:41:47 <rkukura> And with SR-IOV, nova will set binding:profile:physical_network to indicate which segment is being used.
13:41:56 <rkukura> All sounds good to me.
13:42:09 <baoli> irenab, the physical network names are retrieved for scheduling time
13:42:35 <irenab> baoli: Agree , but you still will call neutronV2 api to get it, right?
13:42:37 <baoli> the acutal physical net used will be set on the compute node
13:42:57 <baoli> irenab, yes, we get it during scheduling
13:43:14 <irenab> so you still need method to get it
13:43:35 <baoli> irenab, the method to get it will be different from the one in the bug fix
13:44:11 <irenab> baoli:can you explain the difference?
13:44:31 <baoli> irenab, I have the method in my current patch.
13:44:48 <baoli> https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov
13:45:10 <baoli> https://review.openstack.org/#/c/67500/ actually
13:45:20 <irenab> OK, so just wondering what should be done here for now if any ....
13:45:58 <irenab> baloi: will look at it after the meeting
13:49:45 <sadasu> before the meeting ends, just wanted to check if we could have a sr-iov meeting on the Monday of the summit
13:50:09 <sadasu> we don't have a any neutron sessions on Monday
13:50:23 <sadasu> need to plan travel accordingly
13:50:35 <irenab> is there already agenda for the summit?
13:51:03 <sadasu> not detailed...but we know that Neutron design sessions got from Tue - Fri
13:51:13 <sadasu> s/got/go
13:52:33 <irenab> sadasu: any specific content for the sr-iov meeting?
13:53:03 <sadasu> just next steps and what we would be done in Juno
13:53:05 <irenab> I think we may need nova design session for what we call long term
13:53:16 <beagles> irenab, +1
13:53:17 <rkukura> sadasu: I'll plan to there on Monday, not sure what else may be happening that day, but sounds like a good opportunity
13:53:22 <sadasu> mostly in terms of Nova ...
13:53:33 <rkukura> when's the next SR-IOV IRC meeting?
13:53:49 <baoli> next tuesday
13:54:02 <baoli> we plan to switch back to weekly meeting
13:54:43 <beagles> baoli, same time?
13:54:50 <baoli> but anyone can propose a sync-up meeting during Monday-Thursday.
13:54:57 <baoli> beagles, yes
13:54:58 <sadasu> Is there a Nova design session for pci-passthrough planned?
13:55:09 <irenab> I think we should drive it
13:55:19 <sadasu> irenab, agreed....
13:55:26 <heyongli> i have no idea now
13:55:32 <baoli> We should plan two sessions, one for nova and one for neutron
13:55:40 <rkukura> joint session?
13:55:50 <sadasu> joint session makes sense
13:55:58 <irenab> does it makes sence to have neutron aware scheduler session?
13:56:12 <sadasu> we need to present both pieces together to get/give the complete picture
13:56:32 <baoli> joint session is good.
13:57:06 <irenab> rkukura: any idea how to drive the joint session?
13:57:17 <sadasu> I think we need Nova flavor type discussion and something around neutron aware scheduling
13:57:39 <rkukura> I think proposing a similar session in both nova and neutron, and suggesting they be a join session, would do it.
13:58:05 <rkukura> Still might makes sense to get together Monday to prepare for a join session later in the week.
13:58:07 <irenab> we have also the nova boot API for --nic
13:58:10 <beagles> yeah, that should be pretty clear when proposing the sessions (scheduling and flavors) so they can try and work it that the folks driving scheduling on the nova side have minimal conflicts
13:58:38 <sadasu> baoli, is the discussion around using host aggregates done?
13:58:49 <beagles> rkukura, +1
13:59:00 <baoli> sadasu, not sure.
13:59:00 <irenab> seems we need IRC meeting (or few of them) to plan agenda for the summit
13:59:07 <beagles> :)
13:59:09 <rkukura> I nice picture of the workflow for SR-IOV with some sort of color coding of what's in icehouse, what's absolutely required, and what's nice to add would probably be all that's needed to driver a good discussion
13:59:24 <heyongli> aggregate discuss not closed by yunhong's update from meetup
13:59:32 <sadasu> rkukura, +1
13:59:43 <beagles> rkukura, sounds like the stuff I talked about would be a good place to start
13:59:52 <rkukura> beagles: +1
13:59:54 <baoli> rkukura, yes
14:00:04 <irenab> beagles: +1
14:00:09 <sadasu> I know we are not solving that problem in icehouse, would be great to discuss during the summit
14:00:37 <sadasu> host aggregates, I mean
14:00:40 <heyongli> sure
14:01:07 <sadasu> ok...so dfntly planning to be there on Monday for discussions
14:01:08 <irenab> I think that all user experience parts are not covered well for now
14:01:26 <sadasu> irenab, +1
14:01:54 <irenab> sadasu: agree. Hope to have flights to be there on Monday
14:02:07 <sadasu> lets work on the doc beagles suggested at start of meeting
14:02:27 <sadasu> with color coded diagram rkukura suggested
14:02:49 <sadasu> and then use that to put in proposal for joint session
14:02:51 <heyongli> next monday?
14:03:25 <irenab> rkukura: would you be avaialble later today or tomorrow for few mins to dicuss the nova bug fix?
14:03:43 <baoli> I think that we need to start with a recap on what we have discussed so far, plus the diagram
14:04:04 <rkukura> irenab: I'm booked most of this AM (EST) but later today or tomorrow would be fine
14:04:19 <irenab> so, next IRC meeting focusing on it?
14:04:34 <sadasu> irenab, it?
14:04:57 <rkukura> bye everyone - I've got another meeting to switch to
14:04:59 <irenab> sadasu: agenda you suggested
14:05:21 <sadasu> irenab: thanks :-)
14:05:30 <heyongli> bye
14:05:34 <baoli> ok, let's meet on Tues.
14:05:40 <sadasu> thanks everyone
14:05:42 <beagles> cheers!
14:05:47 <irenab> thanks, bye
14:06:06 <baoli> #endmeeting