16:03:32 <rkukura> #startmeeting networking_ml2
16:03:32 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:35 <openstack> The meeting name has been set to 'networking_ml2'
16:03:45 * pcm_ lurking
16:03:52 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda
16:04:15 <rkukura> #topic Announcements
16:05:13 <trinaths> hi rkukura, please add a topic for 3rd part testing too..
16:05:15 <rkukura> Looks like neutron patches are merging again finally - anyone know more details on whether the general merges are now being approved?
16:05:28 <rkukura> trinaths: OK
16:05:38 <lukego> (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 <trinaths> thank you rkukura
16:06:10 <rkukura> lukego: OK, I think that would be under the Blueprints topic
16:06:31 <lukego> Thanks
16:06:33 <rkukura> Feature proposal deadline is February 18th
16:06:50 <rkukura> All BP implementations for icehouse must be in review by then
16:07:27 <rkukura> Under the Blueprint topic, we can discuss prioritization, etc of the huge list
16:07:53 <rkukura> #topic Action Item Review
16:08:20 <rkukura> The only formal action item was mine, which I've finally completed!
16:09:09 <rkukura> 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 <rkukura> Are there any quick questions or issues regarding that action item?
16:09:30 <trinaths> 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 <matrohon> rkukura : did you already start coding your proposal?
16:10:19 <rkukura> trinaths and everyone else implemening mechanism drivers, please take a careful look at the planned binding changes!
16:10:35 <rkukura> matrohon: About to start
16:10:45 <matrohon> rkukura : great!
16:11:32 <rkukura> Anything else on action items?
16:11:33 <amotoki> 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 <shivharis> thanks for the summary email. will have to read it at least 2 more times.
16:11:58 <trinaths> for pushing the code to upstream, 'mark and kyle' said to go for 3rd party test setup.. I was struck there..
16:13:03 <rkukura> #action rkukura to put result of binding changes email discussion into a wiki or google doc
16:13:43 <rkukura> amotoki: That is the backport issue - lets talk about that under the bugs topic
16:14:01 <amotoki> rkukura: ok.
16:14:36 <rkukura> #topic Blueprints
16:15:16 <rkukura> Since many of the BPs are for new drivers, lets start with trinaths's 3rd party testing question
16:15:41 <trinaths> thank you rkukura...
16:15:54 <trinaths> Was att the basic to 3rd party testing..
16:15:56 <rkukura> trinaths: Can you summarize?
16:16:10 <trinaths> how do to setup the 3rd party testing
16:16:17 <trinaths> what r the requirements
16:16:49 <trinaths> these are the doubts I have..
16:16:53 <banix> http://ci.openstack.org/third_party.html
16:17:16 <Sukhdev> trinaths: it has been discussed a lot on the ML
16:17:40 <HenryG> trinaths: search the ML archives
16:17:50 <trinaths> okay..
16:18:04 <trinaths> how to get the service account..
16:18:11 <HenryG> 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 <shivharis> trinaths: also there is an etherpad for it (i will add the link to it on the wiki)
16:18:33 <irenab> here is a link #https://etherpad.openstack.org/p/multi-node-neutron-tempest
16:18:55 <trinaths> okay.. let me understand the same .. this takes some time.. :)
16:18:56 <banix> trinaths: how to get an account: at http://ci.openstack.org/third_party.html
16:19:07 <amotoki> 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 <Sukhdev> 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 <amotoki> Sukhdev: could you share a link? I can contribute.
16:20:14 <rkukura> trinaths: Will this get you started?
16:20:20 <Sukhdev> amotoki: will do - as soon as I am done
16:20:30 <trinaths> banix the email is a list email
16:20:39 <banix> Jay Pipes has a wiki as well: http://www.joinfu.com
16:20:46 <trinaths> is there any specific email to get the service account
16:21:04 <trinaths> yes rkukura... this give a lot of info..
16:21:14 <trinaths> well i will start tomorrow..
16:21:19 <rkukura> Thanks everyione for the links! I'd like to look at these too.
16:21:21 <banix> trinaths: yes send an email with the info requested to that list
16:21:42 <amotoki> trinaths: we have many malis on servcie account at http://lists.openstack.org/pipermail/openstack-infra/2014-February/thread.html
16:21:53 <trinaths> I have already sent, anix.. they send me the URL for thirdparty.html
16:22:15 <amotoki> let's share our knowledge on Wiki page. etherpad is hard to search.
16:22:32 <trinaths> okay.. thank you.. amotoki.. for the link.. will look into the pages..
16:22:42 <trinaths> true said amotoki..
16:22:46 <shivharis> amotoki: +1
16:22:52 <rkukura> Moving on to BPs in general...
16:23:08 <trinaths> thanks for topic rkukura...
16:23:18 <trinaths> it helped me a lot..
16:23:22 <rkukura> There are 31 ML2 BPs returned by https://blueprints.launchpad.net/neutron?searchtext=ml2
16:24:08 <rkukura> I'd like to clean this up a bit, and make sure priorities and series are correct.
16:24:59 <rkukura> 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 <matrohon> +1
16:25:42 <irenab> agree
16:25:52 <trinaths> 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 <trinaths> 1
16:25:54 <Sukhdev> +1
16:26:12 <sadasu> +1 about 3rd party MD BP priority
16:26:13 <amotoki> Agree with the same priority.
16:26:27 <shivharis> +1
16:26:37 <amotoki> All have "low" is another idea. too many medium BPs make it diffictult to track.
16:26:49 <rkukura> See we need to get the ones that we think can make icehouse approved.
16:27:13 <rkukura> 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 <Sukhdev> 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 <trinaths> sukhdev +1
16:28:58 <irenab> and whicj already has 3rd party testing, start with medium
16:29:07 <irenab> ^which
16:29:24 <rkukura> Sukhdev: +1
16:29:40 <matrohon> +1
16:29:54 <HenryG> sounds good
16:30:00 <shivharis> rkukura: there is a chicken egg prblem in that
16:30:18 <rkukura> shivharis: I was trying to articulate the same thing
16:30:19 <shivharis> if the code is not in the master, you cannot run third party anywasys
16:30:38 <shivharis> sukhdev: -1
16:30:51 <rkukura> Is setting up the jenkins job before the code is merged possible?
16:31:02 <Sukhdev> shivharis: why not?
16:31:06 <banix> rkukura: yes
16:31:26 <shivharis> you need to pull in the branch of a new checkin which should already have your ml2 code in it
16:31:54 <shivharis> hence u cannot test, ifyour ml2 is not in the master to begin with
16:31:57 <Sukhdev> 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 <banix> no you can bring in a patch set under review
16:32:07 <amotoki> we can run tests for proposed commits, so third party testing works.
16:32:30 <banix> no need for it to be merged before testing
16:32:37 <HenryG> In fact, that is how your 3rd party testing should be set up
16:32:49 <rkukura> So the tests would not actually test the new MD until it gets merged, right?
16:33:10 <shivharis> rkukura: correct
16:33:15 <banix> and the merge should happen after third part tests pass
16:33:46 <banix> rkukura: not really
16:33:56 <banix> the test should test the new MD
16:33:58 <rkukura> But should the jenkins job test the patch set(s) proposed to implement the new MD?
16:34:08 <banix> rkukura: yes
16:34:13 <HenryG> exactly
16:34:19 <Sukhdev> rkukura: not really - that is not true
16:34:32 <rkukura> Seems the job would need to run the test only iff the branch contains the MD
16:34:50 <trinaths> sukhdev: jenkins surely tests the code.
16:35:08 <banix> you setup your test so it can get triggered as you submit a patch to your new MD or plugin
16:35:29 <HenryG> ^^^ what banix says
16:35:59 <HenryG> plus, you should trigger on all core code patches too
16:36:05 <amotoki> 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 <Sukhdev> banix, HenryG: correct
16:37:13 <Sukhdev> amotoki: +1
16:37:34 <shivharis> rkukura: your call
16:37:57 <Sukhdev> So, I do not see chicken and egg problem :-)
16:37:58 <rkukura> 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 <Sukhdev> rkukura: +1
16:38:34 <amotoki> +1
16:38:43 <banix> sounds reasonable
16:39:00 <rkukura> Any objections?
16:39:00 <rcurran> +1
16:39:13 <trinaths> +1
16:39:25 <shivharis> So we only test the patchset that has the MD. not CI.
16:39:43 <banix> and all submissions by Jenkins
16:39:50 <lukego> We are struggling with the 3rd party testing, don't know if now is the time to broach that topic...
16:39:54 <jaypipes> hi all, sorry I missed above...
16:39:55 <banix> that is the stated requirement; not sure if it is being enforced
16:40:24 <matrohon> 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 <banix> jaypipes: I referred to your blog wrt testing
16:40:28 <jaypipes> 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 <banix> Gerrit Plugin for us
16:41:04 <irenab> also for us
16:41:10 <rkukura> #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 <HenryG> gerrit, not zuul
16:41:24 <jaypipes> trinaths, Sukhdev? Gerrit Jenkins plugin?
16:41:36 <Sukhdev> jaypipes: I am using jenkins with Gerrit Plugin - you saw my setup in Montreal :-)
16:41:51 <amotoki> at now i am using Gerrit plugin and now testing zuul. It seems easy to migrate from gerrit plugin to zuul.
16:41:53 <jaypipes> Sukhdev: k, I thought so... just wanted to check you had not changed :)
16:42:01 <shivharis> jaypipes: wrote our own from scratch
16:42:02 <jaypipes> amotoki: k, thx.
16:42:07 <jaypipes> shivharis: yikes :)
16:42:16 <trinaths> jaypipes: me need to start the setup..
16:42:25 <shivharis> jaypipes: very flexible
16:42:57 <jaypipes> shivharis: did you use Zuul as a model?
16:43:15 <Sukhdev> jaypipes: using our own setup gives us flexibility of being light weight :-):-)
16:43:16 <shivharis> no, pure python code
16:43:32 <jaypipes> shivharis: so, like Zuul then :)
16:43:41 <shivharis> yup.
16:43:43 <rkukura> matrohon: Good point about multi-node testing of the non-3rd-party drivers.
16:44:20 <jaypipes> 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 <jaypipes> sorry for interrupting, rkukura
16:45:07 <rkukura> Lets put multi-node testing of the non-3rd-party drivers on the agenda for next week
16:45:16 <matrohon> rkukura : ok
16:45:33 <rkukura> proposals/ideas/implementations are welcome
16:45:55 <matrohon> rkukura : we are working on it
16:46:04 <Sukhdev> 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 <rkukura> So we have many BPs that are not introducing new MDs
16:46:10 <matrohon> with multi-node setup with lxc
16:47:04 <rkukura> wondering if there is a need for separate neutron 3rd party testing meeting(s)?
16:47:24 <lukego> I'd like a neutron 3rdty party testing therapy session :)
16:47:33 <banix> rkukura: there have been already a couple of such meetings
16:47:47 <rkukura> banix: Right, wondering if more are needed?
16:47:53 <jaypipes> rkukura: actually, I think there's a need for a cross-project 3rd party testing meeting...
16:47:55 <amotoki> AFAIK it is not scheduled now, but many folks are more interested in it than a month ago.
16:47:57 <Sukhdev> 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 <trinaths> jaypipes: can you share your wiki link about the procedure to setup and 3rd party test setup
16:48:09 <jaypipes> rkukura: since many vendors in cinder, nova, and neutron are struggling with setups.
16:48:33 <jaypipes> trinaths: I will share it when I'm done (hopefully today!)
16:48:51 <banix> I think we need a clear detailed wiki describing how to do this
16:49:01 <amotoki> jaypipes: great
16:49:02 <rkukura> Maybe two different discussions, general 3rd party testing vs. neutron-specific, such as which tempest tests
16:49:08 <lukego> 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 <banix> jaypipes has a good post about using zuul and I think he is going to have another with Gerrit plugin
16:49:36 <trinaths> jaypipes: okay
16:49:48 <trinaths> banix +1
16:49:51 <rkukura> lukego: You might appreciate it more when my merge breaks your driver;-)
16:50:10 <shivharis> rkukura: thanks for that!
16:50:11 <matrohon> i'd like to see this BP at a higer level :
16:50:14 <matrohon> https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info
16:50:16 <Sukhdev> 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 <lukego> rkukura: breaks integration tests without breaking unit tests?
16:50:47 <rkukura> sorry, snow plow was stuck in our driveway
16:51:45 <banix> Beautiful Northeast. Digging out in NYC as well :)
16:51:46 <lukego> 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 <Sukhdev> rkukura: Can I bring up an issue that I am seeing with devstack while doing 3rd party testing with ML2 Plugin?
16:53:38 <rkukura> 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 <rkukura> Sukhdev: sure
16:54:51 <amotoki> 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 <Sukhdev> 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 <rkukura> We've got 5 minutes left.
16:55:43 <matrohon> 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 <rkukura> Sukhdev: Is there a bug for that?
16:56:12 <Sukhdev> rkukura: do not know
16:56:36 <shivharis> sukhdev: file a bug
16:57:00 <rkukura> matrohon my question is whether MD should control the RPC response, and get the info fro the TD if needed
16:57:51 <rkukura> 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 <rkukura> Next week we can check status based on priority and make sure we are on track for feature proposal freeze
16:58:53 <trinaths> okay
16:58:54 <matrohon> rkukura : ok, that could be a way of implementing this!
16:59:27 <Sukhdev> rkukura: sounds good
17:00:08 <HenryG> matrohon: can you keep me and asomya in the loop on that?
17:00:20 <rkukura> 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 <rkukura> #topic open discussion
17:00:42 <asadoughi> 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 <rkukura> asadoughi: Great! Thanks for the update!
17:01:21 <rkukura> anything else?
17:01:29 <rkukura> #endmeeting