13:59:51 #startmeeting fwaas 13:59:52 Meeting started Thu Apr 12 13:59:51 2018 UTC and is due to finish in 60 minutes. The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:59:56 The meeting name has been set to 'fwaas' 14:00:03 #chair xgerman_ 14:00:04 Current chairs: SridarK xgerman_ 14:00:16 yushiro will not be able to join today 14:00:39 hi 14:00:47 Hello All 14:01:47 We are nearing Rocky R-1 milestone 14:02:28 o/ 14:02:35 https://releases.openstack.org/rocky/schedule.html 14:03:06 xgerman_: any other announcements that u would like to bring up ? 14:03:44 for the Vancouver people there is a CI/CD summit colocated with the OopenStack summit 14:04:40 #link https://www.openstack.org/news/view/376/opendev-cicd-schedule-now-live-collaborative-technical-event-focuses-on-jenkins-spinnaker-zuul-and-more 14:04:45 xgerman_: oh that is interesting, do u know if the summit registration covers that ? 14:05:13 yep, covered with the OpenStack pass 14:05:37 nice, thx for that info xgerman_ 14:06:01 Excuse me, what might I have missed? 14:06:34 wkite: will u be at the summit in Vancouver ? 14:07:08 This is unlikely 14:07:18 wkite: if so check out the link above for a CI/CD summit that happens colocated 14:07:30 wkite: ok then no impact 14:07:52 but might be good to check out and if there are videos post event - u can catch up 14:08:00 ok lets move on 14:08:29 #topic Rocky: Pluggable backend Driver 14:08:36 doude: pls go ahead 14:08:45 Hi 14:09:04 doude: thx for addressing comments 14:09:13 I had few reviews, one from you SridarK and two others 14:09:23 I answered them 14:10:00 #link https://review.openstack.org/#/c/480265/ 14:10:02 and for the moment no issue was reported to me 14:10:24 I think yushiro had some clarifications on the tests 14:10:43 doude, have you tested with your patch in multi node environemnt? 14:10:45 #link https://etherpad.openstack.org/p/fwaas-pluggable-backend-testing 14:10:57 no I did not 14:11:25 annp 14:11:31 doube, Today I tried to test your patch, I got same result as yushiro report last metting 14:12:05 doube, Exception OVSFWaaSPortNotFound was raised. 14:12:32 ok 14:12:33 doude: it seems yushiro did not have u in he email - just fwd-ed it to u 14:13:11 annp: this was on update of FWG correct ? 14:13:23 hot it now 14:13:27 got it now 14:14:11 SridarK,I have tested with master branch, I don't see OVSFWaasPortNotFound exception 14:14:22 annp: thx 14:14:48 annp: was it updating a FWG with a port ? 14:14:55 annp can you descibe step you used to reproduce it? 14:15:36 doube, SridarK, 1st: building 1 controller node and 2 compute node with doube's patch 14:16:02 then create VM, You can see log in q-agt.service 14:16:19 Default fwg status change to ERROR 14:16:43 yushiro said in his email he reproduces it in both cases: all-in-one and multi node 14:17:17 annp: oh ok it is on VM create (which triggers the update on FWG) 14:17:28 ok I'll look at it 14:17:28 doude, I just tested with multi node not tested with all-in-one 14:17:35 ok 14:17:48 I've a aio ready, I can try 14:17:52 SridarK, yes 14:18:17 annp: ok thx and as u mention, it seems yushiro sees it in all in one itself 14:18:34 doude: thx can u quickly check that out and debug 14:18:57 annp: would u mind to put a comment on gerrit as well ? 14:19:24 SridarK, No problem. I will do. 14:19:31 annp: thx 14:20:22 also, I've comment from NSX developer who said they already have a NSX driver for FWaaSv2 and ask if my patch will break it 14:20:47 https://review.openstack.org/#/c/480265/19/devstack/plugin.sh@47 14:22:14 doude: yes I think there has to be some accompanying change but i think it may not be too bad 14:22:47 ok, but I don't get how their driver work actually 14:22:53 there is no driver interface 14:23:24 doude: but it will help to get that to a resolution to make sure that there is a clear path for existing users 14:24:24 If someone is using the community version of the pluging and only defining a backend driver - their impact should be minimal ? 14:24:35 just specifying the driver 14:24:44 yes 14:25:04 but with anyone with their version of the plugin - they will need to conform to the service driver interface 14:25:39 not sure to understand that 14:26:12 no they will need to specify their plugin as a flavor 14:26:41 doude: possibly a discussion with the reviewer to outline the changes would be good 14:26:53 as we dont really understand their implementation 14:27:22 ok 14:27:40 I think they implemented their own service plugin 14:27:49 ok 14:27:54 so event after my patch, that'll continuing to work 14:28:16 the service plugin insterface did not change with my patch 14:28:34 and if they want they can implement their plugin as a service driver 14:28:44 but as such they should be fine 14:29:25 ok if they are comfortable we can move on - else maybe a discussion on the channel with them will be good so u can move fwd 14:30:43 ok shall we move on 14:30:48 doude: anything else ? 14:30:54 oh no they use that driver interface https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/services/firewall/drivers/fwaas_base.py 14:31:07 no it's ok for me 14:32:04 ok 14:32:12 lets talk more offline 14:32:22 ok 14:32:31 #topic Rocky Address Group Spec 14:33:01 #link https://review.openstack.org/#/c/557137/ 14:33:25 wkite: pls go ahead 14:33:42 ok 14:33:48 I have also added a few comments 14:34:16 in 14:34:37 annp: chandanc: also pls take a look in what we can support on the driver 14:34:48 we will need to do both iptables and ovs 14:34:49 sure SridarK 14:35:12 sure 14:35:22 or rather how we will support on the driver 14:35:47 wkite: i also echo njohnston 's comment on the address range 14:36:11 wkite: is that very critical need - defn it improves usability 14:36:43 This is a function we need 14:36:46 to support arbitrary ranges not along a cidr block 14:36:57 wkite: ok 14:37:54 wkite: ok lets continue this on the review 14:38:04 wkite: other things u want to bring up 14:38:58 we also need multi address groups 14:39:39 I have implemented this function with my own code. 14:40:28 But I only implemented the driver of iptables by iprange module 14:41:29 wkite: we only support a single address (or range) but i can see the value of having multiple AG's 14:41:45 wkite: we will need to eval ovs for L2 support 14:42:27 lets continue discussion on the review 14:42:50 ok 14:43:41 #topic Rocky FWaaS Logging spec 14:43:46 #link https://review.openstack.org/#/c/509725/ 14:43:53 annp: pls go ahead 14:44:21 I think we just have to resolve some minor things and we should be able to move fwd ? 14:44:34 SridarK: Yes 14:44:34 I'm waiting update from submiter :) 14:44:42 annp: ok 14:44:57 annp anything else u would like to bring up here ? 14:44:58 I think spec is quite close to merge. 14:45:26 Oops, job failed!!! 14:45:33 SridarK, that's all from me. 14:45:49 ok sounds good 14:46:32 #topic Rocky Remote FWG 14:46:39 xgerman_: pls go ahead 14:46:43 #link https://review.openstack.org/521207 14:47:04 not much progress — but I am firmaly in for R-2 14:47:13 xgerman_: sounds good 14:47:35 #topic Rocky tempest 14:48:05 I have been looking at this and will get something going for R-2 14:48:34 #topic bugs 14:49:02 #link https://bugs.launchpad.net/neutron/+bug/1759773 14:49:03 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:49:46 and we had a similar issue for DVR, I will address the DVR issue but on HA would like to get some discussion going on behavior after switchover 14:50:27 I dont know that we had any other bugs come up recently but it is time to do a scrub at some point soon 14:50:57 #topic Open Discussion 14:51:16 Hi xgerman_ 14:51:22 hi 14:51:31 We will skip Dashboard as i dont see SarathMekala - he was going to come up with a list of enhancements 14:51:40 I'm planning to start collect idea for l7 filtering 14:51:49 annp: +1 14:52:07 nice — that’s cilium’s claim to fame 14:52:23 I think we can bring this topic to forum at vancouver summit. Do you think so? 14:52:50 xgerman_, yes, cilium is great. 14:53:02 yes, we can ;-) 14:53:03 annp: have u had some ideas on the backend ? BPF ? 14:54:10 SridarK, actually, I just want to collect idea to start chose good solution before I implement it 14:54:32 well, we should make it pluggable in any way and then just have a rference implementation 14:54:42 May be BPF and XDP is good choice. Is there any simpler than BPF and XDP? 14:54:52 :) 14:54:58 iptables? 14:55:10 annp: ok the challenge (and part of the requirements and discussion) is we will need to support a ref implementation 14:55:13 (which is BPF under the cover but…) 14:55:19 yes. maybe but i'm not sure :) 14:55:50 we should also look at how Octavia/LBaaS define L7 rules 14:56:15 xgerman_: that would be useful 14:56:16 https://developer.openstack.org/api-ref/load-balancer/v2/#l7-policies 14:56:25 xgerman_ +1 14:56:52 yeah, if we can settle on a common “language” that would make it easier for users 14:57:05 I also think CCF was going in that direction 14:57:21 So I think we can create a etherpad to collect requirement and idea for L7 filtering, Do you think so? 14:57:29 annp: +1 14:57:58 xgerman_: we should also evaluate where we stand with CCF 14:58:11 and also the progress on CCF 14:58:31 +1 14:59:17 https://etherpad.openstack.org/p/fwaas-v2-L7-filtering 14:59:30 annp: ok great lets add thoughts there 14:59:49 ok we are at time 14:59:53 thanks all for joining 15:00:08 bye 15:00:12 thanks all 15:00:14 #endmeeting