14:00:50 <yushiro> #startmeeting fwaas
14:00:51 <openstack> Meeting started Tue May 30 14:00:50 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:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:56 <openstack> The meeting name has been set to 'fwaas'
14:01:02 <SridarK> Hi All
14:01:05 <yushiro> #chair SridarK yushiro xgerman njohnston
14:01:06 <openstack> Warning: Nick not in channel: njohnston
14:01:07 <openstack> Current chairs: SridarK njohnston xgerman yushiro
14:01:10 <vks1> hi all
14:01:16 <xgerman> o/
14:01:24 <SridarK> Lets get started
14:01:37 <hoangcx> hi
14:02:04 <SridarK> yushiro: i think today is my turn to run the mtg ?
14:02:17 <yushiro> SridarK, yes, it's your turn :)
14:02:37 <SridarK> #topic FWaas v2
14:02:49 <chandanc> Sorry i am late
14:03:02 <SridarK> lets review state quickly
14:03:17 <SridarK> chandanc: no worries , just in time
14:03:38 <SridarK> chandanc: pls go ahead
14:04:12 <chandanc> I investigated the race condition issue, and we have basically 2 solution
14:04:28 <chandanc> I hope you got a chance to lok at the mail
14:04:33 <yushiro> chandanc, Yes, thanks for your research and e-mail.
14:05:14 <chandanc> We can either patch the ovs agent or a quicker way to unblock may be to directly fetch the vlan tag from localvman manager
14:05:23 <chandanc> *localvlan
14:06:59 <chandanc> i think this can be done in the agent extension ? what do you think ?
14:07:13 <SridarK> chandanc: how do we ensure that the vlan has been configured
14:08:11 <chandanc> the agent extensions are called after the vlan allocation is done, i think the delay is in ovs getting configured
14:08:18 <SridarK> do u mean that on the agent side we are guaranteed but only w.r.t ovsdb is a problem ?
14:08:59 <chandanc> ya that is what i could see in the ovs agent code
14:09:18 <SridarK> chandanc: ok grt, in that case things could be simpler
14:09:34 <chandanc> ya, 1 sec let me find the code link
14:09:51 <yushiro> chandanc, thanks. it'll be helpful.
14:10:10 <chandanc> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1525
14:11:27 <chandanc> please let me know is this approach is acceptable
14:11:46 <chandanc> Also any comments on the driver patch will also be helpfil
14:12:09 <chandanc> i saw a code review -1 from paddu, i will reachout to him for discussion
14:12:36 <SridarK> chandanc: makes sense
14:13:02 <SridarK> chandanc: do u think u can pursue this week so we can get to some closure
14:13:25 <SridarK> we may need to do some more testing along this path as well
14:13:34 <chandanc> Sure, i can push for it,
14:13:52 <SridarK> off the top this looks reasonable to me
14:14:10 <chandanc> Do you have any comments on the patch, as per our discussion we are going to hold on the changes for co-existance right ?
14:14:25 <SridarK> chandanc: yes agreed
14:14:33 <yushiro> OK.
14:14:45 <SridarK> lets get the basic use case functioning b4 we head to co-existence
14:15:16 <SridarK> ok good chandanc anything else u would like to discuss ?
14:15:16 <chandanc> Ok then, please let me know if you need any more changes, i will start a integration test with l2 agent
14:15:27 <chandanc> no that should be all
14:15:36 <SridarK> chandanc: ok good lets move on
14:15:54 <SridarK> yushiro: would u like to discuss DFWG and other changes
14:16:59 <yushiro> SridarK, Regarding DEF FWG, I didn't change except nit fix.  Ah, I'd like to give some opinion of firewall_rule.
14:17:18 <SridarK> yushiro: ok pls go ahead
14:17:19 <yushiro> #link https://review.openstack.org/#/c/425769/
14:17:41 <yushiro> https://review.openstack.org/#/c/425769/17/neutron_fwaas/db/firewall/v2/firewall_db_v2.py
14:17:51 <yushiro> Plz check Line#345~~
14:18:46 <yushiro> Now there are IPv4/IPv6 rules for ingress/egress.
14:18:54 <SridarK> yushiro: yes
14:19:07 <reedip_> Hi sorry
14:19:09 <reedip_> just joined in
14:19:14 <SridarK> yushiro: we talked abt dhcp responses
14:19:30 <yushiro> SridarK, Yes, exactly.
14:19:33 <reedip_> damn trFFIC
14:19:49 <SridarK> reedip_: no worries
14:20:17 <xgerman> reedip_ autonomous cars :-)
14:20:32 <reedip_> still, traffic ! :(
14:20:33 <yushiro> In order to pass DHCP packet in booting VM, it is enough to allow only egress? (Currently, I'm not sure and not tested..)
14:20:50 <yushiro> s/it is/is it
14:21:26 <yushiro> I want some comments with DHCP packet perspective.
14:21:34 <xgerman> mmh, I think you need both. Isn’t DHCP some UDP thing?
14:22:24 <vks1> xgerman: indedd its UDP pkt and it need to be allowed on 67/68 port
14:22:33 <SridarK> yushiro: yes lets look at it - and be in alignment with Security Groups
14:22:58 <vks1> also, what about ARP pkts ?
14:23:05 <yushiro> xgerman, SridarK, vks1  OK, thanks.  I forgot SG :) hahaha
14:23:45 <xgerman> vks1 not sure about those. Neutron itself is not very good with arp
14:24:33 <vks1> yushiro: I have one question though how this DFWG co-exist with SG. I mean how we jusify the use case
14:24:40 <chandanc> the ARP and DHCP 67/68 are required to be allowed
14:24:52 <xgerman> \me recommends this blog series for ARP in Neutron: https://ihrachyshka.com/2017/05/17/gratuitous-arp-for-openstack-neutron/
14:25:29 <chandanc> thanks xgerman
14:26:04 <yushiro> vks1, Ex. in DVR environment, we should apply fwg into ports.
14:26:09 <SarathMekala> xgerman, +1
14:26:53 <vks1> yushiro: I was asking isn't that going to be reduntant
14:27:20 <SridarK> vks1: yes it is but we are like a logical AND operation when we have co-existence
14:27:41 <SridarK> SG AND FWaaS need to permit for a permit
14:28:22 <vks1> SridarK: I was just curious about the purpose it serves
14:28:36 <SridarK> vks1: yes u are correct
14:28:56 <SridarK> if we always coexist - we can possibly take a short cut
14:29:21 <SridarK> but since some may not enable SG - we will need this redundant behavior
14:29:38 <vks1> SridarK: more than anything , can it cause confusion to operator in deployment ?
14:29:47 <vks1> *operators
14:30:06 <SridarK> vks1: agreed but we need to message that correctly
14:30:13 <xgerman> +1
14:30:44 <SridarK> it is likely eventually we may get to a point where only one of these features will be used or exist
14:31:00 <SridarK> but that is a long term horizon
14:31:25 <reedip_> ok , I just read the logs
14:31:32 <SridarK> yushiro: but back to ur point - we will need to close this
14:31:43 <SridarK> so we are in alignment with SG
14:31:48 <yushiro> SridarK, ok.
14:32:09 <reedip_> I agree, DHCP reedip request/response and ARP req/res need to be by-passed on booting the VM with default fwg
14:32:25 <yushiro> chandanc, Regarding DHCP packet,  can we apply ovs rule as 'default flow rule' ?
14:32:42 <yushiro> chandanc, not to 'firewall rule'. ( sorry, it is hard to tell ..)
14:33:00 <chandanc> the DHCP and ARP are part of the basic rules in ovs firewall driver
14:34:15 <chandanc> http://paste.openstack.org/show/606135/ line 44
14:34:17 <yushiro> SridarK, chandanc I'm confusing that should we prepare firewall-rule such DHCP packet or apply ovs flow rule without firewall-rule.
14:34:52 <xgerman> SG won’t show those rules
14:35:28 <yushiro> xgerman, Ok, so, I'll align with SG ?
14:35:33 <yushiro> s/?//
14:35:39 <chandanc> sure
14:35:42 <SridarK> yushiro: +1
14:35:56 <reedip_> SG wont be configured for those rules either
14:35:56 <reedip_> SG allows ARP and DHCP when the VM boots up
14:36:19 <reedip_> SG wont be configured for those rules either
14:36:25 <reedip_> SG allows ARP and DHCP when the VM boots up
14:36:42 <yushiro> reedip_, thanks.
14:36:47 <SridarK> yes it is under the covers and we should adopt the same model
14:36:48 <xgerman> SG allows ARP egress all the time
14:37:15 <reedip_> xgerman : ARP request egress, right ?
14:37:18 <SridarK> sounds good lets move on - i think we have clarity on the approach
14:37:21 <chandanc> SridarK: +1
14:37:22 <reedip_> or all ARP egress
14:37:32 <yushiro> So, default fwg patch is ready for merge.  So, I'll add more UTs.
14:37:34 <xgerman> request egress
14:37:36 <SridarK> yushiro: anything else u want to discuss
14:37:40 <SridarK> yushiro: +1
14:37:42 <yushiro> SridarK, nothing for me.
14:37:49 <SridarK> ok lets move on
14:38:02 <SridarK> #topic Pike/neutron-lib
14:38:07 <SridarK> reedip_: pls go ahead
14:38:08 <reedip_> SridarK , yushiro: any use case for IPv6 for DFWG
14:38:08 <reedip_> ?
14:38:29 <reedip_> Well , I had to create a small hack
14:38:48 <reedip_> rest https://review.openstack.org/#/c/456511/ is ready now
14:38:49 <SridarK> reedip_: i think on ipv6 we just maintain consistency with SG for now
14:39:13 <reedip_> there is a bug in tempest test cases which I need to look at, but I have logged a bug and skipped it for now
14:39:21 <reedip_> in neutron-lib
14:39:39 <SridarK> ok sounds good and Jenkins is happy
14:39:42 <reedip_> Please review it so that we can accelerate its inclusion :)
14:39:51 <SridarK> reedip_: will do
14:40:01 <yushiro> reedip_, SridarK, sure
14:40:12 <yushiro> reedip_, I'll do it tomorrow
14:40:19 <SridarK> ok good anything else reedip_ on this topic ?
14:40:24 <reedip_> Rest, I will now focus on the other stuff which njohnston kept open like Fullstack Tests ( It is also working but it is creating log in wrong locations, so need to twist it a bit )
14:40:37 <SridarK> ok perfect
14:40:40 <reedip_> SridarK : Nothing else for now
14:40:57 <SridarK> #topic other reviews needing attention
14:41:08 <SridarK> vks1: lets start with u
14:41:22 <SridarK> #link https://review.openstack.org/#/c/458723/
14:41:27 <vks1> SridarK: you wanted to discuss
14:41:28 <SridarK> i think u are done
14:41:37 <SridarK> yes i just had a minor nit
14:41:49 <SridarK> i wanted some clarification on v1 and v2
14:41:58 <vks1> SridarK: please go ahead
14:42:02 <SridarK> i see changes in v2 plugin
14:42:13 <SridarK> how do we handle v1
14:42:51 <SridarK> i have been meaning to connect with u and thought it best to atleast bring it up b4 i forget again
14:43:34 <vks1> SridarK: for v1 I don't think we have any provider_config sort of settings
14:43:53 <SridarK> hmm so we dont need to add it ?
14:43:53 <reedip_> vks1 : the config file is for both v1 and v2 right?
14:44:01 <SridarK> reedip_: +1
14:44:05 <vks1> SridarK: but lets say if we want to use this config file with v1 , there shud not be issue
14:44:07 <SridarK> that was my confusion
14:44:08 <reedip_> if so, can you add a small nit in the the reno file?
14:44:37 <vks1> reedip_: please suggest
14:44:38 <SridarK> vks1: yes we shd support both as parallel paths
14:44:51 <reedip_> vks1 : as of now I think it is being used for both v1 and v2
14:45:25 <vks1> SridarK: the config file can be used for both, but corrsponding implementation should be added in plugin
14:45:30 <SridarK> if we had a v1 deployment how would this take effect ?
14:45:34 <SridarK> vks1: yes exactly
14:45:35 <reedip_> I do not think we are differentiating in the file
14:45:48 <reedip_> vks1 : this needs to be notified that this is for V2 only
14:45:51 <reedip_> in the release note
14:45:52 <SridarK> reedip_: yes that is fine
14:46:06 <reedip_> so that user do not use it for V1 expecting any changes
14:46:16 <SridarK> reedip_: hmm why do it for v2 only ?
14:46:41 <reedip_> SridarK: In the current implementation ... if we are going to continue with v1 and v2, then no changes in reno
14:46:43 <SridarK> unless we are saying that it is on its way out
14:46:56 <SridarK> reedip_: ok
14:47:17 <reedip_> SridarK : Have we dropped the mail for V1 deprecation yet?
14:47:27 <vks1> SridarK: reedip_: currently this patch is agnostic of v1 or v2. Its just a placeholder now, until we go and add some code
14:47:49 <reedip_> vks1 : Exactly .. but we have added support for v2 in it :)
14:48:03 <reedip_> means the config is workable with both v1 and v2
14:48:10 <reedip_> and v2 plugin support exists in this patch
14:48:11 <reedip_> :)
14:48:16 <vks1> SridarK: I introduced in PS1 quota but there were comments to not to introduce that int his patch
14:48:30 <reedip_> means you have 2 functionalities in the same patch if looked at the micro level :)
14:48:38 <vks1> reedip_: yeah but oslo option for both v1 and v2 can't coexist
14:48:40 <SridarK> https://review.openstack.org/#/c/458723/12/neutron_fwaas/services/firewall/fwaas_plugin_v2.py
14:48:58 <SridarK> L#37
14:49:14 <SridarK> do we need this in the v1 plugin as well ?
14:49:26 <vks1> SridarK: v2 imports v1 and it cause duplication of oslo config and it breaks
14:49:28 <SridarK> so whichever is enabled (v1 or v2)
14:49:38 <SridarK> vks1: ouch
14:49:48 <SridarK> hmm i wonder abt that
14:49:49 <vks1> SridarK: the moment you enablev2 v1 also gets imported
14:50:04 <SridarK> ok now i see ur issue - let me go look at why we do that
14:50:09 <reedip_> vks1 :really , then we should modify it :)
14:50:17 <SridarK> that seems blasphemy to me :-)
14:50:24 <SridarK> i see ur issue now
14:50:30 <reedip_> SridarK : not the exact way of OOP :)
14:50:55 <SridarK> ok good let me go do some digging  too - this might be an oversight from some early development to get us to move fwd
14:50:56 <reedip_> Sorry , it is exactly OOP :)
14:51:17 <SridarK> i thought it more like "oops" !!
14:51:27 <reedip_> hehehehe
14:51:32 <SridarK> :-)
14:51:44 <SridarK> vks1: ok let me dig some more
14:51:57 <reedip_> vks1 : maybe you can put a bug for the same ( where v2 imports v1 )
14:52:00 <SridarK> and see the quickest way fwd so we dont delya ur patch
14:52:06 <hoangcx> So, what is about my curious question ?
14:52:19 <reedip_> hoangcx : shoot :)
14:52:35 <hoangcx> reedip_: i commented on the patch :-p
14:52:53 <hoangcx> "Just a curious question: Do we need to decouple fwaas_agent.ini as lbaas, vpnaas... also?"
14:53:04 <reedip_> hoangcx : lemme check , I forgot :)
14:53:59 <hoangcx> vks1 just supported decoupling .conf but .ini
14:54:42 <vks1> hoangcx: it would be gud , so this ini file will be with l3agent
14:54:57 <hoangcx> vks1: right
14:55:57 <vks1> SridarK: reedip_: https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/extensions/firewall_v2.py#L28
14:56:28 <reedip_> vks1 : but thats the fwaas extension
14:56:37 <reedip_> we can change that
14:56:40 <SridarK> vks1: ok i think the line above may explain this
14:56:41 <vks1> SridarK: reedip_: please look into this. yeah
14:56:47 <SridarK> vks1: yes will do
14:57:00 <vks1> SridarK: no blasphemy :)
14:57:04 <reedip_> SridarK : just a minor patch, wont hurt much
14:57:05 <SridarK> we should not have import incest in this manner
14:57:08 <SridarK> :-)
14:57:20 <reedip_> but a good catch vks1 ... I saw it but missed it
14:57:23 <SridarK> vks1: good this brought this out
14:57:29 <SridarK> ok lets move on
14:57:33 <SridarK> with time
14:57:38 <reedip_> and this can be integrated in the neutron-lib patch itself where the whole code is being reworked
14:57:44 <SridarK> #topic Open Discussion
14:57:50 <vks1> reedip_: grt
14:57:54 <SridarK> reedip_: +1
14:58:07 <reedip_> ok , will do ...
14:58:15 <vks1> hoangcx: you were telling something
14:58:27 <SridarK> sorry hoangcx go ahead
14:58:32 <hoangcx> vks1: No, I'm OK with that :-)
14:58:38 <SridarK> or u and vks1 can discuss on gerrit
14:59:16 <yushiro> chandanc, if you reach out to paddu, could you add CC to me?
14:59:29 <chandanc> sure will do yushiro
14:59:35 <yushiro> I also need to sync up with him about l2-agent patch
14:59:48 <SridarK> ok we are at time
14:59:50 <reedip_> yushiro : you pinged me last week , sorry I missed it
14:59:57 <SridarK> thx for joining
14:59:57 <yushiro> reedip_, NP!!!
15:00:00 <SridarK> bye all
15:00:03 <SridarK> #endmeeting