13:09:51 <ndipanov> #startmeeting sriov 13:09:52 <openstack> Meeting started Tue Nov 10 13:09:51 2015 UTC and is due to finish in 60 minutes. The chair is ndipanov. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:09:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:09:55 <openstack> The meeting name has been set to 'sriov' 13:10:02 <beagles> ta-dah 13:10:02 <ndipanov> nice! 13:10:07 <moshele> we had not a meeting for 4 months I think 13:10:24 <ndipanov> I changed the meeting earlier today 13:10:38 <ndipanov> mostly cosmetic change + moved it to biweekly 13:10:47 * johnthetubaguy lurks in case he can help unblock process stuff 13:10:49 <ndipanov> https://review.openstack.org/#/c/243382/ 13:11:20 <ndipanov> not sure the time works for everyone - but if it doesn't - we can try and move it 13:11:39 <ndipanov> #action ndipanov to include [Neutron] on the next reply to the thread 13:12:13 <moshele> usually there were some intel guys in the meeting but I can't find the on the irc 13:12:16 <ndipanov> thanks johnthetubaguy 13:12:37 <ndipanov> moshele, nicks? 13:13:55 <moshele> smoony and prezno I think 13:14:34 <ndipanov> OK they sound familiar from gerrit 13:14:48 <lbelivea> Add me as well please, we heavily working on SR-IOV and trying to contribute more 13:15:28 <ndipanov> lbelivea, add you to my mental map of sriov interested people :) 13:15:45 <ndipanov> what are you working on 13:15:48 <ndipanov> ? 13:16:15 <ndipanov> actually while we are here - why not everyone who is lurking and interested give a short overview of what they plan to look into in Mitaka? 13:16:22 <ndipanov> I can start 13:16:37 <lbelivea> We have some new feature in the pipeline, but now I'm mostly trying to push some fixes (especially around support for cold mgiration - we have it delivered to customer) 13:17:12 <moshele> lbelivea: I review it https://review.openstack.org/#/c/242573/ we need it as well :) 13:17:21 <ndipanov> lbelivea, excellent - do you have any patches up 13:17:29 <lbelivea> moshele: thanks ! More coming :) 13:17:55 <ndipanov> #info add any pathces that might be ready to: https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking 13:17:57 <lbelivea> two for the moment: https://review.openstack.org/#/c/242555/ and https://review.openstack.org/#/c/242573/ 13:18:11 <lbelivea> Will do 13:18:12 <ndipanov> ok I will add those and will look at them ASAP 13:18:17 <ndipanov> or you can 13:18:45 <moshele> I have this https://review.openstack.org/#/c/199488/ 13:19:11 <lbelivea> moshele: I'll have a look today 13:19:25 <moshele> and this https://review.openstack.org/#/c/227160/ which I need to talk to baoli 13:19:53 <lbelivea> moshele: this one I reviewed 13:20:07 <ndipanov> moshele, heh I thought that one landed already :) 13:20:57 <moshele> also I want to push this bp https://review.openstack.org/#/c/135331/ but I am missing the intel guys 13:21:32 <ndipanov> I am currently mostly looking into https://review.openstack.org/#/c/212472/ 13:21:53 <ndipanov> moshele, let me add that one to the etherpad too 13:22:02 <ndipanov> (thought it seems to have a -1 from johnthetubaguy 13:22:04 <ndipanov> ) 13:22:36 <moshele> ndipanov: are you pushing the BWG for SR-IOV integration with nova scheduler ? or it is ajo ? 13:23:33 <moshele> ndipanov: I am taking about Qos feature phase 2 13:24:26 <ndipanov> moshele, that would be ajo 13:24:41 <ndipanov> well 13:24:58 <ndipanov> so I tried to get some discussion around this going in tokyo 13:25:45 <ndipanov> but I don't feel there was a very concentrated effort, and a lot of stuff is still up in the air 13:26:15 <ndipanov> I did speak to some neutron folks about it 13:26:53 <ndipanov> and there was a general discussion about how we might at one point in the future do scheduling based on neutron data 13:27:19 <ndipanov> but currently there is no clear direction that anyone has proposed to the best of my knowledge 13:28:14 <ndipanov> moshele, do you have more info on this? specs proposed? discussions I am not aware of? 13:29:22 <moshele> regrading the scheduling, no 13:30:00 <moshele> ndipanov: regrading SR-IOV there is also this bp https://review.openstack.org/#/c/139910/ 13:30:46 <ndipanov> moshele, ah yes - I saw that one - will read new comments on it 13:30:48 <lbelivea> Commented on this one, dunno if it's still "active" 13:31:56 <ndipanov> lbelivea, that is also by some Intel guys I think - I spoke to some of them in Tokyo 13:32:09 <ndipanov> I\d assume that it is 13:32:11 <lbelivea> nevermind, comments are quite recent 13:33:03 <ndipanov> so yeah - how to do scheduling based on Neutron information is something that I'd really like to get to soon 13:33:41 <ndipanov> currently it's based on manually set network_name - which is very crude 13:34:33 <ndipanov> that needs someone to seriously drive it and I did not see anyone really stepping up in tokyo at least 13:34:43 <ndipanov> although ajo was not there 13:34:55 <ndipanov> and he did discuss it previously 13:35:04 <lbelivea> ndipanov: Is there a BP for that ? 13:35:19 <ndipanov> lbelivea, I don't think so 13:35:30 <ndipanov> hmmm 13:35:35 <ndipanov> let me try to dig 13:36:20 <ndipanov> lbelivea, I don't think so 13:36:37 <ndipanov> I will follow up with ajo and see if he has some more info 13:36:45 <lbelivea> Would be nice to have more info/req 13:37:17 <ndipanov> #action ndipanov to follow up with Neutron team on more detailed requirements around qos scheduling 13:37:23 <ndipanov> lbelivea, agreed 13:37:49 <ndipanov> so about cold migration/resize 13:38:04 <moshele> ndipanov: didn't we say in the Qos meeting the we can solve the BWG for SR-IOV because nova knows the VF? or are you looking for a complete solution on how the nova schedule can get update for other openstack project like neutron ? 13:39:54 <ndipanov> moshele, well ideally yes - I mean there is also the ovs implementation in neutron 13:41:28 <ndipanov> besides how would that work for the current sriov code in nova - we'd have to add yet more stuff like bandwidth to the stats dict 13:41:34 <ndipanov> ? 13:42:57 <moshele> yes, it is ugly but can be done in M, the second option seem far away 13:42:58 <ndipanov> not sure that going with the hacky sriov only solution is the right aproach here - I feel that we will save ourselves pain down the line if we came up with an actual solution to this 13:43:08 <ndipanov> need to think about it 13:43:20 <ndipanov> moshele, is there anything proposed along those lines now? 13:44:08 <moshele> no 13:44:56 <ndipanov> ok well let me follow up with ajo and the neutron qos folks and see what they think 13:46:10 <ndipanov> tbh my beef with this is mainly about interface with neutron being magic random strings more than anything 13:47:00 <ndipanov> ok moving on - one more thing I was going to ask lbelivea - is there a bug related to the cold migration? 13:48:26 <lbelivea> ndipanov: yes this one https://review.openstack.org/#/c/242573/, it was tested in a lab with two computes with devstack 13:48:59 <ndipanov> I was fixing some issues around migrating instances with cpu pinning in Liberty and it seems to me that a similar approach can work for pci devices 13:49:18 <lbelivea> ndipanov: we'll put more in the pipeline, there are other cornes cases that are not covered (some race conditions, etc.) 13:49:26 <moshele> ndipanov: cold migration is broken since Juno or never work at all itizikb opened a bug https://bugs.launchpad.net/nova/+bug/1400784 13:49:26 <openstack> Launchpad bug 1400784 in OpenStack Compute (nova) "Cold migration fails when using vnic_type=direct" [Medium,Confirmed] - Assigned to Yongli He (yongli-he) 13:50:52 <lbelivea> moshele: let me have a look, maybe it should be assigned to me, my fix could probably cover his bug description 13:51:06 <moshele> also I think resize is not working https://bugs.launchpad.net/nova/+bug/1368201 13:51:06 <openstack> Launchpad bug 1368201 in OpenStack Compute (nova) "resize with PCI devices doesn't work" [Low,In progress] - Assigned to Yongli He (yongli-he) 13:51:18 <ndipanov> right - so I will review the proposed patch 13:51:53 <lbelivea> ndipanov: which related bug ? I would be interested to have a look 13:52:13 <ndipanov> lbelivea, yeah gimme a sec to dig it up 13:52:28 <lbelivea> TBH, I don't have a solution yet for a resize with different number of PCI devices in the flavor, need to look at that 13:52:34 <ndipanov> but the idea is that this kind of stuff needs to be done when doing the claims 13:52:50 <lbelivea> agreed 13:52:57 <ndipanov> what I did was added a concept of migration context 13:53:11 <ndipanov> that allows us to save and restore "new" compute host data 13:53:15 <ndipanov> in a non-racy manner 13:53:20 <ndipanov> (if we are careful :) ) 13:53:44 <lbelivea> ndipanov: do you have a review for it so that I can look at code ? 13:54:22 <ndipanov> https://review.openstack.org/#/c/218385/ 13:54:40 <ndipanov> https://review.openstack.org/#/c/218938/ 13:54:59 <ndipanov> sadly gerrit does not keep relation of merged patches 13:55:00 <ndipanov> :( 13:55:21 <ndipanov> but most of them were related to that one BP and bug that is linked from those 13:55:22 <lbelivea> I will have a look and keep in mind PCI devices 13:56:19 <ndipanov> lbelivea, cool 13:57:13 <ndipanov> lbelivea, will review https://review.openstack.org/#/c/242573/ tomorrow ASAP 13:57:41 <lbelivea> ndipanov, awesome - I'll address moshele comments today 13:57:51 <ndipanov> cool - progress! 13:58:04 <ndipanov> coming close on time 13:58:12 <lbelivea> perfect ! 13:58:40 <ndipanov> one more thing I was gonna bring up is https://blueprints.launchpad.net/nova/+spec/extend-vnic-pci-detail-info 13:59:29 <ndipanov> those folks were asking for this at the summit and I feel that it is mostly covered by https://review.openstack.org/#/c/195662/ and if it's not it should be 13:59:49 <ndipanov> but I guess I'll have to catch them on IRC 13:59:55 <ndipanov> anyway - thanks for the chat folks 14:00:06 <lbelivea> is that related to https://review.openstack.org/#/c/195662/8 ? 14:00:27 <ndipanov> I think it should be 14:00:28 <lbelivea> oh right, you had the same thinking 14:00:41 <lbelivea> you got faster than me at cut&paste :) 14:00:50 <ndipanov> although the people proposing it claim it doesn't do everything they need 14:01:08 <ndipanov> and that's where we kind of stopped 14:01:13 <trown> o/ 14:01:13 <ndipanov> anyway need to finish 14:01:17 <ndipanov> #endmeeting sriov