Monday, 2017-09-18

*** hoangcx has joined #openstack-fwaas00:57
*** hoangcx has quit IRC01:42
*** hoangcx has joined #openstack-fwaas02:00
*** annp has joined #openstack-fwaas03:45
annpreedip, good morning.03:46
reedipgood morning annp03:46
annpreedip :)03:46
reediphow ar eu03:46
reediphow are u * ?03:46
annpyes, I'm good and how about you?03:46
annpreedip, I'm working on fwaas l2 agent patch to resolve comment from you and Inessa.03:48
reedipI am fine ...03:48
reedipok annp ...03:48
reedipI am also looking into it to resolve the LIST issue03:48
annpreedip, and I mark something moving to default fwg patch. Could you update default fwg patch?03:49
reedipYes, I can03:50
reedipLet me check, I think you marked 3 places03:50
reediphttps://review.openstack.org/#/c/323971/51/neutron_fwaas/services/firewall/fwaas_plugin_v2.py@6303:50
reediphttps://review.openstack.org/#/c/323971/51/neutron_fwaas/services/firewall/fwaas_plugin_v2.py@19903:50
annpreedip, I think we can introduce a new patch for applying default fwg on L2. Do you think so?03:50
reediphttps://review.openstack.org/#/c/323971/51/neutron_fwaas/services/firewall/fwaas_plugin_v2.py@22403:50
reedipAre they correct ?03:50
reedipIf yes, then I will move these 3 pieces of code to DFWG patch03:51
annpreedip, correct.03:51
annpreedip: how about https://review.openstack.org/#/c/323971/51/neutron_fwaas/services/firewall/agents/l2/fwaas_v2.py@30803:52
reedipI dont think its related with DFWG03:52
reedipto be honest03:53
reedipBut yes https://review.openstack.org/#/c/323971/51/neutron_fwaas/services/firewall/fwaas_plugin_v2.py@448 is one more03:53
annpreedip: I'd like to introduce new patch set for applying default fwg. This patch will depends on L2 agent patch and fwg default patch.03:53
annpreedip, what do you think?03:54
annphttps://review.openstack.org/#/c/323971/51/neutron_fwaas/services/firewall/fwaas_plugin_v2.py@448 It can be in new "applying default fwg" patch. :)03:55
reedipI am not sure how it will fix ...03:55
reedipLet me see03:55
annpif we can introduce a new patch-set "applying default fwg" to handle all action related to default fwg. It would be nice.03:57
reedipannp : I am not sure how L2 is directly tied with Default FWG03:59
reedipSo I am not sure if we need a separate patch to handle appliying default FWG over L2. Though the idea seems nice, but how big would it be and how useful would it , remains to be seen04:00
annpreedip, I think applying default fwg patch will be small. Moreover, separating patch allows L2 patch, default FWG can be merged independent. And we will not be confused "What is in default fwg patch, what should be in L2 patch"04:08
annpreedip, that's my idea. :)04:08
annpIf it's reasonable, I will introduce "applying patch" or we should discuss about it in Tomorrow meeting. How do you think?04:09
reedipannp : I think currently default FWG is separate from the L2 implementation04:14
reedipannp : I mean both are pretty independent of each other. the Default FWG can exist without the L2 Agent, right ?04:14
annpyes, you're right.04:15
reediphmm04:16
reedipSo , lets discuss it once in tomorrow's meeting04:16
annpBut L2's implementation is depending on some defining of default fwg.04:16
reedipannp because we are assuming that L2 would work with default FWG but actually its not so. The L2 agent and default FWG can work independently.04:17
reedipActually whatever needs to be defined in L2 should remain in the L2 patch ONLY. And whatever is there in the FWG should remain in the FWG04:17
reedipmixing it causes the merge conflict issue04:18
annpreedip, So I'd like to remove defining and handle all impact of default fwg at new patch.04:18
reedipannp : Okay, lets first propose a new Default FWG patch04:18
reedipthen we can see what is needed by L204:18
annpreedip, new applying default fwg patch. :)04:19
reedipand then see if we can remove the dependency of default FWG from L204:19
reedipannp : I will push a new patch of default FWG04:19
annpreedip, thanks. And I will introduce apply default fwg patch also.04:20
reedipok04:20
annpreedip, Thanks for long discussion. :)04:21
reedip:)04:21
openstackgerritNguyen Phuong An proposed openstack/neutron-fwaas master: FWaaS v2 extension for L2 agent  https://review.openstack.org/32397104:26
reedipannp : enable_l2 option is not required.So I am removing it from https://review.openstack.org/#/c/323971/51/neutron_fwaas/services/firewall/fwaas_plugin_v2.py@6104:28
reedipannp : Let me know the patch for applying default FWG on L2 patch04:50
openstackgerritNguyen Phuong An proposed openstack/neutron-fwaas master: Applying default firewall group  https://review.openstack.org/50484704:52
openstackgerritReedip proposed openstack/neutron-fwaas master: Introduce default firewall groups  https://review.openstack.org/42576904:54
reedipannp : updated ^^04:54
openstackgerritReedip proposed openstack/neutron-fwaas master: Applying default firewall group  https://review.openstack.org/50484704:58
reedipannp : updated ^^04:58
annpreedip, thanks for your updated.05:00
reedipannp : mention not, but we are missing a function in the plugins05:01
reedipI have mentioned it in the comments05:01
annpI will leave office now, Feel free please update all patch-set if you want. :)05:01
reediplol :) Naah, I will focus on the default FWG  for now05:01
annpsorry, I'm forgot. I will update it when i back to work on Wednesday.05:02
annpreedip, :) have a good day.05:02
reedipyou too annp :)05:02
*** annp has quit IRC05:03
openstackgerritReedip proposed openstack/neutron-fwaas master: Add fullstack testing for neutron-fwaas  https://review.openstack.org/39461906:28
openstackgerritReedip proposed openstack/neutron-fwaas master: Add new protocols in Firewalls  https://review.openstack.org/44033106:32
*** reedip has quit IRC09:20
*** reedip has joined #openstack-fwaas09:21
ivasilevskayareedip, hi!10:05
ivasilevskayaJust can't get default fwg generation out of my head. Read your last comments - I suppose default fwg was introduced for the sake of l2 ext patch: when a firewall group is deleted then its vm ports will be "reattached" to the default fwg. If that was the idea - then one default fwg should be present at all times just like in neutron10:05
reedipivasilevskaya : If that is the case, then deletion of the default FWG doesnt make enough sense.10:07
reediplets discuss it during the team meeting tomorrow, because it needs inputs from yushiro and SridarK as well as xgerman_ and annp10:08
ivasilevskayareedip, I'm not talking about deletion of default fwg, I'm talking about deletion of any fwg that has vm ports associated to it10:08
reedipYes, my point is if there can be a scenario where the fwg is deleted and the default FWG doesnt exist10:09
ivasilevskayasure, we'll discuss it tomorrow :)10:10
reedip:)10:10
*** amotoki has quit IRC10:41
*** amotoki has joined #openstack-fwaas10:43
-openstackstatus- NOTICE: Gerrit will be offline for the upgrade to 2.13 starting at 15:00 UTC (in roughly 3 hours) and is expected to probably be down/unusable for 8+ hours while an offline reindex is performed: http://lists.openstack.org/pipermail/openstack-dev/2017-August/120533.html12:05
-openstackstatus- NOTICE: Gerrit will be offline for the upgrade to 2.13 starting at 15:00 UTC (in roughly 1.5 hours) and is expected to probably be down/unusable for 8+ hours while an offline reindex is performed: http://lists.openstack.org/pipermail/openstack-dev/2017-August/120533.html13:36
xgerman_reedip, ivasilevskaya:14:08
xgerman_1) You can’t delete a FWG with ports still attached14:09
xgerman_2) You can delete all FWG to have a port without an FWG so you can switch off port security14:09
-openstackstatus- NOTICE: Gerrit will be offline for the upgrade to 2.13 starting at 15:00 UTC (in roughly 30 minutes) and is expected to probably be down/unusable for 8+ hours while an offline reindex is performed: http://lists.openstack.org/pipermail/openstack-dev/2017-August/120533.html14:31
*** sterdnotshaken has joined #openstack-fwaas14:59
-openstackstatus- NOTICE: The Gerrit service at https://review.openstack.org/ is offline, upgrading to 2.13, for an indeterminate period of time hopefully not to exceed 23:59 UTC today: http://lists.openstack.org/pipermail/openstack-dev/2017-August/120533.html15:02
*** reedip_ has joined #openstack-fwaas15:12
*** sterdnotshaken1 has joined #openstack-fwaas15:18
reedip_o/15:19
*** sterdnotshaken has quit IRC15:21
*** reedip_ has quit IRC16:01
ivasilevskayaxgerman_: but I believe it's possible to remove a firewall group\port association for some vm port - in this case the vm port will be associated with default fwg, right?16:33
-openstackstatus- NOTICE: The Gerrit service at https://review.openstack.org/ is offline, upgrading to 2.13, for an indeterminate period of time hopefully not to exceed 23:59 UTC today: http://lists.openstack.org/pipermail/openstack-dev/2017-August/120533.html16:36
*** ChanServ changes topic to "The Gerrit service at https://review.openstack.org/ is offline, upgrading to 2.13, for an indeterminate period of time hopefully not to exceed 23:59 UTC today: http://lists.openstack.org/pipermail/openstack-dev/2017-August/120533.html"16:36
xgerman_ivasilevskaya nope - we are modeling the SG behavior that then no FWG is associated to allow eventually to remove port security. On SG case you CAN’T remove port security until all SGs are removed from the port. FWG needs to work the same way16:43
ivasilevskayaxgerman_: I may be a bit out of scope - but why are you talking about disabling port security?16:44
xgerman_we need to give users the option to do so16:45
xgerman_so it’s driving some of the design decisions16:45
ivasilevskayaxgerman_: I thought that the whole idea of these changes (default fwg, l2 agent extension, following ovs\iptables drivers) are to enable it16:45
xgerman_yes, but we can’t make it so that if a user wants to disable port security on a port we break it that he can’t anymore16:46
ivasilevskayaxgerman_: so port security is a port-level setting, not a system-wide one?16:46
xgerman_yes16:46
ivasilevskayaxgerman_ : just curious - how it is supposed to coexist with neutron security groups by the way?16:48
ivasilevskayaby this I mean fwaas l2 extension and, say, neutron ovsfw driver16:48
xgerman_I think we will run first and then SG16:49
ivasilevskayaxgerman_: And can you share any notes/spec on the whole expected behavior? All I had was the ideas behind foggy comments and TODOs in l2 extension patch16:49
xgerman_the idea is that if one of them denies it will be denied - only if both accept a packet will go through. There are changes to conntrack planned to enable that behavior16:50
xgerman_yes, we are a bit foggy - our code “diverged” a bit from the spec and our goal is to add some documentation to make things clearer16:51
ivasilevskayaxgerman_: as long as it's fwaas pipeline and the neutron sg -> it might even work that way16:51
ivasilevskayathen*16:51
ivasilevskayaxgerman_: but is there a spec? I'd like to take a look16:53
xgerman_https://github.com/openstack/neutron-specs/blob/master/specs/newton/fwaas-api-2.0.rst16:55
ivasilevskayaxgerman_ cool, thanks16:55
*** lnicolas has joined #openstack-fwaas18:05
*** vishwanathj has joined #openstack-fwaas19:28
*** sterdnotshaken1 has quit IRC19:39
*** sterdnotshaken has joined #openstack-fwaas19:54
*** yamamoto has joined #openstack-fwaas23:36
*** sterdnotshaken1 has joined #openstack-fwaas23:41
*** sterdnotshaken has quit IRC23:41
*** ChanServ changes topic to "#openstack-fwaas"23:44
-openstackstatus- NOTICE: review.openstack.org Gerrit 2.13 upgrade is functionally complete. The Infra team will be cleaning up bookkeeping items over the next couple days. If you have any questions please let us know23:44

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!