04:00:01 <njohnston__> #startmeeting fwaas 04:00:02 <openstack> Meeting started Wed Sep 28 04:00:01 2016 UTC and is due to finish in 60 minutes. The chair is njohnston__. Information about MeetBot at http://wiki.debian.org/MeetBot. 04:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 04:00:06 <openstack> The meeting name has been set to 'fwaas' 04:00:14 <SridarK> Hi All 04:00:15 <njohnston__> Hello, FWaaS friends! 04:00:31 <chandanc_> Hello all 04:00:48 <yushiro> Hi 04:01:22 <padkrish> hi all 04:01:27 <njohnston__> #chair SridarK xgerman yushiro 04:01:28 <openstack> Current chairs: SridarK njohnston__ xgerman yushiro 04:01:43 <SridarK> Lets get started 04:01:50 <yushiro> thanks njohnston :) 04:02:06 <SridarK> #topic FWaaS v2 04:02:28 <SridarK> we can focus on the CLI and L2 for any needed discussion 04:02:52 <SridarK> yushiro: on the CLI - pls go ahead floor is yours 04:03:02 <yushiro> SridarK: OK, thanks 04:03:07 <SridarK> i added one comment on the etherpad 04:03:27 <yushiro> Currently, I posted the CLI(PS 20) 04:03:32 <SridarK> if we can refer to v2 as firewallgroup ? 04:03:39 <SridarK> and v1 as firewall 04:03:46 <SridarK> to distinguish the resources 04:03:50 <yushiro> SridarK: Currently, yes. 04:04:05 <yushiro> However, I'd like to discuss firewall-policy and firewall-rule. 04:04:09 <SridarK> another proposal from njohnston earlier was to see if we can query the plugin version 04:04:29 <SridarK> yushiro: yes pls go ahead 04:04:38 <yushiro> Adding prefix like "_v2" is previous discussion with SridarK and chandanc_ 04:04:47 <njohnston> #link https://etherpad.openstack.org/p/fwaas-v2-cli Etherpad for discussion of the FWaaS CLI 04:04:57 <yushiro> njohnston, Thanks! 04:06:02 <yushiro> OSC plugin cannot use "_" for resource name. I think it is programmatic constraint. 04:06:20 <SridarK> i was wondering if instead of _v2 we can use firewallgroup 04:06:32 <SridarK> so the policy would be: 04:06:48 <SridarK> openstack firewallgroup policy create 04:07:18 <SridarK> and openstack firewall policy create would be the equivalent in v1 04:07:44 <SridarK> in the event if we had to go with OSC for v1 04:08:15 <njohnston> If we don't build v1 support into OSC, then can we just use 'firewall'? 04:09:03 <SridarK> njohnston: i think if we know that we will never support v1 in OSC - we have more flexibility 04:09:37 <njohnston> I agree, it would be much more flexibility, and it would let us use the choice that is easiest for customers to understand 04:09:58 <SridarK> our data models for policy and rule btwn v1 and v2 do not overlap either 04:10:07 <SridarK> so we keep them all separate 04:10:28 <chandanc_> we can use "firewall" for v2 and "firewallv1"for v1 (if we need to) 04:10:32 <yushiro> SridarK: openstack firewallgroup policy create got an error like "is not an openstack command. See 'openstack --help'" 04:10:43 <njohnston> Does anyone have any reasons why they think we should support v1 in OSC? This would be as opposed to just leaving the current support it is currently. 04:11:58 <SridarK> njohnston: good point, yushiro: do all current CLI have to move to OSC ? 04:12:27 <SridarK> yushiro: oh i am confused on the error 04:12:34 <njohnston> python-neutronclient CLI will be deprecated in O, which means it will be removed in Q. We can let fwaas v1 CLI attrite out at that time 04:12:41 <SridarK> is it some limitation the string len 04:13:05 <yushiro> SridarK, njohnston : I found some etherpad to integrate from python-neutronclient to OSC plugin. Just a moment, I'll find it. 04:14:01 <yushiro> Anyway, I'll reach out akihiro and hear about it. 04:15:14 <yushiro> OK, let me go back to the discussion b/w v1 and v2. 04:15:27 <SridarK> chandanc_: we can resort to that, i was hoping we can avoid v1 and v2 reference directly in the CLI 04:15:43 <yushiro> First, if the fwaas v1 is enabled, in this case, if we execute "openstack firewallgroup create foo", 04:15:44 <chandanc_> SridarK, totally agree 04:15:45 <SridarK> to the best of my knowledge, i dont think there is a precedence for it 04:16:11 <yushiro> The result is "The resource could not be found.<br /><br /> Neutron server returns request_ids..." 04:16:25 <njohnston> I think we should say that the only CLI for v1 is python-neutronclient, and the only CLI for v2 is OSC. 04:16:49 <SridarK> yushiro: that would be ok correct as v2 is not enabled ? 04:17:11 <yushiro> SridarK: Yes, v2 is not enabled. 04:17:31 <yushiro> njohnston: ah, if so, it is the easiest to understand. v1 -> use python-neutronclient, v2 -> use OSC plugin 04:17:43 <njohnston> precisely 04:17:52 <yushiro> However, some attention is necessary into somewhere document :) 04:18:02 <SridarK> if we can do that then makes it easier 04:18:12 <njohnston> I agree, we will need to document that and let the customers know 04:18:22 <yushiro> OK, I'll reach out akihiro about that. 04:18:23 <njohnston> it also makes it obvious that v2 is the future 04:18:27 <SridarK> one thing is that we have this terminology of firewallgroup introduced in v2 04:18:29 <chandanc_> but it may catch some people by surprise 04:18:43 <SridarK> so we can align our CLI around that 04:19:00 <SridarK> and not use the reference of firewall 04:19:12 <njohnston> chandanc_: I agree, it may... but once we get the CLI set for the way we want, we have the O cycle to message to our users 04:19:43 <SridarK> BTW, this was not my preferred approach to introduce a new notion of firewallgroup but since we are here ... 04:19:52 <xgerman> o/ 04:19:57 <chandanc_> njohnston, I am all in for it, just being careful :) 04:21:04 <yushiro> Thanks all, 1 suggestion. If we use "firewallgroup", how about to align with other resources? like "firewallpolicy", "firewallrule". 04:21:42 <yushiro> e.g. "os firewallgroup create foo", "os firewallpolicy create mypolicy", ... 04:21:54 <xgerman> that’s a lot of typing 04:22:01 <chandanc_> +1 04:22:26 <njohnston> and I think the more natural OSC way would be "openstack firewall group create foo"... "openstack firewall policy create mypolicy" 04:22:45 <njohnston> my only objection to "openstack firewallgroup" is that it is less clear than "openstack firewall". I can imagine a user asking innocently, "Can I use that command if I don't want to create a whole group of firewalls, I just want to create one?" Oh, and it is a lot of typing :-) 04:22:48 <yushiro> xgerman, chandanc_ : indeed! 04:23:27 <yushiro> njohnston: Sure. so... current implementation is as you specified one :) 04:23:32 <SridarK> njohnston: my only concern is that we have no resource called firewall 04:24:36 <yushiro> SridarK: ah, that's a good point. Let's clarify whether "a group of a firewall' or "firewallgroup". 04:25:01 <SridarK> i think the reasons for the naming came from securitygroup 04:25:32 <SridarK> since we refer to a rule in a securitygroup as a securitygroup rule .. 04:25:51 <SridarK> sorry i dont want to come off as being religious here 04:26:21 <njohnston> I would vote to break with SG precedent in this particular case 04:27:01 <SridarK> njohnston: i will not object too much here 04:27:15 <yushiro> SridarK: I noticed that SG in OSC is as follows: security group create 04:27:15 <yushiro> security group delete 04:27:15 <yushiro> security group list 04:27:15 <yushiro> security group rule create 04:27:15 <yushiro> security group rule delete 04:27:16 <yushiro> security group rule list 04:27:17 <yushiro> security group rule show 04:27:19 <yushiro> security group set 04:27:21 <yushiro> security group show 04:27:36 <njohnston> OK, so we are 27 minutes in, let's bring this to a close. I'm not sure we have consensus at this point. 04:27:38 <SridarK> yushiro: ok then that makes sense 04:28:03 <yushiro> njohnston: yes, but please go ahead. Thank you. 04:28:23 <SridarK> njohnston: i think by reflecting our documentation appropriately we will be good 04:29:12 <njohnston> SridarK: I agree. But what did we decide? Should we vote? 04:29:38 <SridarK> i am ok with this security group model 04:29:54 <SridarK> i think we are on the same page here ? 04:29:58 <njohnston> So you would say s/security group/firewallgroup/? 04:30:00 <chandanc_> looks good to me as well 04:30:08 <SridarK> yes 04:30:13 <SridarK> oh 04:30:20 <SridarK> firewall group 04:30:29 <chandanc_> ^ +1 04:30:30 <SridarK> firewall group policy 04:30:32 <njohnston> sure, I am fine with that 04:30:35 <SridarK> firewall group rule 04:30:43 <xgerman> works for me 04:30:56 <yushiro> SridarK: OK, I agree with you. 04:31:06 <njohnston> is there anything that can go after 'firewall' other than 'group'? Just for clarity. 04:31:54 <chandanc_> any think other then group may mean V1, in case we need v1 in OSC 04:32:49 <chandanc_> * anything 04:32:54 <SridarK> chandanc_: yes that can be plan b in case we have to do v1 in OSC even though we prefer not to go there 04:33:07 <chandanc_> yes sure 04:33:23 <xgerman> SridarK +1 04:34:05 <njohnston> OK, so it sounds like we have reached a compromise? 04:34:25 <SridarK> njohnston: are u comfortable with this ? 04:34:26 <chandanc_> i am good with the proposal 04:35:43 <njohnston> I think the word 'group' is extraneous, personally, but I don't care enough to make too big a fuss about it. 04:36:05 <SridarK> yushiro: a discussion with akhiro will be good too, as he provides a good direction in terms of UI 04:36:29 <yushiro> SridarK: thanks. I think so. 04:36:36 <njohnston> +1 04:36:51 <SridarK> ok i think we have enough inputs here 04:37:13 <njohnston> #agreed the base for FWaaS OSC commands will be 'openstack firewall group...' 04:37:17 <SridarK> yushiro: i think once u can get a discussion with akihiro - perhaps u can send us an update via email and move fwd 04:37:36 <yushiro> SridarK: Of course I will :) 04:37:40 <SridarK> yushiro: i know u are working on a tight deadline this week too :-) 04:38:05 <SridarK> ok i think we can move fwd to the L2 parts 04:38:25 <SridarK> padkrish: yushiro: all yours on the agent side of things 04:39:33 <padkrish> SridarK# i have jotted a few points in the etherpad.... working on about retrieving the FWG details tied to a port throughthe RPC 04:39:47 <padkrish> https://etherpad.openstack.org/p/fwaas-v2-l2-agent 04:40:35 <padkrish> basically the implementing the handle_port and delete_port in the fwaas extension 04:42:04 <SridarK> padkrish: ok i think the interesting workflow will be on a VM create - > port create -> get the fwg from plugin - > apply 04:42:05 <yushiro> (Please check "Summary of ..." at the bottom of etherpad) 04:42:05 <padkrish> certain items as jotted in the etherpad are TBD like creating the default FWG that is associated to any port created .. 04:42:51 <padkrish> yes, am in the "get the fwg from plugin" stage...using the Rest calls for testing 04:43:03 <SridarK> padkrish: ok great thx 04:43:09 <padkrish> yes, thanks yushiro :)...it's at the bottom of the etherpad 04:43:32 <padkrish> feel free to expand on the TBD or share all your thoughts in the etherpad 04:43:59 <SridarK> sounds good, padkrish if needed pls send out an email to the team to remind as well 04:44:09 <padkrish> SridarK# sure 04:44:44 <SridarK> we can try to think thru a model for specifying the default FWG (tenant wide or subnet or ... ) 04:45:08 <SridarK> any thing else to discuss on the agent ? 04:45:11 <njohnston> I have heard an appetite for tenant-wide from customers 04:45:21 <xgerman> +1 04:45:36 <SridarK> there we have a plan :-) 04:45:59 <yushiro> Is tenant-wide equal to "public=True"? 04:46:13 <padkrish> SridarK, njohnston# So, a def FWG is always created for a tenant like SecGrp? 04:46:43 <SridarK> yes i think that would be the equivalent 04:46:43 <njohnston> yushiro: no, "public=True" means that another tenant can use it 04:47:00 <xgerman> yes 04:47:06 <yushiro> njohnston: Ok, thank you. I understando. 04:47:13 <yushiro> **understand 04:47:22 <njohnston> :-) 04:47:34 <SridarK> ok good lets move to the driver 04:47:44 <SridarK> chandanc_: pls go ahead 04:48:08 <chandanc_> I updated the conntrack patch for UT 04:48:44 <chandanc_> but it looks like I am hitting some issue due to the fact that contract module is not a singleton and preserves state 04:49:03 <njohnston> does it need a Depends-on for the singleton patch? 04:49:14 <chandanc_> I have pushed the changes to review, will need some help in fixing those 04:49:34 <chandanc_> not really, we need singleton(s) per name space 04:49:53 <chandanc_> sorry singleton per namespace 04:50:33 <chandanc_> njohnston, can you provide me the pointer to singleton patch , i can have alook at it 04:50:56 <chandanc_> I will send a mail with details when i need help with the UT 04:51:21 <njohnston> https://review.openstack.org/#/c/333338/ is the one that used to be titled "IpConntrackManager class in ip_conntrack.py should be a singleton" 04:51:31 <chandanc_> ya 04:52:23 <njohnston> What is the status on https://review.openstack.org/#/c/348177/ ? 04:52:54 <chandanc_> I could not make progress on that one this week 04:53:31 <njohnston> Would it be helpful if I tried to get the tests fixed, or is it not ready for that? 04:53:41 <SridarK> chandanc_: we can continue to push forward on these neutron patches especially 04:53:42 <chandanc_> yes sure 04:54:11 <chandanc_> SridarK, both are neutron patch and kind of related 04:54:22 <njohnston> #action njohnston work on fixing tests for https://review.openstack.org/#/c/348177/ 04:54:26 <SridarK> chandanc_: yes 04:54:31 <SridarK> njohnston: thx 04:54:38 <chandanc_> njohnston, i thnk i need help from you in the ipconntrack patch 04:55:02 <njohnston> chandanc_: Sure thing! How can I help? 04:55:28 <njohnston> chandanc_: The meeting is almost over, shall we convene in #openstack-fwaas afterwords? 04:55:35 <chandanc_> njohnston, there are 5 or 6 UT that fail due to multi-threading 04:55:42 <chandanc_> yes sure 04:55:45 <SridarK> +1 04:55:57 <SridarK> #topic Open Discussion 04:56:19 <njohnston> So a few changes got merged that will affect everyone 04:56:37 <SridarK> njohnston: nice on getting the devstack changes in 04:56:47 <yushiro> thanks :) 04:56:55 <njohnston> https://review.openstack.org/368948 "Integrate neutron-fwaas with neutron-lib CI" - basically this means there is a test in the check gate that checks changes against the current version of neutron-lib 04:56:58 <SridarK> it makes v2 usable in stable/newton 04:57:16 <njohnston> SridarK: Thanks! I think it is a great thing to have. :-) 04:57:27 <njohnston> https://review.openstack.org/368945 "Add Grafana dashboard for FWaaS checks" gives us our own error dashboard! http://grafana.openstack.org/dashboard/db/neutron-fwaas-failure-rates 04:57:40 <xgerman> sweet 04:57:45 <chandanc_> cool 04:57:46 <SridarK> +1 04:57:52 <yushiro> awesome! 04:58:04 <njohnston> And finally, https://review.openstack.org/359320 "Make neutron-fwaas functional job not experimental" means that the functional job is working and voting, so we have HenryG's migration/model sync tests now on check and merge gates. 04:58:18 <njohnston> These are all criteria for stadium inclusion 04:58:25 <SridarK> njohnston: awesome 04:58:31 <njohnston> so I think we are in pretty good standing right now 04:58:56 <SridarK> next week we can focus on other things for Ocata as well 04:59:20 <SridarK> i think we needed to close the CLI today so yushiro can move fwd b4 his PTO and that took some time apologies 04:59:26 <njohnston> There is one more left - https://review.openstack.org/371749 - that will separate out the tempest job, so we will have a tempest run for fwaas v1, and a separate one for fwaas v2 04:59:42 <njohnston> that should help us fix the v2 tempest tests 05:00:04 <njohnston> anyhow, that's all the time we have folks. Thanks very much! Further discussion on #openstack-fwaas. 05:00:09 <njohnston> #endmeeting