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