14:01:34 <yushiro> #startmeeting fwaas
14:01:35 <annp_> hi SridarK
14:01:35 <openstack> Meeting started Thu Aug 16 14:01:34 2018 UTC and is due to finish in 60 minutes.  The chair is yushiro. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:37 <njohnston> o/
14:01:38 <openstack> The meeting name has been set to 'fwaas'
14:01:40 <yushiro> Hi SridarK
14:01:48 <annp_> Hi Nate
14:02:00 <yushiro> #chair SridarK
14:02:01 <openstack> Current chairs: SridarK yushiro
14:02:03 <SridarK> yushiro: today my turn i think ?
14:02:13 <yushiro> SridarK, Yes, please :)
14:02:19 <SridarK> ok :-)
14:02:30 <SridarK> #topic Rocky
14:03:04 <SridarK> Thx to all for getting the FWaaS Logging patches in
14:03:23 <yushiro> SridarK, Thank you too.  I really appreciate.
14:03:26 <annp_> thank you a lot, SridarK.
14:04:02 <SridarK> No issues at all - yushiro annp_ longkb hoangcx - u all did a great job
14:04:16 <njohnston> congrats - you did great work!
14:04:30 <yushiro> Thanks njohnston.  :)
14:04:40 <reedip|afk> \o/
14:04:41 <SridarK> Are there any other things that need attention
14:04:46 <annp_> SridarK, njohnston: you too.
14:05:22 <annp_> SridarK, I'd like to share with you some regression test between firewall and firewall logging
14:05:40 <SridarK> annp_: yes i was going to ask abt that :-)
14:05:45 <annp_> Here is our test result: https://etherpad.openstack.org/p/firewall-logging
14:06:33 <yushiro> This is the same URL that I wrote down at the agenda.
14:06:50 <annp_> yushiro, thanks.
14:07:07 <annp_> let's me summary:
14:07:33 <SridarK> thx annp_
14:07:35 <yushiro> OK.
14:07:42 <SridarK> so we have one issue
14:07:47 <annp_> 1. almost case for allow/drop with L3 port work fine.
14:08:19 <SridarK> sorry annp_ go ahead
14:08:23 <annp_> 2. almost case for allow/drop with L2 port if we didn't enable L2 logging extension work fine.
14:09:43 <annp_> 3. There one issue related to case when enable L2 logging extension as I declared at case 3 in the link.
14:10:06 <yushiro> annp_, You mean 'almost' is 'all', right?
14:10:29 <annp_> yushiro, yes.
14:10:44 <annp_> yushiro, in other word, so far so good. :)
14:10:58 <longkb> o/
14:11:03 <longkb> Sorry, I am late
14:11:17 <yushiro> longkb, welcome home :)
14:11:30 <longkb> thanks yushiro :D
14:11:32 <yushiro> annp_, I see.  Ok, that is same understanding.
14:11:37 <SridarK> so if we have sg logging and fwaas logging enabled we have an issue
14:11:49 <SridarK> although with fwaas logging we only support L3
14:11:51 <SridarK> ports
14:11:57 <annp_> SridarK, yes.
14:12:02 <longkb> +1 SridarK
14:12:25 <yushiro> SridarK, yes, you're right.
14:12:28 <annp_> SridarK, I and longkb already putted patches to fix that
14:12:33 <SridarK> and u have patches in flight (sorry i had some PTO so not completely on top)
14:12:39 <SridarK> annp_: +1
14:13:02 <annp_> https://review.openstack.org/#/c/591918/
14:13:02 <annp_> https://review.openstack.org/#/c/591978/
14:13:09 <SridarK> got it
14:13:42 <yushiro> In addition, 1 follow up patch: https://review.openstack.org/#/c/590682/
14:14:29 <annp_> SridarK, yushiro, We also need patch https://review.openstack.org/#/c/590682 to make logging work perfect. :)
14:14:33 <SridarK> ok thx yushiro
14:14:38 <yushiro> I think https://review.openstack.org/#/c/590682/ needs to be backported into stable/rocky if possible.
14:14:39 <SridarK> and annp_
14:14:48 <yushiro> Sorry annp_ .
14:14:58 <yushiro> annp_, We've duplicated :p
14:15:04 <SridarK> :-)
14:15:07 <annp_> yushiro, ah. :)
14:16:01 <SridarK> ok sounds good we can track these
14:16:02 <annp_> yushiro, Do you want to say something regards to some crazy bug at logging topic or later for bug topic
14:16:30 <SridarK> lets go on to bugs then if we are done here
14:16:44 <annp_> SridarK, thanks.
14:16:45 <yushiro> SridarK, annp_ +1  OK.
14:16:49 <SridarK> ok
14:16:59 <yushiro> annp_, I'll explain about this bug :)
14:17:00 <longkb> got it :D
14:17:02 <SridarK> #topic bugs
14:17:07 <longkb> oh
14:17:14 <SridarK> yushiro: pls go ahead
14:17:57 <yushiro> Regarding annp_ , longkb and tuanvc's great testing, we've clarified known bug
14:18:17 <yushiro> The bug was 'state transition of firewall group'.
14:18:37 <longkb> I found another crazy bug on FW Dashboard too: https://docs.google.com/spreadsheets/d/1Z_3h2Fqffz8Zjr6PHrMxBrx210jM7TtPDAFvSJtUXzg/edit#gid=1429860855
14:18:56 <yushiro> longkb, Yes, thank you.
14:19:31 <yushiro> SridarK, This is draft version of testcases for state transition: https://docs.google.com/spreadsheets/d/1Z_3h2Fqffz8Zjr6PHrMxBrx210jM7TtPDAFvSJtUXzg/edit#gid=0
14:20:08 <yushiro> I'd like to clarify again about 'state definition of firewall group'.
14:20:35 <SridarK> ok hmm interesting we dont land up at correct status
14:20:42 <SridarK> for some updates
14:21:54 <yushiro> SridarK, Yeah.
14:22:19 <yushiro> The most important point is 'what is "ACTIVE" state for firewall group?'
14:22:36 <annp_> yushiro, +1
14:22:42 <yushiro> In my understanding,  ACTIVE:  has ingress or egress_firewall_policy and has at least 1 port and admin_state_up is 'UP'
14:22:56 <SridarK> yushiro: yes
14:23:16 <yushiro> DOWN: admin_state_up is 'DOWN'
14:23:24 <annp_> yushiro, SridarK, Is there any document related to fwg state?
14:23:45 <SridarK> yushiro: yes
14:23:54 <SridarK> annp_: not sure if we have something
14:24:05 <yushiro> annp_, In my memory, we've discussed on IRC meeting only since previous cycle.
14:24:31 <annp_> SridarK, yushiro, ok. So let's make the document about that
14:24:56 <SridarK> but basically, INACTIVE means that we dont have a port or policy or both - to distinguish from DOWN
14:25:08 <SridarK> annp_: +1
14:25:13 <yushiro> annp_, +1
14:25:52 <yushiro> SridarK, Yes, I agree with you.      INACTIVE: has ingress or egress_firewall_policy and no port  or no ingress or egress_firewall_policy and at least 1 port  and admin_state_up is 'UP'
14:26:12 <yushiro> ooops, difficult fot document..
14:26:45 <amotoki> do we need to reflect admin_state(_up) to status?
14:26:47 <SridarK> yes some cleanup is needed
14:27:31 <amotoki> in neutron port, admin_state UP and status ACTIVE means a port itself can work but it is disabled
14:27:46 <yushiro> amotoki, DOWN ?
14:28:42 <amotoki> there is a case where port status is DOWN and admin state is UP
14:28:59 <amotoki> I might be wrong....
14:29:02 <SridarK> I think this needs some cleanup - i just added an item to our list
14:29:02 <yushiro> current impl, firewall group depended on 'admin_state_up' with own 'status'.  If admin_state_up is 'DOWN', then the status of firewall group changed into 'DOWN'
14:29:16 <yushiro> SridarK, Thanks.
14:29:33 <annp_> SridarK, ++
14:29:42 <SridarK> amotoki: i think as yushiro says
14:29:50 <amotoki> SridarK: yeah
14:30:07 <SridarK> i think we need to look at this more and align better with neutron as well
14:30:17 <amotoki> there is no clear guideline on what we should change 'status' attr when admin_state is changed..
14:30:27 <amotoki> IIRC network and port have different behaviors
14:30:50 <SridarK> annp_: let me take an action and document current behavior and we start a thread on clean up
14:31:19 <annp_> SridarK, yeah.that's sound great!
14:31:25 <SridarK> we are a bit unique also in what we need to do if a fwg is associated with multiple ports and one of them is down or admin down
14:31:37 <SridarK> so that area needs some thought too
14:31:52 <annp_> SridarK, thanks.
14:32:20 <yushiro> OK.
14:33:17 <yushiro> I thought that firewall group was referring router's state transition but it was different..  There is no relation b/w admin_state_up and status for router.
14:34:58 <SridarK> yushiro: sorry multitasking in another mtg
14:35:26 <yushiro> In case of router, if 'admin_state_up' is down, the namespace has been removed.  If we refer router's behavior, all firewall rules should be removed if we changed admin_state_up into 'DOWN'.  That is one example..
14:35:31 <yushiro> SridarK, never mind :)
14:35:36 <annp_> yushiro, SridarK, I think we can discuss via email
14:35:57 <yushiro> annp_, +1
14:36:37 <SridarK> yushiro: i agree
14:37:04 <SridarK> here there are bugs and also handling multiple ports case
14:37:27 <yushiro> Yeah, at first, let's summarize current behavior and sync up with fwaas members.
14:38:00 <annp_> yushiro, ++
14:38:14 <SridarK> yushiro: +1
14:39:27 <yushiro> SridarK, OK, that's all from me :)
14:39:47 <SridarK> ok sounds good
14:39:54 <annp_> longkb, your turn :)
14:40:53 <longkb> +1 annp
14:41:26 <longkb> I make a statistic related to FW rules updating from FW Dashboard. Please look at this doc: https://docs.google.com/spreadsheets/d/1Z_3h2Fqffz8Zjr6PHrMxBrx210jM7TtPDAFvSJtUXzg/edit#gid=1429860855
14:42:32 <longkb> The value will return to default value if we do not choose again during FW rule updating
14:43:43 <amotoki> it seems the first step is to check what body is passed as a request to neutron server and what is returned as a response from the neutron API.
14:44:40 <yushiro> amotoki, +1  longkb I think checking request body is necessary as well.
14:44:52 <longkb> +1 amotoki, yushiro :D
14:45:27 <amotoki> longkb: could you file a bug to neutron-fwaas-dashboard so that all can track it?
14:45:59 <longkb> amotoki: sure. I will report this bug tomorow :D
14:46:05 <SridarK> +1
14:46:13 <annp_> +1
14:46:33 <yushiro> SridarK, Can I put bug-report regarding state transition as well?
14:46:35 <SridarK> longkb: good catch - possibly some regression
14:47:09 <longkb> thanks SridarK
14:49:20 <SridarK> yushiro: we shd sync up on the issue with HA/DVR Ports
14:50:12 <yushiro> #link https://bugs.launchpad.net/neutron/+bug/1759773
14:50:12 <openstack> Launchpad bug 1759773 in neutron "FWaaS: Invalid port error on associating L3 ports (Router in HA) to firewall group" [Undecided,Confirmed] - Assigned to Sridar Kandaswamy (skandasw)
14:50:18 <SridarK> as we last discussed we need to get some clarification from the L3HA team
14:51:47 <yushiro> SridarK, Yes.  However, I haven't discussed with them yet..
14:51:56 <SridarK> yushiro: in ur last round of tests - it seemed like the rules were not applied appropriately
14:52:11 <SridarK> yushiro: ok no issues - lets discuss more offline
14:52:32 <SridarK> I think thats all we had on this topic
14:52:38 <SridarK> lets move on
14:52:40 <yushiro> SridarK, yes.  Even if we could associate FWG with HA port, the firewall rule has applired into 'standby' router.
14:52:47 <SridarK> yushiro: +1
14:53:08 <SridarK> it seemed like this is something we need to handle
14:53:21 <SridarK> #topic Open Discussion
14:53:55 <yushiro> SridarK, Yes, whether we should handle or abstruct from L3-HA layer.
14:54:11 <SridarK> yushiro: yes exactly
14:54:35 <yushiro> Tomorrow, I'll send e-mail to ML about this issue.
14:54:47 <yushiro> #action yushiro will send ML about L3-HA issue
14:55:02 <SridarK> yushiro: sounds good - or we can attend the L3 mtg and discuss there
14:55:26 <SridarK> i think that may be more useful - so we can debug it quickly with the L3 team
14:55:45 <yushiro> SridarK, yes.  Maybe after this meeting ?  will check it :)
14:56:04 <SridarK> yushiro: ok
14:56:14 <amotoki> IIRC there is no L3 meeting this week
14:56:23 <SridarK> oh yes it was cancelled
14:56:30 <SridarK> yushiro: then next week
14:56:34 <yushiro> Tuesday at 1500 UTC in #openstack-meeting
14:56:39 <amotoki> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133129.html
14:56:42 <yushiro> SridarK, OK, thanks.
14:57:01 <SridarK> yushiro: i will ping u during ur day time and lets discuss b4 we attend the L3 mtg
14:57:09 <yushiro> amotoki, Thanks akihiro
14:57:22 <yushiro> SridarK, OK, thanks.
14:57:29 <SridarK> i think it shd be quick IMO - we just need a specific clarification
14:57:48 <SridarK> ok if nothing else we can close out ?
14:58:16 <SridarK> Thx all for joining
14:58:22 <SridarK> have a great week
14:58:37 <yushiro> SridarK, Yes, we'are asking from Chris and Hyunsun
14:58:41 <yushiro> Thanks all.
14:58:49 <annp_> SridarK, you too
14:58:51 <SridarK> #endmeeting