13:01:24 <baoli> #startmeeting PCI Passthrough
13:01:24 <openstack> Meeting started Tue Dec  2 13:01:24 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:27 <openstack> The meeting name has been set to 'pci_passthrough'
13:01:31 <baoli> Hi there
13:01:34 <yongilhe> hi
13:01:55 <pczesno> hi
13:02:35 <riwinters> hi
13:03:28 <baoli> Irena can't attend today.
13:05:33 <baoli> https://wiki.openstack.org/wiki/Meetings/Passthrough#Agenda_on_Dec._2nd.2C_2014
13:05:40 <baoli> Let's get started.
13:06:50 <baoli> Looks like that we have a new neutron bug
13:07:58 <baoli> https://bugs.launchpad.net/neutron/+bug/1397675
13:08:00 <uvirtbot> Launchpad bug 1397675 in neutron "Updating admin_state_up  for port with vnic_type doesn't have affect" [Undecided,New]
13:08:59 <baoli> itzikb: do you have 'agent_required' flag turned on? I guess that you are using mlnx which supports update of port's admin state?
13:09:24 <itzikb> baoli: I'm not using mlnx
13:09:46 <itzikb> baoli: So it's without the agent
13:10:11 <sadasu> itzikb: are you using an agent that can take action on admin_state_up False?
13:10:57 <itzikb> sadasu: No.I'm using Intel 1G NIC and there is no agent involved
13:10:58 <sadasu> itzikb: i see your answer. Without an agent, I don't think this is expected to work
13:12:53 <itzikb> It seems to me there should be a  way to be able to set the admin_state_up if we can't do it we should at least document it and somehow write an error when there is no support for this option
13:13:55 <baoli> itzikb, that sounds reasonable.
13:14:26 <sadasu> itzikb: yes, we are lacking in documentation
13:14:33 <baoli> Ok, anything else for bugs.
13:15:26 <sadasu> last week a discussion surrounding "bonding" of 2 sr-iov ports was brought up...would that be a bug?
13:15:38 <sadasu> I guess that would be more like a new BP category
13:15:46 <baoli> sadasu, right
13:16:09 <baoli> #topic reviews
13:16:09 <sadasu> just wanted to highlight that we have this week to propose a new BP, if needed
13:16:43 <baoli> sadasu, yes, thanks for the reminder
13:18:21 <baoli> yonglihe, I put some comments in your PCI resize wip patch
13:18:53 <yongilhe> thanks, i had no time for it now, i will check it soon
13:18:57 <baoli> https://review.openstack.org/#/c/137530/
13:19:09 <baoli> yonglihe, sure
13:21:25 <yongilhe> baoli, good suggestion
13:22:03 <baoli> yongilhe, thanks
13:22:25 <yongilhe> for 'devices' like resouce, resource tracker does not support that in nature, there some work to do.
13:25:50 <sadasu> I have a question on this review: what is the significance of sign in manager.py?
13:26:18 <yongilhe> it means 'alloce' reserver something.
13:26:27 <baoli> sadasu, check resource_tracker.py on how 'sign' is used over there.
13:26:56 <yongilhe> the negtive sign indicator a claim aborting or direct release the resources.
13:27:23 <baoli> it makes sense if the resource can be arithmetically calculated.
13:27:25 <sadasu> what other values can it have?
13:28:14 <sadasu> +1, 0. -1?
13:28:20 <baoli> 'sign' means + or -
13:28:22 <yongilhe> no other value, just searching the caller you will find it : -1 or default to 1
13:28:26 <sadasu> s/./,
13:28:54 <sadasu> +1 to allocate and -1 to release?
13:29:14 <yongilhe> yeah, it is.
13:29:36 <yongilhe> +1 some time means 'reserved' to pci devices.
13:29:39 <sadasu> thansk
13:30:06 <yongilhe> that why pci need know the stage of resizing.
13:31:23 <baoli> I'll try to push for approvals for several reviews that are in good shape this week.
13:31:40 <baoli> Guess that we can move on to the next topic:
13:31:50 <baoli> #topic Blueprints.
13:31:52 <yongilhe> baoli, thanks, sound cool
13:32:31 <baoli> like Sandhya has mentioned a moment ago, please submit your proposal if any by the end of this week, I guess.
13:32:50 <baoli> deadline is monday
13:32:53 <baoli> end of monday?
13:33:33 <sadasu> baoli: correct
13:35:58 <yongilhe> i'm stuck on other thing, but someone will cover me for the 'interface attaching' bp, hope we can meet the deadline.
13:36:39 <baoli> yongilhe: sounds good
13:36:48 <yongilhe> baoli, how about your migration bp? any progress?
13:37:33 <baoli> yongilhe, some blocking issue came up. Libvirt or the hypervisor doesn't seem to be happy with interface renaming.
13:38:00 <baoli> I've send a query to libvirt-users
13:40:17 <baoli> Hopefully, I can get some resolution soon.
13:41:24 <baoli> network xml doesn't help either. Internally, libvirt converts that to interface, and during live migration, the same interface is needed on the destination host.
13:42:41 <baoli> If anyone has any idea, please let me know.
13:43:23 <yongilhe> baoli, sure, maybe i can consult our hypervisor team to see is there anything can help
13:44:08 <sadasu> baoli: no ideas for a solution...but by "same interface" you mean pci device with same address?
13:44:11 <baoli> yongilhe, that sounds great. Let me forward the libvirt-users query to you.
13:44:35 <baoli> sadasu: same interface name like eth6
13:44:46 <itzikb> baoli: Please send me too
13:45:31 <baoli> irzikb, sure.
13:45:43 <itzikb> baoli: Just a quick question - the problem is with the first migration
13:45:54 <itzikb> baoli: Or back to the original host
13:45:57 <sadasu> ah! so this will probably work only in the use case where we are migrating to a new/clean new server
13:46:37 <baoli> itzikb: the vm couldn't even be booted up.
13:46:44 <sadasu> itzikb: I suppose either direction as long as the same interface is unavailable
13:47:19 <itzikb> baoli: Let's discuss this after the meeting. I think it worked for mlnx_vif
13:48:12 <baoli> itzikb, cool. I thought Irenab has done that.
13:48:33 <baoli> I need to get another intel card and try it on.
13:49:02 <baoli> I don't have any mlnx cards for sure.
13:49:37 <itzikb> baoli: Should work with Intel..
13:50:36 <baoli> itzikb, cool. will give it a try.
13:50:37 <sadasu> is someone bringing up the bonded interfaces case? we were supposed to follow-up on the ML but I didn't see anything
13:51:01 <baoli> sadasu, beagles brought it up.
13:51:04 <baoli> last time
13:51:17 <baoli> pczesno: trying to review your spec. Will add some comments and questions soon.
13:51:33 <pczesno> baoli: great thanks
13:51:36 <sadasu> yes, thats right.
13:52:31 <sadasu> just want to make sure we spend some time to atleast define the problem
13:53:04 <baoli> well, beagles doesn't seem to be present. So let's wait to see his proposal.
13:53:28 <baoli> Ok, move on
13:53:41 <baoli> #topic CI Testing
13:53:48 <baoli> anything on this?
13:54:12 <yongilhe> i'm try to make our CI online asap.
13:55:40 <baoli> yongilhe, that's great!
13:56:04 <yongilhe> any hw CI there?
13:57:00 <itzikb> yongilhe: What tests are your running?
13:57:22 <sadasu> I have questions on how to convert my existing setup to do Nova CI
13:57:39 <sadasu> can we do both Nova and Neutron CI on the same TB?
13:58:02 <sadasu> I am investigating in the background...will hopefully have an update in the next meeting
13:58:03 <yongilhe> itzikb, to online, first stage only had baisc pci passthrough testing. and will add more and more gradully.
13:58:53 <yongilhe> sadasu, we trying to cover basic sriov after online.
13:59:03 <itzikb> yongilhe: You mean local testing or tests that are upstream?
13:59:59 <yongilhe> itzikb, i don't know yet, but upstream a HW specific test seems not very valuable. but if it does, we happy to upstream all of them.
14:01:24 <baoli> Time is running out. So let's continue next time
14:01:38 <baoli> thanks everyone
14:01:42 <yongilhe> sure, then, bye
14:01:46 <baoli> #endmeeting