16:03:32 #startmeeting networking_ml2 16:03:32 Meeting started Wed Feb 5 16:03:32 2014 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:03:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:35 The meeting name has been set to 'networking_ml2' 16:03:45 * pcm_ lurking 16:03:52 #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda 16:04:15 #topic Announcements 16:05:13 hi rkukura, please add a topic for 3rd part testing too.. 16:05:15 Looks like neutron patches are merging again finally - anyone know more details on whether the general merges are now being approved? 16:05:28 trinaths: OK 16:05:38 (I'd like to briefly review status of the Tail-f md if that's possible. I'm not sure if I should have added that on the agenda already?) 16:05:45 thank you rkukura 16:06:10 lukego: OK, I think that would be under the Blueprints topic 16:06:31 Thanks 16:06:33 Feature proposal deadline is February 18th 16:06:50 All BP implementations for icehouse must be in review by then 16:07:27 Under the Blueprint topic, we can discuss prioritization, etc of the huge list 16:07:53 #topic Action Item Review 16:08:20 The only formal action item was mine, which I've finally completed! 16:09:09 Looks like good discussion on the proposed port binding changes is under way on openstack-dev, so we don't need to spend too much time on it here 16:09:29 Are there any quick questions or issues regarding that action item? 16:09:30 i'm currently doing the improvement to the code base of fsl-sdn-os-mech-driver. this weekend will push to the git.. 16:10:13 rkukura : did you already start coding your proposal? 16:10:19 trinaths and everyone else implemening mechanism drivers, please take a careful look at the planned binding changes! 16:10:35 matrohon: About to start 16:10:45 rkukura : great! 16:11:32 Anything else on action items? 16:11:33 regarding havana db migration fix on ML2, there is a post on dev ML, but there seems to be no good solution so far. 16:11:36 thanks for the summary email. will have to read it at least 2 more times. 16:11:58 for pushing the code to upstream, 'mark and kyle' said to go for 3rd party test setup.. I was struck there.. 16:13:03 #action rkukura to put result of binding changes email discussion into a wiki or google doc 16:13:43 amotoki: That is the backport issue - lets talk about that under the bugs topic 16:14:01 rkukura: ok. 16:14:36 #topic Blueprints 16:15:16 Since many of the BPs are for new drivers, lets start with trinaths's 3rd party testing question 16:15:41 thank you rkukura... 16:15:54 Was att the basic to 3rd party testing.. 16:15:56 trinaths: Can you summarize? 16:16:10 how do to setup the 3rd party testing 16:16:17 what r the requirements 16:16:49 these are the doubts I have.. 16:16:53 http://ci.openstack.org/third_party.html 16:17:16 trinaths: it has been discussed a lot on the ML 16:17:40 trinaths: search the ML archives 16:17:50 okay.. 16:18:04 how to get the service account.. 16:18:11 trinaths: also, here is a good read to understand the underlying system: #link http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ 16:18:15 trinaths: also there is an etherpad for it (i will add the link to it on the wiki) 16:18:33 here is a link #https://etherpad.openstack.org/p/multi-node-neutron-tempest 16:18:55 okay.. let me understand the same .. this takes some time.. :) 16:18:56 trinaths: how to get an account: at http://ci.openstack.org/third_party.html 16:19:07 trinaths: about service account, please send a mail to openstack-infra with information described in http://ci.openstack.org/third_party.html 16:19:11 trinaths: I am trying to put together wiki on third partry testing - have not had much time to finish it - will publish next week 16:19:43 Sukhdev: could you share a link? I can contribute. 16:20:14 trinaths: Will this get you started? 16:20:20 amotoki: will do - as soon as I am done 16:20:30 banix the email is a list email 16:20:39 Jay Pipes has a wiki as well: http://www.joinfu.com 16:20:46 is there any specific email to get the service account 16:21:04 yes rkukura... this give a lot of info.. 16:21:14 well i will start tomorrow.. 16:21:19 Thanks everyione for the links! I'd like to look at these too. 16:21:21 trinaths: yes send an email with the info requested to that list 16:21:42 trinaths: we have many malis on servcie account at http://lists.openstack.org/pipermail/openstack-infra/2014-February/thread.html 16:21:53 I have already sent, anix.. they send me the URL for thirdparty.html 16:22:15 let's share our knowledge on Wiki page. etherpad is hard to search. 16:22:32 okay.. thank you.. amotoki.. for the link.. will look into the pages.. 16:22:42 true said amotoki.. 16:22:46 amotoki: +1 16:22:52 Moving on to BPs in general... 16:23:08 thanks for topic rkukura... 16:23:18 it helped me a lot.. 16:23:22 There are 31 ML2 BPs returned by https://blueprints.launchpad.net/neutron?searchtext=ml2 16:24:08 I'd like to clean this up a bit, and make sure priorities and series are correct. 16:24:59 Seems only fair to me that all 3rd party MD BPs should be at the same priority, probably either medium. Does that make sense? 16:25:31 +1 16:25:42 agree 16:25:52 1 [from my side, 'fsl-sdn-os-mech-driver' BP, with LOW priority, completed the code and waiting for 3rd party test setup... ] 16:25:54 1 16:25:54 +1 16:26:12 +1 about 3rd party MD BP priority 16:26:13 Agree with the same priority. 16:26:27 +1 16:26:37 All have "low" is another idea. too many medium BPs make it diffictult to track. 16:26:49 See we need to get the ones that we think can make icehouse approved. 16:27:13 I'm fine with either medium or low for these, but don't want them to fall below the radar for reviewers. 16:27:52 I like amotoki's idea - start with low priority for all and as they meet the third part requirement- bump up the priority to medium 16:28:42 sukhdev +1 16:28:58 and whicj already has 3rd party testing, start with medium 16:29:07 ^which 16:29:24 Sukhdev: +1 16:29:40 +1 16:29:54 sounds good 16:30:00 rkukura: there is a chicken egg prblem in that 16:30:18 shivharis: I was trying to articulate the same thing 16:30:19 if the code is not in the master, you cannot run third party anywasys 16:30:38 sukhdev: -1 16:30:51 Is setting up the jenkins job before the code is merged possible? 16:31:02 shivharis: why not? 16:31:06 rkukura: yes 16:31:26 you need to pull in the branch of a new checkin which should already have your ml2 code in it 16:31:54 hence u cannot test, ifyour ml2 is not in the master to begin with 16:31:57 when you run third party testing, you are applying patches anyways why can you apply your own patch before kicking the testing? 16:31:58 no you can bring in a patch set under review 16:32:07 we can run tests for proposed commits, so third party testing works. 16:32:30 no need for it to be merged before testing 16:32:37 In fact, that is how your 3rd party testing should be set up 16:32:49 So the tests would not actually test the new MD until it gets merged, right? 16:33:10 rkukura: correct 16:33:15 and the merge should happen after third part tests pass 16:33:46 rkukura: not really 16:33:56 the test should test the new MD 16:33:58 But should the jenkins job test the patch set(s) proposed to implement the new MD? 16:34:08 rkukura: yes 16:34:13 exactly 16:34:19 rkukura: not really - that is not true 16:34:32 Seems the job would need to run the test only iff the branch contains the MD 16:34:50 sukhdev: jenkins surely tests the code. 16:35:08 you setup your test so it can get triggered as you submit a patch to your new MD or plugin 16:35:29 ^^^ what banix says 16:35:59 plus, you should trigger on all core code patches too 16:36:05 we setup third party testing for proposed patches. but it really helps us to debug our own plugins/drivers against the master branch. 16:36:24 banix, HenryG: correct 16:37:13 amotoki: +1 16:37:34 rkukura: your call 16:37:57 So, I do not see chicken and egg problem :-) 16:37:58 So are we agreeing that BPs for new MDs should be low priority until they have the jenkins job in place that will test the patch sets submitted to implement the MD, then they should get bumped to medium? 16:38:28 rkukura: +1 16:38:34 +1 16:38:43 sounds reasonable 16:39:00 Any objections? 16:39:00 +1 16:39:13 +1 16:39:25 So we only test the patchset that has the MD. not CI. 16:39:43 and all submissions by Jenkins 16:39:50 We are struggling with the 3rd party testing, don't know if now is the time to broach that topic... 16:39:54 hi all, sorry I missed above... 16:39:55 that is the stated requirement; not sure if it is being enforced 16:40:24 what about opensource MD (l2-pop, ovs, lb). like 3rd party, They need multi-node setup which is not available in openstack-infra by now 16:40:28 jaypipes: I referred to your blog wrt testing 16:40:28 was wondering what the percentage of you all that are using Jenkins Gerrit plugin as your triggering agent vs. Zuul is. Can I get a show of hands of how many use the Jenkins Gerrit plugin please? 16:40:47 Gerrit Plugin for us 16:41:04 also for us 16:41:10 #action: rkukura to change priorities of all new 3rd party MD BPs to low if they do not already have jenkins job in place. 16:41:20 gerrit, not zuul 16:41:24 trinaths, Sukhdev? Gerrit Jenkins plugin? 16:41:36 jaypipes: I am using jenkins with Gerrit Plugin - you saw my setup in Montreal :-) 16:41:51 at now i am using Gerrit plugin and now testing zuul. It seems easy to migrate from gerrit plugin to zuul. 16:41:53 Sukhdev: k, I thought so... just wanted to check you had not changed :) 16:42:01 jaypipes: wrote our own from scratch 16:42:02 amotoki: k, thx. 16:42:07 shivharis: yikes :) 16:42:16 jaypipes: me need to start the setup.. 16:42:25 jaypipes: very flexible 16:42:57 shivharis: did you use Zuul as a model? 16:43:15 jaypipes: using our own setup gives us flexibility of being light weight :-):-) 16:43:16 no, pure python code 16:43:32 shivharis: so, like Zuul then :) 16:43:41 yup. 16:43:43 matrohon: Good point about multi-node testing of the non-3rd-party drivers. 16:44:20 kk, thx all. I should have the puppet modules in http://github.com/jaypipes/os-ext-testing setting up Zuul sometime today (replacing the use of the Gerrit Jenkins plugin) 16:44:46 sorry for interrupting, rkukura 16:45:07 Lets put multi-node testing of the non-3rd-party drivers on the agenda for next week 16:45:16 rkukura : ok 16:45:33 proposals/ideas/implementations are welcome 16:45:55 rkukura : we are working on it 16:46:04 jaypipes: The real issue I am faced with (I am sure others are hitting or will hit) is the kind of tests to run and what services to enable - as opposed to the framework itself 16:46:09 So we have many BPs that are not introducing new MDs 16:46:10 with multi-node setup with lxc 16:47:04 wondering if there is a need for separate neutron 3rd party testing meeting(s)? 16:47:24 I'd like a neutron 3rdty party testing therapy session :) 16:47:33 rkukura: there have been already a couple of such meetings 16:47:47 banix: Right, wondering if more are needed? 16:47:53 rkukura: actually, I think there's a need for a cross-project 3rd party testing meeting... 16:47:55 AFAIK it is not scheduled now, but many folks are more interested in it than a month ago. 16:47:57 rkukura: it may be a good idea - but, agenda should not focus on CI - but, on what to test, what servvices should be enabled when running devstack 16:48:08 jaypipes: can you share your wiki link about the procedure to setup and 3rd party test setup 16:48:09 rkukura: since many vendors in cinder, nova, and neutron are struggling with setups. 16:48:33 trinaths: I will share it when I'm done (hopefully today!) 16:48:51 I think we need a clear detailed wiki describing how to do this 16:49:01 jaypipes: great 16:49:02 Maybe two different discussions, general 3rd party testing vs. neutron-specific, such as which tempest tests 16:49:08 3rd party testing doesn't bring us much benefit, because our driver is so simple and we're happy with the unit tests, but it has got us into a fight with #openstack-infra, and we feel the threat of "deprecation". #sadface 16:49:36 jaypipes has a good post about using zuul and I think he is going to have another with Gerrit plugin 16:49:36 jaypipes: okay 16:49:48 banix +1 16:49:51 lukego: You might appreciate it more when my merge breaks your driver;-) 16:50:10 rkukura: thanks for that! 16:50:11 i'd like to see this BP at a higer level : 16:50:14 https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info 16:50:16 rkukura: yes, we need to understand what to test from Neutron point of view - I spoke with Mark when in Montreal - he wants full gate testing, which requires many services to be enabled 16:50:32 rkukura: breaks integration tests without breaking unit tests? 16:50:47 sorry, snow plow was stuck in our driveway 16:51:45 Beautiful Northeast. Digging out in NYC as well :) 16:51:46 rkukura: all the OpenStack ever sees from our 3rd party system is "200 OK".. the logic is so basic that nothing more is needed 16:53:13 rkukura: Can I bring up an issue that I am seeing with devstack while doing 3rd party testing with ML2 Plugin? 16:53:38 matrohon: That's the one that lets type drivers put info the get_device_details response. Seems mechanism drivers need to do this as well. How about kicking off an email discussion on this? 16:53:44 Sukhdev: sure 16:54:51 Apart from third party testing, another concern towards I-3 is how to coordinate changes in ML2 main code (such as binding issues) and MD patches. The change in main code requires to rebase and refactor all MD patches. 16:55:09 when we run devstack, neutron invokes neutron-debug probe-create (which makes create_port_pre/post call) The port context/port structure fields are not set correctly, and causes the ML2 drivers to fail 16:55:21 We've got 5 minutes left. 16:55:43 rkukura : this is not this one, but asomya told us that he was waiting for this BP to merge besore proposing its patch to allow MD to add info in get_device_details 16:55:51 Sukhdev: Is there a bug for that? 16:56:12 rkukura: do not know 16:56:36 sukhdev: file a bug 16:57:00 matrohon my question is whether MD should control the RPC response, and get the info fro the TD if needed 16:57:51 I'll try to ping owners of all the BPs in the next couple days and get priorities and approvals sorted out. 16:58:34 Next week we can check status based on priority and make sure we are on track for feature proposal freeze 16:58:53 okay 16:58:54 rkukura : ok, that could be a way of implementing this! 16:59:27 rkukura: sounds good 17:00:08 matrohon: can you keep me and asomya in the loop on that? 17:00:20 We didn't cover bugs today, but the VIF security issue needs resolution. See http://lists.openstack.org/pipermail/openstack-dev/2014-January/026060.html 17:00:34 #topic open discussion 17:00:42 ovs-firewall-driver update: should be pushing out code for a firewall driver review before the next meeting, making minor adjustments to existing assign vlans review as well to accomodate that 17:01:15 asadoughi: Great! Thanks for the update! 17:01:21 anything else? 17:01:29 #endmeeting