14:03:37 <SridarK> #startmeeting fwaas
14:03:38 <openstack> Meeting started Thu Feb  1 14:03:37 2018 UTC and is due to finish in 60 minutes.  The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:42 <openstack> The meeting name has been set to 'fwaas'
14:03:52 <xgerman_> #topic Announcements
14:04:02 <SridarK> amotoki: ah ok thx - sorry i just got up so have not gone thru email yet
14:04:11 <SridarK> #chair xgerman_
14:04:12 <openstack> Current chairs: SridarK xgerman_
14:04:21 <SridarK> xgerman_: pls go ahead
14:04:23 <xgerman_> #link #topic Announcements
14:04:27 <xgerman_> #link http://superuser.openstack.org/articles/firewall-service-openstack/
14:04:39 <SridarK> xgerman_: +1 great
14:04:43 <amotoki> good writing xgerman_ chandanc
14:04:45 <annp> +1
14:04:53 <xgerman_> chandanc: +1
14:04:55 <chandanc> thanks all and xgerman_
14:05:08 <SridarK> xgerman_: chandanc: thx
14:05:42 <xgerman_> RC-1 is next week - I haven’t heard from Neutron how many RCs they are planning but…
14:06:28 <xgerman_> if we get bug fixes in in the next few days they might make it
14:06:42 <amotoki> no strict plan. RC1 will be cut as usual
14:06:50 <SridarK> ok
14:06:57 <amotoki> more RC(s) are on-demand and depending on critical bugs
14:07:16 <SridarK> shall we get into some outstanding issues
14:07:29 <xgerman_> PTG prices are going up BTW today
14:07:48 <xgerman_> #topic Queen Bugs/Outstanding issuesd
14:07:49 <SridarK> xgerman_: +1 thx
14:07:56 <annp> SridarK: +1
14:08:14 <xgerman_> thanks amotoki
14:08:14 <SridarK> i think we have 2 issues
14:08:45 <SridarK> xgerman_: sorry go ahead pls drive
14:08:49 <xgerman_> ok
14:09:04 <xgerman_> #link https://review.openstack.org/539461
14:09:21 <xgerman_> there is a problem with auto-associate for the firewall
14:09:39 <xgerman_> and
14:09:42 <xgerman_> #link https://review.openstack.org/536234
14:10:12 <xgerman_> I think both are pretty close but need some more work
14:10:21 <SridarK> +1
14:10:25 <chandanc> +1
14:10:52 <annp> xgerman_, Yes. I have to test more careful. So sorry about previous patch
14:11:28 <SridarK> annp: no worries - good that we have fix in the works
14:11:33 <xgerman_> +1
14:11:46 <xgerman_> at least we found it before the release which is huge!
14:11:47 <annp> thanks SridarK
14:11:51 <chandanc> agree
14:12:17 <SridarK> On 536234 - this will prevent that one combination in the support matrix table
14:12:31 <SridarK> so with that we should be covered
14:12:48 <xgerman_> yes, that is my understanding…
14:13:04 <SridarK> and once ur fix for the auto-associate is done we are in good shape
14:13:22 <annp> SridarK +1
14:13:26 <xgerman_> +1
14:13:27 <SridarK> IMHO, 539461 is the higher priority
14:13:59 <xgerman_> I am confident we can get both in before release. Worst case we ask for another RC
14:14:09 <SridarK> the other one can be a potential documentation - worst case - i think u are in good shape to get it in
14:14:14 <SridarK> xgerman_: +1
14:15:01 <annp> xgerman_: i believe we can get merge both patch on tomorrow or next few days.
14:15:10 <SridarK> annp: +1
14:15:17 <xgerman_> annp: +1
14:16:17 <annp> thanks. chandanc: can you help me test 539461 in your environment?
14:16:45 <xgerman_> we all should test + verify amotoki ’s problem earlier in the channel
14:16:47 <chandanc> sure will test
14:17:02 <xgerman_> #link http://paste.openstack.org/show/658314/
14:17:14 <amotoki> xgerman_: I am now testing with neutron-fwaas devstack only.
14:17:25 <annp> chandanc, thanks a lot. :)
14:17:30 <xgerman_> amotoki: thanks
14:17:45 <amotoki> previously I enalbed both neutron-fwaas and vpnaas. I am testing with neutron-fwaas only to identify the problem
14:18:10 <amotoki> my devstack just stoped with the same error :(
14:18:13 <amotoki> will investigate more
14:18:47 <xgerman_> ok, thanks — we definitely need to make sure we didn’t break devstack…
14:19:08 <chandanc> 2018-02-01 13:50:16.085 | tee: etc/neutron/plugins/ml2/ml2_conf.ini: No such file or directory
14:19:09 <hoangcx_> amotoki: https://review.openstack.org/#/c/527040/
14:19:20 <chandanc> missing / ?
14:19:37 <hoangcx_> amotoki: Maybe you encountered same issue with me
14:19:51 <amotoki> it is missing a leading / but
14:20:01 <amotoki> NEUTRON_CONF_DIR is defined with / in devstack
14:20:09 <amotoki> so I am wondering what's wrong
14:20:25 <xgerman_> mmh
14:20:39 <amotoki> note that i am not using neutron-*. I use default q-* now.
14:20:42 <chandanc> variable not sourced properly may be
14:20:55 <chandanc> will test
14:20:58 <hoangcx_> amotoki: same here. I use q-*
14:21:20 <amotoki> let's share info if we have more after the meeting
14:21:28 <xgerman_> +1
14:21:31 <annp> +1
14:21:58 <amotoki> I am facing this issue for several weeks and did not fwaas for weeks due to this :(
14:22:16 <amotoki> btw, I have one more thing to ask.
14:22:16 <xgerman_> yeah, we need to get to the bottom of this
14:22:28 <xgerman_> sure, go ahead
14:22:31 <amotoki> I would like to know what is remaining to complete https://blueprints.launchpad.net/neutron/+spec/fwaas-api-2.0
14:23:00 <amotoki> I think the drivers team will discuss queens blueprints in tomorrow meeting.
14:23:08 <amotoki> some status update would be appreciated.
14:23:14 <xgerman_> we tried to mark it complete but didn’t have access
14:23:30 <amotoki> xgerman_: i think everyone can update the whiteboard
14:24:07 <SridarK> amotoki: there are probab a few items there which are a bit more futuristic - will be good to have some use cases before we prioritize
14:24:33 <xgerman_> let’s close that one and file new one for additional features
14:24:50 <SridarK> but i think with L2 support we are quite complete
14:25:16 <SridarK> xgerman_: i think the Remote FWG that u started is possibly the one thing that is realistic needed in the near term
14:25:30 <SridarK> xgerman_: yes i agree - we can put some notes and Close it
14:25:37 <amotoki> SridarK: xgerman_: can't we file anotehr blueprint on that?
14:25:38 <xgerman_> +1
14:25:45 <xgerman_> yes, we can
14:25:45 <SridarK> amotoki: +1
14:26:01 <SridarK> amotoki: so for status i think we can call it complete
14:26:19 <annp> +1
14:26:19 <amotoki> SridarK: xgerman_: could you add some note to the top of the whiteboard of the BP?
14:26:25 <SridarK> L2 support was the main outstanding item
14:26:35 <xgerman_> I added COPLETED ;-)
14:26:35 <SridarK> amotoki: sure
14:26:44 <amotoki> SridarK: thanks!
14:27:16 <amotoki> I see COMPLETED, yay :)
14:27:21 <xgerman_> :-
14:27:23 <annp> :)
14:27:23 <xgerman_> )
14:28:25 <xgerman_> #todo (xgerman) File Blueprint for remote FWG
14:29:10 <xgerman_> but let’s talk in a few weeks what other features we want for R (e.g. address group)
14:29:53 <SridarK> xgerman_: +1
14:30:14 <SridarK> i would also think to revisit the requirements
14:30:29 <xgerman_> +1
14:30:59 <xgerman_> #topic Documentation
14:31:36 <xgerman_> A while back we decided to go in-tree with that
14:32:08 <xgerman_> and we should have something up before Q gets released…
14:32:45 <xgerman_> (at least our compatibility matrix)
14:33:11 <chandanc> +1
14:33:30 <SridarK> And will have time - does this land in like bug fixes ?
14:33:40 <SridarK> *do we have time
14:34:15 <xgerman_> Technically they can publish anytime but they version
14:34:33 <xgerman_> amotoki: wondering if you know more about that process
14:35:12 <xgerman_> no worries
14:35:33 <amotoki> it looks like about doc process
14:35:47 <xgerman_> yes, how long do we have for Queen docs?
14:35:51 <amotoki> in general feature freeze is not applied to doc
14:36:07 <SridarK> amotoki: ok
14:36:28 <amotoki> we can update our docs in master and backport them after stable/queens is cut.
14:36:38 <SridarK> amotoki: ah ok
14:36:38 <xgerman_> sweet
14:37:38 <SridarK> we will need to evaluate if some other ground work in needed for in tree docs
14:38:06 <xgerman_> I think we have the skeleton… need to see if we have a doc job…
14:38:16 <SridarK> ok
14:38:44 <amotoki> looking at fwaas v2 section in the networking guide, i think we need some basic information about fwaas v2 concept
14:38:52 <amotoki> as explained in the superuser blog.
14:38:53 <xgerman_> +10
14:39:23 <SridarK> amotoki: yes agreed - i think we need to lay some foundational things on differences btwn L3 and L2
14:39:33 <SridarK> otherwise the API is the same
14:39:34 <annp> +1
14:39:40 <amotoki> if you want, you can maintain your docs in neutron-fwaas repo. it is up to individual teams
14:39:53 <xgerman_> we like in-tree
14:40:18 <amotoki> you can choose etther neutron in-tree or neutron-fwaas in-tree docs.
14:40:22 <xgerman_> I also think we need a cookbook style guide with use cases
14:40:46 <amotoki> if the latter, we can add a link to the netwokring guide and/or installation guide.
14:41:02 <xgerman_> we aim for neutron-fwaas-in-tree
14:41:21 <xgerman_> amotoki: sounds good
14:41:56 <SridarK> amotoki: if we are in tree - how will the doc get rendered for a user ?
14:42:10 <SridarK> Will there be a separate guide for fwaas
14:42:30 <xgerman_> #link https://github.com/openstack/neutron-fwaas/tree/master/doc/source
14:42:32 <SridarK> or will it still get rendered as part of networking guide with content coming from fwaas repo
14:42:54 <amotoki> SridarK: yes. it will be puslished at docs.o.o/neutron-fwaas/latest or neutron-fwaas/queens/
14:43:30 <amotoki> so we need some guide links in networking guide in that case so that reader can easily find contents
14:43:31 <SridarK> So for the users - it will be separate guide ?
14:43:49 <amotoki> at now it will be a separate guide
14:43:50 <SridarK> amotoki: ok so there will be link we need in the networking guide
14:44:23 <SridarK> but if we put it in neutron - it will show up as a chapter in the networking guide
14:44:24 <amotoki> i think the toc of networking guide needs to be improved a bit
14:44:54 <amotoki> SridarK: exactly if we put it in neutron
14:45:10 <SridarK> amotoki: ok thx
14:45:20 <amotoki> sfc/vpnaas/bgpvpn/dynamic-routing have similar problems
14:45:44 <SridarK> xgerman_: do u think it will be better if we put it in neutron so it is more cohesive with the networking guide
14:46:03 <SridarK> or rather all subprojects should follow a consistent model
14:46:46 <SridarK> amotoki: may be we should strive for consistency with the other projects - all of us should adopt the same approach
14:46:49 <xgerman_> yes, consitency is good but I think having the docs in our tree gives us more autonomy
14:47:16 <xgerman_> but I am good with whatever standard we come up with
14:47:19 <amotoki> SridarK: at now there is no guideline on this according to what we discussed at Denver.
14:47:34 <SridarK> amotoki: ok
14:48:29 <amotoki> i think either approach works. most important is to write contents :)
14:48:39 <SridarK> that i agree :-)
14:48:51 <hoangcx_> amotoki: If so, I think neutron doc liaison should define some detail guideline for all subprojects to follow. though?
14:49:15 <amotoki> hoangcx_: true to some extent :p
14:49:27 <amotoki> boden is a current liaison
14:49:45 <amotoki> I am involved in the process much too
14:49:56 <SridarK> While we work thru that - let me take an action to review what we have and start pulling some things together
14:50:13 <xgerman_> yeah, I was thinking about writing as well
14:50:30 <SridarK> xgerman_: surely - lets sync up offline
14:50:35 <xgerman_> +1
14:50:46 <xgerman_> #topic Open Discussion
14:50:57 <annp> I have one
14:51:12 <xgerman_> go ahead
14:51:14 <SridarK> chandanc: Thanks for getting this in https://review.openstack.org/#/c/538154/
14:51:39 <annp> chandanc, xgerman_, sridark: Related to detect sg enable email thread
14:51:46 <chandanc> SridarK: ya i am close but still stuck with merging
14:52:27 <annp> Shall we go with my draft idea for default fwg to resolve problem of sg=noop and fwaas=ovs?
14:52:40 <chandanc> annp: +1
14:52:58 <SridarK> annp: u mean https://review.openstack.org/#/c/536234/
14:53:02 <annp> If so, I think we should remove the option https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L39
14:53:25 <amotoki> what does sg=noop mean?
14:53:47 <xgerman_> there is a noop driver for SG
14:54:20 <amotoki> so will SG be disabled?
14:54:21 <annp> SridarK, No related to 536234
14:54:32 <xgerman_> we have this as an option
14:54:43 <SridarK> annp: yes
14:54:50 <xgerman_> an operator can choose to enable SG, FW, or both
14:54:59 <annp> amotoki: I mean we set firewall_driver of security group is noop
14:55:00 <xgerman_> (or none)
14:55:10 <amotoki> I see.
14:55:57 <annp> if we go with my draft idea i think we should remove option auto_associate_default_fwg
14:56:17 <amotoki> there is 'enable_security_group' option in securitygroups_rpc.py
14:56:17 <annp> and revert https://github.com/openstack/neutron-fwaas/commit/e5f5c3f44531d2b6c9d813bc8f6d69e685af8c14 this patch
14:56:25 <xgerman_> mmh, there was a use case where people wanted FWaaS but only on ports they choose
14:56:45 <annp> Because I don't want to change behavior of user.
14:57:42 <xgerman_> I am not 100% in that camp so removing would be ok for me
14:57:45 <chandanc> annp: i agree , as soon as the DFWG fix patch goes in
14:57:52 <xgerman_> SridarK: thoughts?
14:58:30 <SridarK> yes we went thru to have some  option for users
14:58:37 <annp> I means fwaas api only allow admin to set or unset port to default fwg
14:59:33 <amotoki> annp: doesn't it depend on operators' choice?
14:59:34 <annp> if user want to use security group only, i think user should contact with admin
15:00:15 <SridarK> if some one does not want to associate the default fwg - then they are relying on SG
15:00:29 <chandanc> annp: in either case he needs to contact admin
15:00:36 <SridarK> or they really know what they are doing and relying on perimeter security
15:00:38 <xgerman_> yes, the thought of the switch was that operators would be reluctant to switch something on which alters all their ports and wanted to go at a slower pace
15:00:49 <annp> amotoki: sorry, can you explain more your question?
15:00:56 <annp> chandanc: +1
15:01:21 <amotoki> annp: no problem. I feel there seems several use cases on who can control FWG.
15:02:07 <amotoki> annp: my point is what happens if operators allow users to configure default FWG by policy.
15:02:44 <amotoki> annp: but it depends on usecases and we need to summarize usecases. then we can clarify what is the first target.
15:03:01 <xgerman_> yeah, I think we need to release and see what the field is doing…
15:03:31 <xgerman_> anyhow we are at time…
15:03:39 <amotoki> hehe
15:03:41 <SridarK> lets continue in channel
15:03:47 <annp> amotoki: can we discuss after meeting?
15:03:52 <amotoki> annp: sure
15:03:57 <annp> thanks.
15:03:59 <xgerman_> I gotta run but will be back in like 30-45 minutes
15:04:06 <xgerman_> #endmeeting