13:00:06 <baoli> #startmeeting PCI Passthrough
13:00:08 <openstack> Meeting started Tue Sep 23 13:00:06 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:12 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:13 <baoli> Hi there
13:00:23 <heyongli> hi\
13:00:25 <rpothier> hi
13:02:54 <irenab> hi
13:03:02 <baoli> ok, let's get started.
13:03:24 <baoli> I'd like to go over the list of kilo items: https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough
13:03:39 <heyongli> ok
13:04:01 <baoli> yongli, I saw that you've signed up on a few things.
13:04:15 <heyongli> yeah
13:04:25 <heyongli> intresting
13:04:35 <baoli> heyongli, that's great
13:05:00 <heyongli> i need work harder for the sriov
13:05:28 <irenab> I am still checking the priority internally, but will assign soon as well
13:06:59 <heyongli> if we achive covering or priority, it's good, worry about how many thing could be done in one release
13:07:47 <baoli> heyongli, it also depends on how many people would like to contribute and driver a particular item
13:08:24 <heyongli> yeah
13:08:39 <sadasu_> Hi! I got disconnected briefly
13:08:45 <heyongli> just mention, i working on resize bug
13:08:55 <sadasu_> could you pls give me some context for this discussion?
13:09:15 <sadasu_> ok
13:09:19 <heyongli> just begin, sadasu
13:09:30 <baoli> heyongli, I opened a bug on resize, did you assign it to yourself?
13:09:38 <heyongli> yeah
13:09:58 <baoli> heyongli, cool. did you find anything that you can share?
13:10:14 <irenab> there is also bug with macvtap and hw_veb
13:10:18 <heyongli> not yet
13:10:34 <sadasu_> I am not sure if this was discussed earlier or in other meetings ...but are we tackling the Nova changes to boot SRIOV VMs as a single step this release?
13:10:44 <heyongli> progress slow on starting, and just few hours spend
13:10:48 <sadasu_> but before that what is the bug in macvtap and hw_veb?
13:11:09 <baoli> heyongli, be aware that with the sr-iov change, you can't test resize yet
13:11:25 <itzikb> sadasu_: You can look here https://bugs.launchpad.net/nova/+bug/1370348
13:11:27 <uvirtbot> Launchpad bug 1370348 in nova "Using macvtap vnic_type is not working with vif_type=hw_veb" [Undecided,Incomplete]
13:11:28 <heyongli> got , baoi
13:11:48 <baoli> let's finish the resize, and then go over with the macvtap and hw_veb bug
13:11:55 <sadasu_> itzikb: thanks!
13:12:21 <itzikb> baoli: I think I the nova part is fixed - need to push it
13:12:27 <baoli> heyongli, so you are using icehouse code for testing, right.
13:12:51 <baoli> itzikb, that's great
13:12:59 <heyongli> no, not into that detail now
13:13:09 <heyongli> just begin
13:13:38 <itzikb> baoli: There will be a need for Neutron part
13:14:05 <baoli> heyongli, please keep me in the loop on what you have found on that. I will be touching on that too.
13:14:14 <heyongli> sure
13:14:18 <baoli> itzikb, ok, let's talk about this macvtap bug
13:15:45 <irenab> as far as I know neutron L2 agent will be required to complete VLAN configuration for macvtap
13:15:53 <baoli> itzikb, so the fix is to move 'conf.vlan = vlan' inside the 'if' part of the statement
13:16:08 <itzikb> baoli: yes
13:16:33 <itzikb> baoli: Seems like libvirt doesn't supprot VLAN for 'direct'
13:17:14 <irenab> I plan to add this support for sriovagent, to apply VLAN for macvtap port
13:20:35 <baoli> irenab, that's good
13:21:18 <baoli> itzikb, can you also add unit test when you push it up for review?
13:22:07 <irenab> baoli: but this means that to have macvtap on hw_veb flavor will require agent on compute nodes
13:23:00 <baoli> irenab, why?
13:23:32 <baoli> irenab, you mean since libvirt doesn't support it?
13:23:33 <itzikb> baoli: probably :-)
13:24:45 <irenab> baoli: yes
13:24:52 <itzikb> baoli: (meant for the unit test..)
13:25:22 <irenab> baoli: do you have other idea how to apply vlan from nova?
13:26:17 <baoli> irenab, not really at this point.
13:27:05 <irenab> baoli: seems the best for now is to apply it via neutron agent. Agree?
13:27:35 <baoli> irenab, how do you apply it? calling the ip utility directly?
13:27:47 <irenab> baoli: yes, it was a plan
13:28:11 <baoli> irenab, have you tried it already and did it work?
13:28:45 <irenab> baoli: yes
13:30:07 <baoli> irenab, cool. Do we know why libvirt doesn't support it?
13:30:52 <irenab> baoli: I do not know. But it was the information provided on the bug
13:34:23 <irenab> do we want to be back  to kilo list?
13:34:53 <baoli> irenab, if we make change in the neutron agent code, then port up/down needs to be coordinated with the agent.
13:35:10 <baoli> irenab, in this particular case
13:36:13 <irenab> baoli: not sure what is your concern?
13:37:05 <irenab> agent will try to set admin state, it may return 'unsupported' from ip link, but not fail the agent
13:37:17 <baoli> irenab, it's not a concern. But now that the neutron agent is involved in setting up the vlan, it's kind of similar to the traditional agent, in which case, the agent notifies neutron server of port being brought up.
13:38:08 <irenab> baoli: yes
13:38:38 <irenab> it should be depended on agent to configure networking bits
13:38:59 <baoli> irenab, let's think about it a bit more, we can also discuss offline. Meanwhile, I'd like to see if we can find out why libvirt doesn't support it, or if we should report a bug on that
13:39:15 <irenab> baoli: sure
13:40:02 <sadasu> baoli, irenab: yes, we should spend more time investigating and raising bug again libvirt if required
13:40:41 <baoli> irenab, anything else you want to talk about the list? I thought that you still need time determining priority from your side.
13:41:41 <sadasu> are we talking about the kilo feautre list?
13:41:42 <irenab> baoli: for me I need to see what to dive in, we may discuss what others see as critical, required, nuce to have, ...
13:41:43 <baoli> The big ticket items seem to be 1, 2
13:42:39 <heyongli> and seems live migration is obscure now
13:43:05 <baoli> heyongli, can you clarify?
13:43:29 <heyongli> i mean , do we have any solution or design?
13:44:01 <baoli> heyongli, if you still remember, we discussed a couple of solutions already
13:44:36 <baoli> heyongli, I can dig up the emails, and pass it around again
13:44:58 <heyongli> like ethernet rename thing? i might forgot -:)
13:45:22 <irenab> heyongli: yes, also there is libvirt networks that may be used
13:45:35 <sadasu> baoli: I think 1, 2 and 3 might be high priority
13:45:53 <heyongli> irenab,got
13:46:41 <sadasu> 3 just because of the fact that now "nova boot" for sr-iov ports is a 2 step process as opposed to 1 step
13:46:44 <baoli> does everyone is in favor of changing the vnic-type names?
13:47:23 <sadasu> baoli: +1 also since it seems like a low-hanging-fruit
13:47:36 <baoli> sadasu, I don't think it's because of the naming, If I remember it correctly.
13:48:41 <irenab> I do not think we need just change names
13:49:16 <sadasu> baoli: yes, not directly related to naming, but I think if we get the naming correct, it might get added as a parameter to "nova boot"
13:50:17 <baoli> sadasu, not sure about that.
13:50:40 <sadasu> naming by itself may not add value...the feedback I am getting is that this 1 step VM boot is a great feature in Openstack (as opposed to AWS)
13:50:41 <irenab> sadsu: maybe worth to open discussion on ml?
13:51:36 <irenab> I remember there was a discusion regarding nic types
13:51:43 <sadasu> baoli: let me rephrase...let us focus on getting "nova boot" to be 1 step and if that required re-naming, we can do it
13:52:15 <sadasu> yes, lets discuss on ML, since this is a highly subjective thing and we will hear a lot of opinions
13:52:16 <irenab> sadsu: agree on making nova boot support request for sr-iov
13:52:17 <baoli> sadasu, I completely agree with you on the one-step thing
13:52:43 <irenab> I am not sure that names change is the first step
13:52:54 <baoli> we started it  up that way, but got rejected.
13:53:31 <sadasu> before time runs out, has anyone tried/trying to bring up one VM with an SR-IOV port and a non-SRIOV port?
13:53:42 <baoli> But I think that it may be time to resume that discussion again.
13:53:47 <irenab> sadasu: yes
13:53:53 <baoli> sadasu, I've tested that
13:53:57 <sadasu> baoli: I agree and I think this time around also it might be difficult!!
13:54:28 <irenab> It was with sriovnic and ovs  MDs
13:54:28 <sadasu> baoli: cool
13:54:31 <heyongli> might hard also this time, but we can discuss on ml
13:54:31 <baoli> But I think that we should focus on 1 & 2 so that we can have the functionality in place
13:55:24 <sadasu> irenab: yes, I have tried to bring up seperate VMs, one with SR-IOV port and another VM with non-sriov port
13:55:52 <irenab> sadasu: I did it with two different vNICs on same VM
13:56:00 <sadasu> I was going to try one VM with both ports, just checking if folks expect issues before that
13:56:10 <baoli> Yeah, it's going to be hard since flavors alway is a hot patato
13:56:16 <sadasu> irenab: thanks!
13:57:24 <irenab> any action items for next week?
13:58:23 <baoli> Let's continue with the bugs. Let's look into details of the kilo list, and especially who'd like to contribute or a joint contribution, etc.
13:58:25 <sadasu> investigate use of VLAN in/with libvirt
13:58:57 <irenab> sadsu: for macvtap, right?
13:59:58 <baoli> Ok, thanks everyone, see you guys next week.
14:00:00 <sadasu> irenab: correct
14:00:05 <heyongli> i agree, seems time up
14:00:13 <baoli> #endmeeting