14:00:29 <SridarK> #startmeeting fwaas
14:00:35 <openstack> Meeting started Tue Aug  1 14:00:29 2017 UTC and is due to finish in 60 minutes.  The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:38 <TuanVu> Hi everybody
14:00:39 <openstack> The meeting name has been set to 'fwaas'
14:00:54 <SridarK> #chair xgerman_ yushiro
14:00:55 <openstack> Current chairs: SridarK xgerman_ yushiro
14:01:12 <SridarK> Lets get started
14:01:18 <xgerman_> o/
14:01:47 <SridarK> #topic Pike
14:02:27 <SridarK> yushiro: chandanc: how are things looking with the L2 change
14:02:29 <SridarK> s
14:02:54 <yushiro> OK, let me sync up my progress
14:02:57 <yushiro> #link https://review.openstack.org/#/c/323971/
14:03:37 <yushiro> Currently, my patch can work as I expected except illegal case.  Now ready for review.
14:03:53 <chandanc> Sorry got disconnected
14:04:20 <yushiro> Regarding race condition when handle_port, it means VM port creation could avoid by using local vlan manager.
14:05:14 <SridarK> yushiro: ok, still some Jenkins issues
14:05:25 <yushiro> I'm changing Unittest now.
14:05:35 <SridarK> yushiro: ok
14:05:57 <yushiro> In plugin layer, we can call _core_plugin.get_port()  and it can get port_db.
14:06:07 <SridarK> yushiro: yes
14:06:51 <SridarK> ok
14:06:54 <yushiro> However, in unittest, a return value of this method is missing 'binding:xxx' info.  As a result, we cannot get 'binding:host_id' ..
14:07:52 <yushiro> https://review.openstack.org/#/c/323971/39/neutron_fwaas/services/firewall/fwaas_plugin_v2.py
14:07:54 <yushiro> In line 280
14:08:17 <yushiro> In devstack, we can get 'binding:xxx' info by using _core_plugin.get_port().
14:08:42 <yushiro> So, I'll dig more in UT.
14:09:13 <SridarK> yushiro: yes sounds good
14:09:29 <yushiro> In addition, I sent e-mail to folks about deleting firewall group constraint.
14:09:41 <SridarK> would this be the only thing that need to be fixed
14:10:08 <yushiro> yes.
14:10:29 <yushiro> Currently, firewall group can not delete while status is 'ACTIVE'.
14:10:59 <xgerman_> doesn't this make sense
14:11:23 <SridarK> yushiro: yes this will need to be fixed given that our deployment model has changed
14:11:24 <chandanc> what should happen if the vm is deleted ?
14:11:53 <xgerman_> if the vm is deleted the SG still hangs around
14:12:06 <xgerman_> so I would expect the same for FWG
14:12:40 <chandanc> but i think the firewall rules for the port need to be cleaned up
14:12:51 <yushiro> chandanc, If VM is deleted, Vm port also deleted.
14:12:52 <xgerman_> yes —
14:13:00 <chandanc> i hope we dont have a race there
14:13:03 <SridarK> xgerman_: yes but we have slightly different approach mainly due to our L3 legacy
14:13:45 <SridarK> chandanc: yes it may be harmless as the port is gone but still we will have unnecessary rules hanging around
14:13:51 <SridarK> we will need the cleanup
14:14:17 <yushiro> chandanc, xgerman_ yes, when deleting VM instance, currently it raises in neutron-side.
14:14:22 <chandanc> ok, will check if the port id is enough for cleanup
14:14:23 <reedip_> hi
14:14:25 <reedip_> sorry
14:14:30 <SridarK> we will need to check this
14:14:31 <yushiro> I filed a bug report about it.  https://bugs.launchpad.net/neutron/+bug/1707913
14:14:31 <reedip_> really sorry
14:14:32 <openstack> Launchpad bug 1707913 in neutron "OVS driver - OVSFWPortNotFound when deleting VM port affects agent extension framework" [Undecided,New]
14:14:33 <SridarK> chandanc: yes
14:14:56 <xgerman_> +1
14:15:07 <SridarK> ok lets discuss more on this offline
14:15:11 <chandanc> the only thing is the  contrack zone
14:15:21 <SridarK> chandanc: how are things on ur end
14:15:31 <yushiro> chandanc, Yes, please check ovs-ofctl dump-flows br-int
14:15:40 <chandanc> I was with yushiro begining of the week
14:15:53 <chandanc> but couldnot do much for the delete case
14:16:04 <chandanc> we figuredout the create race
14:16:12 <SridarK> chandanc: ok
14:16:53 <SridarK> lets spend a few mins to make a call on L2 support for Pike
14:16:55 <chandanc> i will check how we can escape the delete race
14:17:03 <SridarK> chandanc: ok
14:17:09 <chandanc> ok SridarK
14:17:24 <yushiro> chandanc, I found something delete case.  let's talk after this meeting  if you have time :)
14:17:37 <chandanc> sure
14:17:42 <reedip_> looks like I gained an invisibility cloak before the meeting .... expecto patronum .... !
14:17:53 <SridarK> :-)
14:18:14 <yushiro> reedip_, :)  :)  :)
14:18:21 <xgerman_> :-)
14:18:28 <yushiro> reedip_, you're here :)
14:18:46 <reedip_> Yes, reached a while back
14:18:50 <SridarK> given where we stand do u think it is realistic to push for L2 support ?
14:19:25 <SridarK> at the risk of getting something in where we have not had a chance to do some rigorous testing
14:19:53 <yushiro> SridarK, yes, I'm concern about configurable patch for default fwg.
14:20:36 <xgerman_> if we have it behind a feature flag I am ok with putting it in and saying that support is “experimental”
14:20:47 <reedip_> in one word , no ... in a more descriptive format, considering that its feature freeze, it might introduce some issues
14:21:15 <xgerman_> feature freeze only applies to new features — we still can finish our old ones ;-)
14:21:30 <reedip_> however, we can introduce it as an experimental feature with some configuration option as NO  ( if we set it to yes then we can test the experimental features )
14:21:32 <chandanc> xgerman_: i too am worried about all the delete and default firewall group cases
14:21:44 <reedip_> xgerman_ : L2 and default fwg are new features :)
14:21:56 <xgerman_> yes, but we had patches out for a while
14:22:11 <yushiro> chandanc, deleted by admin?
14:22:38 <xgerman_> so technically they are not affected by feature freeze…
14:22:57 <chandanc> delete port from fwg should move to defaut fwg ?
14:23:05 <SridarK> we can take the approach of "disabled by default"
14:23:06 <chandanc> i am not sure of that use case
14:23:09 <reedip_> xgerman_ though this is a question of perspective, I agree with you that we can push it in P3
14:23:09 <yushiro> chandanc, yes
14:23:33 <chandanc> yushiro: lets speak after this meeting
14:23:38 <SridarK> but still we should feel confident as a team with some level of end to end testing
14:23:39 <yushiro> sure
14:23:46 <reedip_> SridarK : lets take the vote on disabled by default ... what do you say ?
14:24:21 <reedip_> Atleast it would guaruntee that we have time for testing and the feature can still be pushed into pike
14:24:22 <SridarK> reedip_: my thought is that we will need to take this approach without question
14:24:40 <SridarK> but even with that we should not have open issues
14:24:53 <SridarK> esp being a security featue
14:24:56 <SridarK> *feature
14:25:15 <yushiro> reedip_, SridarK sorry for confusing.  I'll do my best until FFE for configurable patch of default fwg.
14:25:38 <SridarK> yushiro: no worries - it is good to have an open discussion
14:25:58 <xgerman_> I am ok to push things with minor known bugs… but I am a bit more aggressive then most ;-)
14:26:33 <SridarK> xgerman_: :-) no i agree as long as we have minor issues with well know caveats that we can release note
14:26:34 <reedip_> :)
14:27:26 <xgerman_> in any case we need to closely coordinate with Neutron since they are doing the release and have our FFEs filed, etc.
14:27:56 <yushiro> SridarK, xgerman_ 1 question.  Should we send e-mail about FFE on ML?
14:28:00 <SridarK> and definitely realistically we all have been juggling multiple things so the bandwidth allocation has been a challenge for all
14:28:07 <chandanc> So if we disable l2 by default, will the cli disable creation of FWG with l2 ports ?
14:28:28 <SridarK> chandanc: good point
14:28:35 <reedip_> chandanc : CLI should check if L2 is available
14:28:47 <SarathMekala> even the UI has to take this into account
14:28:57 <chandanc> reedip_: yes thats what i ment
14:29:02 <SridarK> chandanc: we can always fail the validation in the plugin
14:29:05 <reedip_> can be possible if it is created as an extension :(
14:29:11 <chandanc> or just ignore l2 ports ?
14:29:18 <xgerman_> yes, if it’s an extension we cna check
14:29:32 <xgerman_> otherwise we throw errors and user exp sucks
14:30:01 <reedip_> chandanc : does it have to be a major change to make an extension out of the L2 FWG ?
14:30:15 <chandanc> Do we have a separate extension for l2 only ports
14:30:17 <SridarK> hmm as an ext - it is really the attributes
14:30:34 <SridarK> that can be tricky as it is still a port attribute
14:30:36 <xgerman_> you can have everyhting as an ext
14:30:46 <chandanc> i think the extension is fwaas_v2
14:30:49 <reedip_> I mean, enable L2 FWG if the extension is loaded ?
14:30:51 <reedip_> If it is not loaded ,then the CLI/UI can handle the error
14:30:53 <chandanc> i may be wrong
14:31:10 <yushiro> extensions = fwaas_v2  should be set in ml2_conf.ini  in order to run l2 support
14:31:19 <reedip_> chandanc : patch ID  ( I forgot the link )
14:31:21 <xgerman_> no, in LBaaS I once wrote an extension to enable cascading delete (one flag was set to true)
14:31:50 <xgerman_> yushiro that is the plugin
14:31:51 <SarathMekala> I was also wondering if a flag can be used for this
14:31:57 <xgerman_> extension is the API we support
14:32:01 <chandanc> reedip_: dont have it handy, will mail
14:32:11 <SridarK> i think the simplest thing to do is to check if the L2 driver is loaded, then the plugin will allow L2 ports in the validation
14:32:14 <reedip_> lemme check the gitreview
14:32:49 <SridarK> else it will fail the validation and throw an exception or log message
14:32:54 <chandanc> SridarK: so the check is at plugin level right ?
14:32:56 <reedip_> chandanc : this one right : https://review.openstack.org/#/c/447251/ ?
14:33:00 <SridarK> chandanc: yes
14:33:01 <xgerman_> extensions from LBaaS: https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/extensions
14:33:28 <xgerman_> any API change is an extension
14:33:33 <chandanc> So here is my understanding
14:33:37 <yushiro> SridarK, +1  OK, I'll add a validation to check l2 driver condition.
14:34:04 <chandanc> the fwaas v2 has a single extension, but we want to disable l2 ports in fwaas v2
14:34:20 <chandanc> i think , this can be done at plugin level right ?
14:34:50 <chandanc> the extension needs to be loded to supported event the l3 ports
14:34:57 <xgerman_> I think we are confuding two things:
14:35:02 <yushiro> chandanc, plugin side and agent side .
14:35:07 <xgerman_> 1) Does the API support L2 -> Extensions
14:35:10 <chandanc> plugin side
14:35:17 <xgerman_> 2) Is L2 working -> plugin
14:35:52 <reedip_> yushiro , chandanc : we are looking at this right ?? : https://review.openstack.org/#/c/323971/
14:36:28 <yushiro> reedip_, right.  Maybe we call it 'L2 driver'
14:36:33 <chandanc> Sorry still abit confused, if this is too confusing, we can discuss by mail
14:36:49 <reedip_> yushiro  :yes, this isnt an extension per-se
14:37:21 <yushiro> reedip_, yes, xgerman_ explains 'extensions' for fwaas.
14:37:21 <SridarK> since the attribute in question is port, and our ext defines it already, we are only qualifying if it is L2 or L3
14:37:26 <reedip_> chandanc  : currently what we have is more of a driver. We are not adding anything to the fwaas_v2 API attribute, are we ?
14:37:51 <yushiro> SridarK, correct.
14:37:56 <chandanc> reedip_: yes, this is my point
14:37:57 <SridarK> reedip_: yes nothing is being added to the API as it is still a port attribute
14:38:13 <reedip_> SridarK : Is there any parameter which seprates an L2 port from an L3 port?
14:38:18 <reedip_> or any attribute ??
14:38:25 <reedip_> chandanc :: ^^
14:38:30 <xgerman_> well, they sometimes have dummy extensions since drivers can say which etxnesions they support
14:38:36 <SridarK> reedip_: it will be the device owner
14:38:53 <yushiro> xgerman_, you mean 'noop' driver ?
14:39:05 <SridarK> u will need to examine the port resource to determine to figure if it is L2 or L3
14:39:13 <reedip_> SridarK : so it means the value may be changed but the APU attribute would be the same
14:39:14 <xgerman_> no, an extension which doesn’t define any attributes and drivers say they support that
14:39:29 <yushiro> OK
14:39:49 <SridarK> xgerman_: basically an ext that will define a flag for L2 support
14:39:57 <xgerman_> yep
14:39:59 <chandanc> xgerman_: something like fwaas_v2_l2_support ?
14:40:10 <reedip_> chandanc : that will be too complicated
14:40:11 <xgerman_> and then the driver says it supports/doesn’t support that extension
14:40:25 <reedip_> xgerman : thats a much easier option
14:40:40 <xgerman_> yeah, but I think checking if the l2 is loaded is prob. better
14:41:08 <xgerman_> since a driver might support L2 but L2 isnt laoded
14:41:16 <SridarK> xgerman_: that would be simpler from code
14:41:28 <yushiro> but current l2 is only agent-side definition.  I'll consider to check server-side as well as agent-side.
14:41:50 <chandanc> we need server side
14:41:51 <SridarK> yushiro: yes that is the downside - we will need to check on the server side too
14:42:03 <reedip_> yushiro : if the Extension is loaded, then we can pull up the agent-side code, right ?
14:42:06 <SridarK> to enable the validation to be done
14:42:12 <yushiro> SridarK, +10
14:42:43 <yushiro> reedip_, maybe yes and we can validate it in server-side.
14:42:51 <xgerman_> but overall we should make an L2 extnesion since there might be 3rd party drivers whoch don’t support L2
14:43:04 <reedip_> yushiro : yes ...
14:43:19 <reedip_> xgerman_ : right :)
14:43:26 <SridarK> xgerman_: yes i think that is good so validation is done early
14:43:48 <SridarK> and 3rd parties can reuse the reference plugin
14:43:53 <yushiro> yes. or we can create 'noop' driver for l2.
14:44:27 <reedip_> ok , so we are agreed upon creating the extension
14:44:32 <SridarK> ok lets weigh some of these options
14:45:34 <SridarK> but still lets see how confident we are with an end to end test to atleast have the basic use cases working
14:45:38 <reedip_> SridarK : Lets put it on the mail
14:46:24 <SridarK> assuming we feel confident about that - we can adopt using an ext or just checking for an L2 driver
14:47:00 <xgerman_> or both
14:47:14 <SridarK> off the top the checking for the L2 driver is easier from a code point of view this late in the game, but long term the ext makes it more cleaner
14:47:52 <yushiro> OK.
14:47:54 <SridarK> having an ext serve as an enable will make reuse of the plugin more clean
14:48:01 <yushiro> will implement validation.
14:48:01 <xgerman_> yes, but if we release without extension we can’t add it later since we are taking functionality away instead of adding
14:48:03 <chandanc> +1
14:48:47 <xgerman_> I am not sure if Neutron will actually enforce that with us…
14:48:55 <SridarK> xgerman_: hmm perhaps we will have the functionality but we realise it differently
14:49:05 <SridarK> first with a quick hack then with an ext
14:49:11 <xgerman_> k
14:49:19 <SridarK> xgerman_: but good point - let me think more too
14:49:42 <SridarK> but mainly lets see how confident we are with the L2 agent - driver integration
14:49:50 <xgerman_> +1
14:49:52 <SridarK> ok lets take it offline
14:50:00 <SridarK> running out to time
14:50:07 <SridarK> #topic Horizon
14:50:23 <SarathMekala> I have some updates
14:50:27 <SridarK> SarathMekala: amotoki: pls go ahead
14:50:49 <SarathMekala> I am working on the add/remove port forms
14:51:14 <SarathMekala> and looking at the UI, I am opting for the following approach
14:51:36 <SridarK> SarathMekala: ok do u need to ask for an FFE - i think there is less concerns here
14:51:48 <amotoki> I added devstack support to SarathMekala patch
14:52:05 <SridarK> amotoki: great thx
14:52:06 <amotoki> I am not sure we can land the v2 patch in FFE time frame even though it is low-risk
14:52:41 <amotoki> as far as i checked, the current UT proposed is just a copy from v1 stuff and there seems a lot of work to pass UT
14:53:03 <SridarK> amotoki: ok i was hoping that this is definitely low risk as u mention
14:53:24 <SarathMekala> amotoki, yes.. I did not update the UT yet
14:53:54 <amotoki> if the team would like to request FFE for v2 dashboard, please go ahead
14:54:04 <SridarK> SarathMekala: do u feel comfortable to get this done - it should get an FFE with amotoki's support too
14:54:15 <yushiro> +1
14:54:17 <amotoki> it is better to follow the official neutron stadium process as it is a project under neutron
14:54:27 <SridarK> +1
14:54:36 <SarathMekala> sure SridarK, I will sync with amotoki and send across a mail to the team
14:54:56 <amotoki> i would like to see extensive tests from fwaas team
14:55:16 <SridarK> SarathMekala: ok perfect and u should be present in the drivers team mtg too
14:55:19 <SridarK> amotoki: +1
14:55:30 <SarathMekala> ok.. I need to put in a few more UI design considerations for review here
14:55:42 <SridarK> SarathMekala: we will start doing some manual testing
14:55:42 <SarathMekala> sure SridarK
14:55:48 <yushiro> SarathMekala, thanks for your great work :)
14:55:58 <SarathMekala> I will ping you offline
14:55:59 <SridarK> SarathMekala: go ahead pls - we only have 5 mins
14:56:11 <SarathMekala> sure
14:56:13 <SridarK> we can continue on fwaas channel if we hit time
14:56:26 <SarathMekala> sure.. I have a few things to discuss
14:56:41 <SarathMekala> In the FWG tab, the row actions will be the following
14:56:54 <SarathMekala> update FwG, Delete FWG, Add Port and Delete Port
14:57:24 <SarathMekala> I am thinking adding Add Ingress Policy, Delete Ingress Policy
14:57:33 <SarathMekala> as well as Egress Policy actions will be a bit too much
14:57:56 <SarathMekala> so Ingress/Egress policy addition/deletion can be done during FWG edit operation
14:58:06 <yushiro> SarathMekala, +1
14:58:08 <SridarK> SarathMekala: we could have policy and a selector for Ingress or Egress ?
14:59:07 <SarathMekala> SridarK, a selector is present.. but for updating I dont want to add it as a row btn action
14:59:21 <SridarK> SarathMekala: ok
14:59:28 <SarathMekala> so effectively, to update ingress/egress policies we need to update the FWG
14:59:34 <SridarK> we are almost at time
14:59:34 <amotoki> I think it is better to gather feedbacks for improvements from fwaas team after running the dashboard (using something like etherpad)
14:59:38 <yushiro> correct
14:59:41 <SarathMekala> but add/delete ports will be similar to insert rules
14:59:54 <SarathMekala> amotoki, +1
14:59:55 <SridarK> lets continue on fwaas channel
14:59:59 <SarathMekala> sure
15:00:03 <amotoki> points from SarathMekala coves a few I think
15:00:04 <yushiro> OK, let's move on :)
15:00:14 <amotoki> *covers*
15:00:20 <SridarK> thx all for joining - priorites is to get L2 support decisions and defn try to get in Horizon
15:00:29 <SridarK> #endmeeting fwaas