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