14:00:18 <yushiro> #startmeeting fwaas
14:00:19 <openstack> Meeting started Tue Jun 13 14:00:18 2017 UTC and is due to finish in 60 minutes.  The chair is yushiro. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:24 <openstack> The meeting name has been set to 'fwaas'
14:00:41 <yushiro> #chair SridarK xgerman_ yushiro njohnston_
14:00:41 <openstack> Current chairs: SridarK njohnston_ xgerman_ yushiro
14:00:45 <SridarK> hi all
14:00:57 <reedip_> \o/
14:00:59 <xgerman_> o/
14:01:01 <hoangcx_> o/
14:01:06 <SarathMekala> hi all O/
14:01:14 <yushiro> Hi. Let's get start.  Today is my turn :)
14:01:18 <vks1> hi all
14:01:22 <yushiro> #topic Pike
14:01:50 <yushiro> 1st:  L2 support
14:02:09 <yushiro> Pleaset let me announce about l2-agent patch.
14:02:30 <yushiro> #link https://review.openstack.org/#/c/323971/
14:03:05 <yushiro> I just updated l2-agent patch.  Now adding more UTs.
14:04:01 <reedip_> yushiro: put -1 on the workflow instead of the review.. confuses fellow reviewers :)
14:04:32 <yushiro> 1 remaining item is a comment from annp about handle_port calls twice..
14:04:55 <yushiro> reedip_, OK.
14:05:29 <yushiro> That's all my side.
14:05:50 <yushiro> SarathMekala, is chandan off today?
14:06:20 <SarathMekala> yushiro, he is attending another office meeting
14:06:37 <SarathMekala> he wont be able to join today
14:06:51 <yushiro> SarathMekala, Oh, OK.  I see :)
14:07:37 <yushiro> Regarding default FWG, now addig UT phase.  I don't change any logic.
14:08:27 <yushiro> Regarding OVS l2 driver, avoiding race condition for handle_port() is now pending.
14:08:30 <reedip_> i think vks1 had also the point of whether we need the default FWG to configure it
14:08:49 <reedip_> sorry , I mean if there a way to turn it off
14:09:09 <xgerman_> yep, we were talking about that
14:09:20 <yushiro> ah, yes. I remember that.
14:09:44 <reedip_> yushiro : point is that if we upgrade fwaas , it is possible that we have a default fw for the user
14:10:11 <reedip_> if (a) we already have users for v2 or(b) we provide migration support from v1 to v2
14:10:16 <SridarK> yushiro: reg the race condition for handle_port()  lets sync with chandanc this week
14:10:51 <yushiro> SridarK, Correct.  let's do that.
14:11:48 <yushiro> reedip_, in Boston summit, we've got an opinion to provide migration script from v1 to v2.
14:12:27 <vks1> yushiro: that's worth doing it
14:12:30 <vks1> :)
14:12:48 <reedip_> yushiro : I know, there is a bug/rfe for the same in neutron with the fwaas tag
14:12:48 <SridarK> +1
14:13:15 <reedip_> yushiro : and if we do it , I think what vks1 suggested would be true ( User will have a default FWG which he didnt intend to have )
14:13:21 <SridarK> we need to spin some cycles to investigate that - we will need to make some assumptions as this migration cannot be perfect
14:13:30 <xgerman_> +1
14:14:04 <reedip_> SridarK : exactly .... it wont be a small thing , and we need to make sure what versions are supported
14:14:10 <SridarK> on migration - since there was no L2 support in v1 - we could just do migration for L3
14:14:13 <yushiro> SridarK, xgerman_ +1.  In order to provide migration script, we need to take more cycle.
14:14:19 <reedip_> I mean whether we target migration from Ocata/Newton/Mitaka etc
14:14:49 <xgerman_> yeah, only L3 needs to be migrated
14:15:09 <SridarK> so we could get away without any default fwg implications
14:15:17 <SridarK> since we dont really do this for L3
14:15:17 <xgerman_> but if somebody likes to switch on DFWG should we have some way of slabbing it on all hosts?
14:15:57 <xgerman_> as soon as we offer a switch we need to have code to add/remove?
14:16:43 <reedip_> xgerman_ , yushiro : how about keeping it as an extension to fwaas ?
14:16:55 <reedip_> I know its late , but just asking .
14:18:03 <SridarK> reedip_: hmm, ext attribute may not be a perfect fit
14:18:22 <yushiro> reedip_, Sorry.  You mean l2 support should be changed as an extention ?  Currently, l2 feature is one of extension.
14:18:23 <SridarK> since we are just talking abt an enable/disable on an existing ext
14:18:38 <xgerman_> yeah, I also like to encourage adoption…
14:19:05 <xgerman_> maybe we should be bold and offer migration of SG->FWG ;-)
14:19:21 <reedip_> SridarK , xgerman_ : ok, extension is out of the picture.But can we configure it in fwaas.conf ?
14:19:28 <SridarK> xgerman_: :-)
14:19:35 <yushiro> Current impl,  we chan choose to use l2 feature + default fwg  by adding  'extentions = fwaas_v2'  into /etc/neutron/plugins/ml2/ml2_conf.ini
14:19:37 <reedip_> I mean set it to true by default and make it false in User wants it ?
14:19:58 <yushiro> If we don't specify it, fwaas v2 can work only L3.
14:20:16 <SridarK> reedip_: that is certainly an option, L2 as such is as pointed to by yushiro above
14:20:28 <reedip_> yushiro : you mean L2 is coupled with Default FWG ?
14:20:42 <reedip_> yushiro : do we need such coupling ?
14:21:00 <xgerman_> probably not
14:21:30 <yushiro> reedip_, Currently yes.  A set of L2 feature.  We cannot switch on/off for only default fwg feature.
14:21:32 <reedip_> xgerman_ : as per yushiro , its not :)
14:21:59 <reedip_> yushiro : should we not keep them completely separate ?
14:23:10 <yushiro> I agree with to have an option to on/off default fwg feature.  However, currently we need to 'WHEN' it will be implemented.
14:23:29 <yushiro> reedip_, and vks1 want to have 'this cycle', right?
14:23:52 <reedip_> yushiro : I would like this to be in the plans right now , even a ToDo would work .
14:23:53 <xgerman_> that’s what I am sensing but I am ok with having that later
14:24:17 <reedip_> I would prefer that the code be least modified when we put a switch on it
14:24:34 <SridarK> yes we can have it in the plans, right now IMHO we should get the basic stuff working first
14:24:41 <xgerman_> +1
14:24:54 <yushiro> +1
14:25:19 <SridarK> and in some sense we need to look like SG
14:26:07 <reedip_> +11
14:27:14 <yushiro> OK, I'll research to handle on/off feature for default fwg.
14:28:07 <xgerman_> thanks
14:28:10 <reedip_> yushiro : let me know , I can also help out if possible :)
14:28:32 <yushiro> reedip_,  of course :) I trust you.
14:28:36 <reedip_> :)
14:28:43 <vks1> yushiro: not me ??? ;)
14:28:48 <reedip_> hahahahaha
14:28:52 <xgerman_> lol
14:28:54 <reedip_> I trust you vks1
14:28:56 <yushiro> vks1, hahaha!  of course you :)
14:29:06 <reedip_> so by extension yushiro does too :D
14:29:21 <yushiro> vks1, please give your opinion on gerrit or IRC or e-mail.
14:29:22 <SridarK> relationship counseling ;-)
14:29:30 <vks1> hahaha
14:29:35 <reedip_> I dont need it right now :D
14:29:38 <vks1> reedip sure
14:29:45 <SridarK> :-)
14:29:48 <yushiro> Ok, is there anything about L2-support/default fwg?
14:30:21 <yushiro> OK, next.
14:30:27 <yushiro> Neutron-lib adoption: https://review.openstack.org/#/c/421472/   /  https://review.openstack.org/456511
14:30:35 <reedip_> Thats a big one yushiro :(
14:30:57 <reedip_> Well the problem is that midonet crashed
14:31:14 <reedip_> because of certain changes in neutron-lib adoption
14:31:32 <xgerman_> mmh, the other vendor drivers still work?
14:31:43 <reedip_> Right now there are 2 options , one suggested by Yamamoto to revert the changes of fwaas
14:32:23 <yushiro> reedip_ and I were researching today about networking-midonet broken...
14:32:24 <reedip_> and the second option from my end is to modify some of the changes in fwaas while also modify midonet to accept the changes in fwaas
14:32:55 <reedip_> xgerman_ : didnt find any notification about other vendor drivers.
14:33:40 <xgerman_> I hate to break a specific vendor but we also need to move on… SridarK_?
14:33:50 <reedip_> xgerman_ pulling up codesearch.openstack.org to check the projects which are affected by fwaas
14:34:17 <reedip_> xgerman: yushiro and I agree pointed out that the changes which we made are actually required for the neutron stadium
14:35:53 <SridarK> xgerman_: agreed - we may need some changes from their side too
14:36:00 <yushiro> xgerman_, SridarK Currently, networking-midonet has a logging feature for fwaas v1 and directly refers fwaas extension(alias).  In addition, networking-midonet doesn't have CI for tracking fwaas patches.  That's why it is not easy to notice.
14:36:59 <reedip_> xgerman_ SridarK , the Logging feature is in neutron-lib
14:37:03 <SridarK> yushiro: i think it would be best to work with yamamoto for a mutually least impact solution
14:37:06 <reedip_> so it causes addition issues
14:37:32 <yushiro> SridarK, +++++++1 Yes, it is the best way to overcome this situation.
14:37:53 <yushiro> reedip_, Have you already discussed with yamamoto about that today?
14:37:56 <SridarK> so if midonet also adopts neutron-lib changes shouldnt tht work ?
14:38:11 <reedip_> SridarK , from neutron perspective, I like boden's approach where in the consumers change their code as per the modification of the source project
14:38:36 <SridarK> reedip_: which is what most of us have been doing
14:38:38 <reedip_> yushiro , xgerman_ : I discussed with yamamoto san
14:39:17 <reedip_> SridarK, yushiro, xgerman_ : The problem is , if I execute a bulk of the test cases, probably 10/30 fail
14:39:34 <reedip_> but when I executed each of the failedd 10 test cases individually , they passed
14:39:58 <xgerman_> that looks like a bug…
14:40:20 <reedip_> so I think there is some other issue, probably that as the test cases are run in parallel during tox, certain test cases pass, but leave out some env attributes, which cause the other test cases to fail
14:40:24 <hoangcx_> reedip_: Have you check the test with serial option?
14:40:48 <reedip_> hoangcx_ : no , and I dont think the gate tests are run in serial, are they ?????
14:41:34 <hoangcx_> reedip_: Indeed. But that is the way to make sure the problem as you pointed out rather than running each individual case by hand
14:42:30 <SridarK> reedip_: sigh, could be some kind of race - these are painful
14:43:05 <yushiro> race condition regarding multi process/thread or ....
14:43:09 <reedip_> hoangcx_ let me know how to run them serially in tox ... SridarK , I am working on it with yushiro san. Hopefully we will get a response soon
14:43:30 <hoangcx_> reedip_: OK, I will guide you later
14:43:31 <yushiro> hoangcx_, you know how to run with single process, right? :)
14:43:48 <yushiro> OK, perfect
14:43:49 <hoangcx_> yushiro: yeah ;-)
14:44:27 <yushiro> reedip_, let me sync up about discussion with yamamoto later.
14:44:39 <hoangcx_> reedip_: If that is the case, "sigh" with SridarK too
14:45:02 <reedip_> yushiro : lets discuss it on #openstack-fwaas so that if someone is offline, they can catch up from the logs :)
14:45:31 <yushiro> reedip_, yup
14:45:33 <yushiro> OK, next.  today, chandan is off and we'll skip ovs firewall driver section.
14:45:48 <yushiro> #Horizon support
14:46:10 <sarathmekala_> I need some help with the formalities
14:46:10 <yushiro> sarathmekala_, Please go ahead :)
14:46:33 <sarathmekala_> I have the code ready and am waiting for amotoki to create a branch so that both of us can check into it
14:46:47 <sarathmekala_> he sent across a mail to the mailerlist, but i dont see any progress
14:47:22 <sarathmekala_> I need some pointers on how to proceed further
14:47:23 <xgerman_> mmh, you need a new repo?
14:47:28 <sarathmekala_> xgerman_, yes
14:47:40 <xgerman_> you just make a patch to infra
14:47:56 <yushiro> sarathmekala_, OK, I'll ping him tomorrow about that during  Japan time zone.
14:48:07 <sarathmekala_> yushiro, thanks
14:48:17 <sarathmekala_> xgerman_, do you have any pointers on how to go about that
14:48:19 <sarathmekala_> any links
14:48:22 <xgerman_> https://review.openstack.org/#/c/446082/
14:48:46 <sarathmekala_> cool.. thanks
14:48:54 <yushiro> sarathmekala_, xgerman_ correct.  openstack-infra manages any repos.
14:49:05 <xgerman_> that;s the patch I was looking for: https://review.openstack.org/#/c/444057/
14:49:10 <sarathmekala_> I will wait for a day for yushiro to sync up with amotoki..
14:49:24 <xgerman_> look how ovtavia-dashboard was done
14:49:32 <yushiro> sarathmekala_, Yes, it's better because he've already posted some patches into openstack-infra.
14:49:35 <amotoki> sarathmekala_: sorry for late...
14:49:41 <sarathmekala_> by thursday I will check in the code an initiate a review
14:49:49 <yushiro> amotoki, wow, you're here :)
14:49:58 <sarathmekala_> hi amotoki
14:50:42 <sarathmekala_> will you go ahead and create the branch?
14:50:49 <amotoki> some updates from me: i created a launchpad project neutron-fwaas-dashboard and sets up bugs and related thing.
14:51:04 <amotoki> sarathmekala_: what do you mean by "create the branch"?
14:51:21 <reedip_> amotoki : I think the repo should be enough
14:51:22 <xgerman_> he was lookign for a repo
14:51:34 <amotoki> sarathmekala_: i think we are talking about creating a new repo, spilit fwaas v1 from horizon adn then add fwaasv2 panel to it.
14:51:37 <reedip_> sarathmekala : I think you can just commit the code in that repo and start  :)
14:51:38 <sarathmekala_> sorry.. i meant repo
14:51:56 <amotoki> sure. thanks for clarifying.
14:52:04 <xgerman_> not sure if we need an extra LP for dashboard — SridarK_ something else we need to groom for bugs?
14:52:12 <amotoki> perhaps i can push project-config change tomorrow.
14:52:39 <yushiro> amotoki, great.
14:52:48 <sarathmekala_> +1, thanks
14:53:07 <amotoki> xgerman_: in the thread in the dev list, I got several responses +1 for separate launchpad project.
14:53:26 <yushiro> OK, anything else about Horizon, sarathmekala_ ?
14:53:29 <amotoki> i think it is because filing dashboard bugs to neutron is a bit tricky
14:53:38 <sarathmekala_> nothing more..
14:53:48 <sarathmekala_> I will check in the code and open it for review
14:53:51 <amotoki> go ahead
14:53:59 <yushiro> sarathmekala_, amotoki  OK. thanks.
14:54:26 <reedip_> sarathmekala_ do add us in the review :P
14:54:34 <yushiro> 5 minutes left..
14:54:35 <yushiro> #topic Stadium Compliance
14:54:43 <sarathmekala_> sure reedip_ :)
14:55:09 <xgerman_> amotoki I filter by [FWaaS] so missed that post
14:55:27 <amotoki> xgerman_: I see
14:55:43 <yushiro> reedip_, It is now stopping due to neutron-lib migration with you great punch list
14:56:12 <reedip_> yushiro : I know :(
14:56:22 <reedip_> I am checking midonet tests right now
14:56:29 <reedip_> I will push it by this weekend
14:56:36 <yushiro> reedip_, cool. Thanks.
14:56:40 <yushiro> #topic Open Discussion
14:57:08 <yushiro> Just an announce.  As you know, CFP for sydney summit is now opened.
14:57:28 <reedip_> yushiro : yes ... are we planning to provide any paper for FWaaS ?
14:58:22 <yushiro> reedip_, I just want to ask for them :)  So, it is better to provide some papers.
14:58:39 <SridarK> i think a lot depends on where we are with L2
14:58:56 <SridarK> also we need to show something different from what was done at Boston
14:59:05 <yushiro> SridarK, +1
14:59:05 <SridarK> meaning more additions
14:59:12 <xgerman_> yep
14:59:19 <reedip_> yushiro , hoangcx_ , SridarK , xgerman_ : Good News ( ?? )  Midonet test pass when executed serially but ( badnews ) fail while running parallely
14:59:27 <xgerman_> but if someone has travel $$$ we should propose something
14:59:52 <yushiro> xgerman_, yeeeees.. That's a big problem for budget fee..
14:59:58 <SridarK> yes indeed
15:00:03 <SridarK> 1 min warning
15:00:06 <yushiro> oh,  we're time
15:00:16 <yushiro> #endmeeting