13:00:30 <baoli> #startmeeting PCI Passthrough
13:00:31 <openstack> Meeting started Tue May 27 13:00:30 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:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:34 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:49 <baoli> Hi
13:00:51 <heyongli> hi, all
13:00:55 <yjiang5> hi
13:01:12 <heyongli> how many alarm you set
13:01:27 <yjiang5> heyongli:  2 this time :)
13:01:39 <irenab> hi
13:01:43 <baoli> yjiang5, thanks a lot for joining
13:02:04 <yjiang5> baoli: :)
13:02:23 <irenab> baoli: great work on the spec!
13:02:40 <baoli> I put together a little agenda for today: https://wiki.openstack.org/wiki/Meetings/Passthrough#Agenda_on_May_26th.2C_2014
13:02:59 <baoli> irenab, heyongli: thanks for reviewing
13:03:50 <irenab> great, lets start according to agenda
13:03:55 <heyongli> do we join NFV instead of pci sriov alone?
13:04:32 <irenab> I am not sure we can keep focus there, but must follow what happens in NFV
13:04:45 <baoli> agreed
13:05:23 <beagles> I also concur
13:05:38 <baoli> I asked Jointhetubaguy to review the spec. Hoepfully he will remove the -2 soon.
13:06:21 <irenab> baoli: good, I think -2 may cause other cores to skip review
13:06:52 <beagles> irenab, that is probably correct
13:07:31 * beagles apologizes for being a couple of minutes late and also offers baoli praise on his spec work!
13:08:05 <baoli> Thanks beagles
13:08:35 <baoli> anything else about the spec?
13:09:00 <irenab> I passed any concern on review
13:09:07 <baoli> If you think it's in good shape, please give +1.
13:09:25 <heyongli> sure,
13:09:32 <irenab> Already done. I just was suprised you do not need any help :-)
13:10:03 <baoli> irenab, I appreciated your offering of help.
13:10:49 <irenab> baoli: I am just concerned to have it as soon as possible under review
13:11:02 <baoli> irenab, we also have a team here to help.
13:11:26 <irenab> as beagles mentioned there is a lot of changes in the neutronV2 area
13:11:46 <irenab> baoli: great!
13:12:09 <irenab> shall we skip to next topic on agenda?
13:12:20 <baoli> irenab, do you expect any significant change and difference from the POC, in the neutronv2 area?
13:12:35 <baoli> irenab, I'd like to hear from you on that.
13:13:07 <irenab> baoli: Not for our needs, but other mainly refactoring tasks may be pushed by others
13:13:32 <baoli> irenab, in that case, I'd like to see them addressed separately.
13:14:57 <irenab> baoli: the point I wanted to raise is that you may find youself rebasing the patch, but its part of the process, so will be OK.
13:15:22 <baoli> I appreciated everyone's help. So let's get the spec approved, and started reviewing the official patch soon.
13:15:49 <irenab> +1
13:17:19 <irenab> tempest tests ?
13:17:43 <baoli> #topic tempest tests
13:17:48 <beagles> before discussing tempest tests are we talking about a single patch or multiple patches?
13:17:54 <beagles> (too slow)
13:18:35 <baoli> beagles, we'll submit multiple patches to facilitate the review process. But there might be dependencies between the patches
13:19:20 <beagles> baoli: cool... the dependency thing is cool as well. been-there-done-that with several reviews lately.
13:20:09 <baoli> irenab, mlnx has CI tests. Does it support sr-iov networkign already?
13:20:17 <heyongli> dependencies is ok if every one is keep every thing not broken
13:20:24 <irenab> baoli: yes
13:20:49 <baoli> irenab, does it need to be enhanced/modified with the new nova code?
13:21:22 <irenab> baoli: it covers mellanox sr-iov mech driver, which does not use
13:21:49 <irenab> does not use the POC, it has some external package to do resource allocation of VFs
13:22:19 <irenab> going forward with HW_VEB mech. driver it will use your code in nova
13:23:16 <baoli> irenab, do you expect any change of code for mlnx tempest tests?
13:23:16 <irenab> for now we run mostly api tests
13:23:44 <baoli> irenab, so no real hardware based tests?
13:23:56 <irenab> bali: need to start end 2 end tests with real networking
13:24:03 <yjiang5> irenab baoli: IIRC, we have CI test also for PCI, but not cover SR-IOV yet, only generic PCI passthrough integration test. I think possibly we need discuss the NFV testing as a general topic in NFV meeting, which requires gate on hardware?
13:24:16 <irenab> baoli: yues with real hardware, but not with full end 2 end tests
13:25:18 <yjiang5> irenab: baoli: how is neutron handle the hardware specific integration testing?
13:25:36 <baoli> Sadasu is not here. But with cisco MD, I believe we'll have tests on real hw as well.
13:25:48 <irenab> yjiang5: it expects the 3rd party testing system to verify
13:25:52 <sadasu> baoli: I am right here
13:26:07 <baoli> sadasu, sorry didn't notice
13:26:16 <sadasu> comment regarding cisco tempest tests is correct
13:26:32 <irenab> do you think we need special tests to be added to tempest?
13:28:05 <sadasu> irenab: yes...we have to
13:28:09 <yjiang5> irenab: sadasu: I think we need special tests in tempest, but will be skipped in gate.
13:28:36 <sadasu> yes, these tests would have ti be specific to verndor specific CI tests
13:29:25 <sadasu> I am not sure if this would be a dependency for baoli's nova commit
13:29:31 <irenab> sadasu: I am not sure why tests should be specific. I think that setup is vendor specific but tests should be common
13:29:48 <yjiang5> sadasu: Do we need vendor specific CI? I thought it will be generic one, but be executed in 3rd party hardware. Nova has no hardware specific driver, .
13:29:51 <yjiang5> irenab: +1
13:30:12 <sadasu> vendor specific hw setup, but common CI tests...thanks for correcting irenab
13:31:10 <irenab> so I guess we need tests to cover nova boot for -- nic port_id case with SR-IOV port request, right?
13:31:10 <baoli> one question through, vendor MD requires specific config, right?
13:31:29 <baoli> irenab, that's right
13:31:37 <sadasu> irenab: correct
13:31:56 <sadasu> but that should still be part of tests for the mech drivers
13:32:21 <sadasu> how is this usually done in Nova?
13:32:21 <baoli> sadasu, so tests are specific to MD drivers.
13:32:24 <yjiang5> irenab: one thing come to mind is, the provider_physical_network will be test environment specific ?
13:32:46 <irenab> yjiang5: correct
13:34:02 <baoli> yjiang5: unless we'd like to develop common tests, from which vendor tests are based on, which will setup vendor specific config, etc.
13:34:10 <sadasu> I think the tests that check the nova boot with --nic port_id would be common
13:34:29 <sadasu> also the neutron port create tests would be common
13:34:30 <irenab> sadasu: agree
13:35:02 <sadasu> I am only not sure if each vendor's CI tests would want to add additional tests that are specific to their use case
13:35:15 <sadasu> in this particular aspect the tests might differ
13:35:28 <sadasu> but that completely depends on each vendor
13:35:51 <irenab> I do not have much knowledge on tempest tests, need some time to look and see what is there and which tests are missing for SR-IOV case
13:36:30 <irenab> I think at least basic connectivity cases should be covered by common tests
13:36:35 <sadasu> there are no tests that are specific to the SR-IOV case at this point
13:37:30 <beagles> irenab: true, but the usage pattern (create port, pass to nova) may not be exercised. mlavalle or marun may be able to give you some quick feedback on that
13:37:30 <irenab> for my understanding, except for using pre created neutron port with vnic_type=direct, there should be common cases that are applicable for SR-IOV based solution
13:37:53 <yjiang5> sadasu: in neutron, will vendor-specific test case be added to tempest?
13:38:04 <sadasu> I don't think we would have to come up with completely new tests, modifying existing tests (pre create sr-iov port) to suit the SR-IOV case would take care of most of the testing
13:38:38 <sadasu> yjiang5: not to generic tempest tests
13:39:00 <yjiang5> sadasu: thanks.
13:39:03 <irenab> beagles: I'll take a look and check with marun or mlavalle
13:39:32 <baoli> irenab, sadasu, would you like to take a look at tempest tests for sr-iov networking?
13:39:36 <beagles> sadasu, some of these tests are based on "works with nova-network, works with neutron"-parity kind of thing so it is quite possible that new tests will be needed -
13:39:41 <beagles> ... so that's an action item :)
13:39:43 <beagles> ooo
13:40:13 <beagles> also.. btw there is  WIP of porting neutron to use oslo.rpc. it should not affect tempest tests (directly anyways) but...
13:40:44 <yjiang5> beagles: I think it should be ok, right?
13:40:47 <irenab> beagles: sounds like you want to take a look on tempest :-)
13:40:50 <beagles> it may benefit from coordination with the people working on it for creating any additional unit tests etc
13:41:09 <beagles> irenab, please no :)
13:41:29 <yjiang5> irenab: I will have a look on tempest
13:41:35 <beagles> I will definitely help though.. just that the third party CI stuff is completely foreign to me...
13:41:46 <baoli> we need to finalize the tempest tests soon.
13:41:47 <sadasu> baoli: I am already looking into the tempest tests for the cisco CI case for my ML2 driver
13:41:59 <irenab> yjiang5: thanks!
13:41:59 <baoli> sadasu, great and thanks!
13:42:13 <baoli> yjiang5, thanks.
13:42:32 <irenab> sadasu: anythink you would like to share for next meeting, to consider to put it upstream?
13:42:33 <baoli> So next meeting, we may have a concrete plan for tempest tests?
13:42:43 <sadasu> Internally, I am doing a lot of end-to-end testing with baoli's patched
13:43:00 <beagles> in all seriousness.. I will help with tempest, but I don't know if I am the best one to drive it. Quick review and independent testing of patches, etc.
13:43:13 <sadasu> but I doubt I wil have all that translated into tempest tests in juno-1 or even juno-2
13:43:37 <sadasu> currently,the priority it for me to get my ml2 driver into Juno
13:44:00 <heyongli> sadasu, the test case you mentioned for sriov will be upstream?
13:44:05 <yjiang5> beagles: I think we should first define policy for haredware basesed testing, and then defint the list of integration testing should be added.
13:44:18 <irenab> sadsu: I guess it worth to discuss in the team here to see if can push together, seems that it may be valuable for all
13:44:24 <beagles> yjiang5, that makes sense
13:44:26 <sadasu> tempest tests with more sophisticated testing will be added incrementally, given adding these tests also has its own review process
13:44:55 <yjiang5> sadasu: agree, once we have the list/scenerio should be covered, then we can implement step by step.
13:44:58 <baoli> if it's not a prerequisite to have tempest tests ready in order to commit the code, we can strive to make them for juno-3 or later
13:45:14 <yjiang5> baoli: +1
13:45:21 <sadasu> baoli: +1 that is what I am shooting for
13:45:30 <baoli> cool.
13:45:50 <beagles> baoli, +1 agreed... important to have, but landing a little later is cool
13:45:51 <irenab> baoli: makes sence, just need to make sure that nova side does not require any tempest by itself
13:46:19 <sadasu> I don't want to add more hurdles to any of these commit...we have enough already
13:46:19 <beagles> irenab, yeah we should unit test that to death...
13:46:36 <baoli> I think that we just need to keep that in mind, and keep looking at it.
13:46:45 <irenab> baoli: agree
13:46:47 <sadasu> yes, we have the unit tests and I have end-to end integration tests
13:46:58 <sadasu> its just not part of upstream tempest
13:47:09 <baoli> Shall we continue to the next topic?
13:47:11 <beagles> we should also do a quick check of the existing tempest tests to see if there are any deficiencies in coverage that might be quickly mitigated to catch any regressions we might inadvertantly add
13:47:50 <beagles> translation: try and avoid breaking stuff :)
13:47:51 <baoli> beagles, sure
13:47:51 <irenab> baoli: yes, please
13:47:51 <sadasu> yes, again that can be done in our own testbeds...not pushed upstream right away
13:48:04 <baoli> #topic bugs
13:48:31 <baoli> yjiang5 and heyongli, can you guys take a look at https://review.openstack.org/#/c/82206/Init
13:48:35 <heyongli> first bug link if broken , i add myself to second one and review soon
13:48:56 <baoli> Sorry, I will fix that
13:50:03 <heyongli> this one Abandoned
13:50:08 <heyongli> please recover
13:50:09 <baoli> https://review.openstack.org/#/c/82206/
13:50:23 <baoli> Please take a look at the comments regarding the node id
13:50:51 <heyongli> sure
13:51:18 <baoli> Please let me know what you guys think about the node_id versus host name in the PCI device table.
13:52:22 <baoli> If needed, we need to open a new bug, or address that in 82206
13:52:24 <irenab> we  have less than 10 mins left, I am afraid we wont cover next topics today
13:52:45 <heyongli> sure, baoli
13:52:57 <baoli> ok, to be quick, I will update the next bug soon.
13:53:14 <irenab> I am not sure we should right now enter into new advantures, lest try to land someting first
13:54:18 <irenab> there are few issues that may be worth to resolve as soos as possible, like vnic_type renaming if really needed
13:54:23 <baoli> irenab, we should have them started so that they have a chance to get in in the next release. There are a lot of works
13:54:58 <baoli> given the experience with the current work
13:55:53 <irenab> let's give a priority to issues that may have an impact on current phase
13:56:26 <baoli> irenab, agree. The vnic-type renaming should have high priority, I think.
13:57:17 <baoli> For others, depending on when users would need them
13:57:44 <irenab> baoli: do we have to change names? or once we get into nova api changes
13:58:07 <yjiang5> what's vnit-type renaming?
13:58:30 <irenab> currently vnic_types are normal, direct and macvtap
13:58:47 <irenab> maybe worth to change macvtap to indirect
13:59:07 <irenab> I am not sure its a must, at least networking  guys were OK with naming
13:59:55 <baoli> irenab, yea. So I don't think it has to. We can wait until somebody really cries for the change.
14:00:06 <yjiang5> irenab: thanks for clarification
14:00:19 <baoli> ok, times is up. Let's meet next week.
14:00:23 <baoli> Thanks everyone
14:00:24 <beagles> yjiang5, vnit-type renaming - chuckle - an unintentional pun? because this is a "nit" about naming :)
14:00:25 <irenab> Updating, I will skip next week meeting
14:00:33 <beagles> cheers!
14:00:39 <heyongli> bye!
14:00:42 <irenab> thanks guys
14:00:45 <beagles> irenab, on holiday? have a good trip!
14:00:45 <baoli> irenab, have a good trip to Paris!
14:00:53 <baoli> #endmeeting