Thursday, 2018-02-01

*** threestrands has joined #openstack-fwaas02:27
*** threestrands has quit IRC02:27
*** threestrands has joined #openstack-fwaas02:27
*** annp has joined #openstack-fwaas02:34
*** yamamoto has joined #openstack-fwaas02:37
openstackgerritTuan Luong-Anh proposed openstack/neutron-fwaas master: Enable hacking-extensions H204, H205  https://review.openstack.org/53977602:47
*** hoangcx has quit IRC03:18
*** hoangcx has joined #openstack-fwaas03:18
*** chandanc has joined #openstack-fwaas04:58
chandancHello yushiro04:58
*** chandanc_ has joined #openstack-fwaas05:08
*** chandanc has quit IRC05:08
*** chandanc_ is now known as chandanc05:08
yushirohi chandanc05:46
chandancHello yushiro05:46
yushirochandanc, Thanks for your great work for CT_zone patch.05:46
chandancwanted to know how to get the workflow on the patch05:46
chandancthanks yushiro :)05:46
yushiro2 days ago, Akihiro and I talked about your patch and he discussed in neutron driver team.05:47
chandancis it automatic or do i need to ping someone ?05:47
chandancoh ok, thanks for the help05:47
*** threestrands has quit IRC05:48
chandancif i need to ping someone, who would be the right person ?05:49
yushirochandanc, OK, just a moment.05:49
chandancsure05:49
yushirochandanc, I think this bug has been set 'queens-rc1' So, the deadline is maybe Feb 05 (https://releases.openstack.org/queens/schedule.html)05:52
yushirochandanc, So, currently, it's OK to wait I think.05:53
chandancok05:53
chandancsure05:53
yushirochandanc, Now, I and annp are trying to fix auto-association patch(https://review.openstack.org/#/c/539461/05:54
chandancya i saw that yushiro05:54
yushiroAlso, thanks for your review :)05:54
chandanci will have to read the code more carefully :)05:55
yushiroThanks.05:55
yushiroA point is a timing 'newly created VM port'05:55
yushiro@registry.receives(resources.PORT, [events.AFTER_CREATE])  handles newly created port but there is no way to judge this is VM port or not.05:56
chandanchmm, i think the patch is now looking for the owner attribute right ?05:57
yushirochandanc, correct.05:58
yushiroHowever, it is not enough only checking 'device_owner'05:58
chandancs what else need to be taken care of ?05:59
yushiroI think it is also necessary to check 'binding:vif_type'.05:59
chandancovs vs LB ?06:00
yushiroNewly created VM port is handles as follows:   1.created(binding:vif_type = 'unbound') -->  update_port( called bind_port and associated binding:vif_type = 'ovs')06:00
chandanchmm, in that case is it not better to listen for port update events ?06:01
chandancand specifically for a transition from “unbound” to “ovs”06:02
yushirochandanc, no-no.  It's OK to listen update events.  In this timing, argument 'kwargs' includes 2 kind of port information.  current port dict(after updated) and original port dict(before updating)06:02
chandancyes, so the orig_port vif==unbound and cur_port.vif==ovs check06:04
chandancthat should be good enough ?06:04
yushirochandanc, Indeed!!06:04
yushirochandanc, and check 'device_owner' starts 'compute:...'06:04
chandancyes06:04
yushiroBTW, I saw my friends on this docment :)  Congrats.   http://superuser.openstack.org/articles/firewall-service-openstack06:11
yushirochandanc, xgerman_ :)06:11
chandancya it happened yesterday06:12
chandanci have put it on linkedin :)06:13
yushiroOh, sure.  I'll put +1 in linkedin ;)06:19
chandanccool :)06:20
openstackgerritNguyen Phuong An proposed openstack/neutron-fwaas master: Fix auto associate default fwg  https://review.openstack.org/53946106:49
annpyushiro, chandanc, hi06:51
annpyushiro, chandanc: I've just updated auto associate default fwg. Could you have a look at it?06:53
yushiroSure06:59
*** yushiro is now known as yushiro_afk06:59
annpyushiro: Regarding to check 'vif_type'=ovs or lb. It should cover in https://review.openstack.org/#/c/536234/, Do you think so?07:01
*** AlexeyAbashkin has joined #openstack-fwaas07:18
*** hoangcx has quit IRC07:33
*** annp has quit IRC07:33
*** hoangcx has joined #openstack-fwaas07:33
*** annp has joined #openstack-fwaas07:33
*** AlexeyAbashkin has quit IRC07:37
*** AlexeyAbashkin has joined #openstack-fwaas07:50
yushiro_afkannp yes, but it should be separated by usage.07:53
*** yushiro_afk is now known as yushiro07:53
yushiroa07:53
annpyushiro, Thanks for your comments. I'm updating the patch as your suggestion. I will let you know later.07:59
yushiroannp, oK.  I think it's better to be merged this bug first.08:00
annpyushiro, it's better to be merged both patch.08:01
yushiroannp, yes, I said its priority.08:01
yushiroI think this bug is critical08:02
annpyushiro, Got it. I'd like to get both patch in Q-RC1 if possible.08:02
openstackgerritNguyen Phuong An proposed openstack/neutron-fwaas master: Fix auto associate default fwg  https://review.openstack.org/53946108:24
*** reedip has quit IRC08:48
openstackgerritNguyen Phuong An proposed openstack/neutron-fwaas master: Fix auto associate default fwg  https://review.openstack.org/53946110:22
*** AlexeyAbashkin has quit IRC10:28
*** AlexeyAbashkin has joined #openstack-fwaas10:53
openstackgerritNguyen Phuong An proposed openstack/neutron-fwaas master: Add checking whether a port is supported by FWaaS L2 driver or not  https://review.openstack.org/53623410:56
*** annp has quit IRC10:57
*** Aju has joined #openstack-fwaas11:09
*** chandanc has quit IRC11:09
*** afranc has quit IRC11:11
*** AlexeyAbashkin has quit IRC11:33
*** AlexeyAbashkin has joined #openstack-fwaas11:33
*** AlexeyAbashkin has quit IRC12:35
*** AlexeyAbashkin has joined #openstack-fwaas13:13
amotokihi, when I enable neutron-fwaas devstack plugin, I got the following error13:29
amotoki2018-02-01 13:20:28.683 | +functions-common:run_plugins:1668         [[ -f /opt/stack/neutron-fwaas/devstack/plugin.sh ]]13:29
amotoki2018-02-01 13:20:28.687 | +functions-common:run_plugins:1669         source /opt/stack/neutron-fwaas/devstack/plugin.sh stack post-config13:29
amotoki2018-02-01 13:20:33.281 | tee: etc/neutron/plugins/ml2/ml2_conf.ini: No such file or directory13:29
amotoki2018-02-01 13:20:33.284 | Error on exit13:29
amotokiIs it only for me?13:29
amotokimore detail log with xtrace http://paste.openstack.org/show/658314/13:54
*** yamamoto has quit IRC13:55
*** SridarK has joined #openstack-fwaas13:58
*** annp has joined #openstack-fwaas13:58
*** hoangcx_ has joined #openstack-fwaas14:00
SridarKHi FWaaS folks14:00
xgerman_Hi14:00
SridarKI think yushiro it is ur turn to run the mtg14:01
annphi14:01
SridarKthx for updating the etherpad14:01
xgerman_is he here?14:02
*** chandanc has joined #openstack-fwaas14:02
SridarKi see him online14:02
chandanchello all14:02
SridarKlets give him a minute14:02
amotokihi14:02
xgerman_ok14:02
SridarKyushiro: ping14:02
SridarKok maybe we can get started14:03
amotokiSridarK: yushiro sends a mail that he cannot join today's meeting14:03
SridarK#startmeeting fwaas14:03
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:03
*** openstack changes topic to " (Meeting topic: fwaas)"14:03
openstackThe meeting name has been set to 'fwaas'14:03
xgerman_#topic Announcements14:03
SridarKamotoki: ah ok thx - sorry i just got up so have not gone thru email yet14:04
SridarK#chair xgerman_14:04
openstackCurrent chairs: SridarK xgerman_14:04
SridarKxgerman_: pls go ahead14:04
xgerman_#link #topic Announcements14:04
xgerman_#link http://superuser.openstack.org/articles/firewall-service-openstack/14:04
SridarKxgerman_: +1 great14:04
amotokigood writing xgerman_ chandanc14:04
annp+114:04
xgerman_chandanc: +114:04
chandancthanks all and xgerman_14:04
SridarKxgerman_: chandanc: thx14:05
xgerman_RC-1 is next week - I haven’t heard from Neutron how many RCs they are planning but…14:05
xgerman_if we get bug fixes in in the next few days they might make it14:06
amotokino strict plan. RC1 will be cut as usual14:06
SridarKok14:06
amotokimore RC(s) are on-demand and depending on critical bugs14:06
SridarKshall we get into some outstanding issues14:07
xgerman_PTG prices are going up BTW today14:07
xgerman_#topic Queen Bugs/Outstanding issuesd14:07
*** openstack changes topic to "Queen Bugs/Outstanding issuesd (Meeting topic: fwaas)"14:07
SridarKxgerman_: +1 thx14:07
annpSridarK: +114:07
xgerman_thanks amotoki14:08
SridarKi think we have 2 issues14:08
SridarKxgerman_: sorry go ahead pls drive14:08
xgerman_ok14:08
xgerman_#link https://review.openstack.org/53946114:09
xgerman_there is a problem with auto-associate for the firewall14:09
xgerman_and14:09
xgerman_#link https://review.openstack.org/53623414:09
xgerman_I think both are pretty close but need some more work14:10
SridarK+114:10
chandanc+114:10
annpxgerman_, Yes. I have to test more careful. So sorry about previous patch14:10
SridarKannp: no worries - good that we have fix in the works14:11
xgerman_+114:11
xgerman_at least we found it before the release which is huge!14:11
annpthanks SridarK14:11
chandancagree14:11
SridarKOn 536234 - this will prevent that one combination in the support matrix table14:12
SridarKso with that we should be covered14:12
xgerman_yes, that is my understanding…14:12
*** jhesketh has quit IRC14:12
SridarKand once ur fix for the auto-associate is done we are in good shape14:13
annpSridarK +114:13
*** jhesketh has joined #openstack-fwaas14:13
xgerman_+114:13
SridarKIMHO, 539461 is the higher priority14:13
xgerman_I am confident we can get both in before release. Worst case we ask for another RC14:13
SridarKthe other one can be a potential documentation - worst case - i think u are in good shape to get it in14:14
SridarKxgerman_: +114:14
annpxgerman_: i believe we can get merge both patch on tomorrow or next few days.14:15
SridarKannp: +114:15
xgerman_annp: +114:15
annpthanks. chandanc: can you help me test 539461 in your environment?14:16
xgerman_we all should test + verify amotoki ’s problem earlier in the channel14:16
chandancsure will test14:16
xgerman_#link http://paste.openstack.org/show/658314/14:17
amotokixgerman_: I am now testing with neutron-fwaas devstack only.14:17
annpchandanc, thanks a lot. :)14:17
xgerman_amotoki: thanks14:17
amotokipreviously I enalbed both neutron-fwaas and vpnaas. I am testing with neutron-fwaas only to identify the problem14:17
*** yamamoto has joined #openstack-fwaas14:17
amotokimy devstack just stoped with the same error :(14:18
amotokiwill investigate more14:18
xgerman_ok, thanks — we definitely need to make sure we didn’t break devstack…14:18
chandanc2018-02-01 13:50:16.085 | tee: etc/neutron/plugins/ml2/ml2_conf.ini: No such file or directory14:19
hoangcx_amotoki: https://review.openstack.org/#/c/527040/14:19
chandancmissing / ?14:19
hoangcx_amotoki: Maybe you encountered same issue with me14:19
amotokiit is missing a leading / but14:19
amotokiNEUTRON_CONF_DIR is defined with / in devstack14:20
amotokiso I am wondering what's wrong14:20
xgerman_mmh14:20
amotokinote that i am not using neutron-*. I use default q-* now.14:20
chandancvariable not sourced properly may be14:20
chandancwill test14:20
hoangcx_amotoki: same here. I use q-*14:20
amotokilet's share info if we have more after the meeting14:21
xgerman_+114:21
annp+114:21
amotokiI am facing this issue for several weeks and did not fwaas for weeks due to this :(14:21
amotokibtw, I have one more thing to ask.14:22
xgerman_yeah, we need to get to the bottom of this14:22
xgerman_sure, go ahead14:22
amotokiI would like to know what is remaining to complete https://blueprints.launchpad.net/neutron/+spec/fwaas-api-2.014:22
amotokiI think the drivers team will discuss queens blueprints in tomorrow meeting.14:23
amotokisome status update would be appreciated.14:23
xgerman_we tried to mark it complete but didn’t have access14:23
amotokixgerman_: i think everyone can update the whiteboard14:23
SridarKamotoki: there are probab a few items there which are a bit more futuristic - will be good to have some use cases before we prioritize14:24
xgerman_let’s close that one and file new one for additional features14:24
SridarKbut i think with L2 support we are quite complete14:24
SridarKxgerman_: i think the Remote FWG that u started is possibly the one thing that is realistic needed in the near term14:25
SridarKxgerman_: yes i agree - we can put some notes and Close it14:25
amotokiSridarK: xgerman_: can't we file anotehr blueprint on that?14:25
xgerman_+114:25
xgerman_yes, we can14:25
SridarKamotoki: +114:25
SridarKamotoki: so for status i think we can call it complete14:26
annp+114:26
amotokiSridarK: xgerman_: could you add some note to the top of the whiteboard of the BP?14:26
SridarKL2 support was the main outstanding item14:26
xgerman_I added COPLETED ;-)14:26
SridarKamotoki: sure14:26
amotokiSridarK: thanks!14:26
amotokiI see COMPLETED, yay :)14:27
xgerman_:-14:27
annp:)14:27
xgerman_)14:27
xgerman_#todo (xgerman) File Blueprint for remote FWG14:28
xgerman_but let’s talk in a few weeks what other features we want for R (e.g. address group)14:29
SridarKxgerman_: +114:29
SridarKi would also think to revisit the requirements14:30
xgerman_+114:30
xgerman_#topic Documentation14:30
*** openstack changes topic to "Documentation (Meeting topic: fwaas)"14:30
xgerman_A while back we decided to go in-tree with that14:31
xgerman_and we should have something up before Q gets released…14:32
xgerman_(at least our compatibility matrix)14:32
chandanc+114:33
SridarKAnd will have time - does this land in like bug fixes ?14:33
SridarK*do we have time14:33
xgerman_Technically they can publish anytime but they version14:34
xgerman_amotoki: wondering if you know more about that process14:34
-amotoki- is looking at logs..14:34
-amotoki- was afk for a while14:35
xgerman_no worries14:35
amotokiit looks like about doc process14:35
xgerman_yes, how long do we have for Queen docs?14:35
amotokiin general feature freeze is not applied to doc14:35
SridarKamotoki: ok14:36
amotokiwe can update our docs in master and backport them after stable/queens is cut.14:36
SridarKamotoki: ah ok14:36
xgerman_sweet14:36
SridarKwe will need to evaluate if some other ground work in needed for in tree docs14:37
xgerman_I think we have the skeleton… need to see if we have a doc job…14:38
SridarKok14:38
amotokilooking at fwaas v2 section in the networking guide, i think we need some basic information about fwaas v2 concept14:38
amotokias explained in the superuser blog.14:38
xgerman_+1014:38
SridarKamotoki: yes agreed - i think we need to lay some foundational things on differences btwn L3 and L214:39
SridarKotherwise the API is the same14:39
annp+114:39
amotokiif you want, you can maintain your docs in neutron-fwaas repo. it is up to individual teams14:39
xgerman_we like in-tree14:39
amotokiyou can choose etther neutron in-tree or neutron-fwaas in-tree docs.14:40
xgerman_I also think we need a cookbook style guide with use cases14:40
amotokiif the latter, we can add a link to the netwokring guide and/or installation guide.14:40
xgerman_we aim for neutron-fwaas-in-tree14:41
xgerman_amotoki: sounds good14:41
SridarKamotoki: if we are in tree - how will the doc get rendered for a user ?14:41
SridarKWill there be a separate guide for fwaas14:42
xgerman_#link https://github.com/openstack/neutron-fwaas/tree/master/doc/source14:42
SridarKor will it still get rendered as part of networking guide with content coming from fwaas repo14:42
amotokiSridarK: yes. it will be puslished at docs.o.o/neutron-fwaas/latest or neutron-fwaas/queens/14:42
amotokiso we need some guide links in networking guide in that case so that reader can easily find contents14:43
SridarKSo for the users - it will be separate guide ?14:43
amotokiat now it will be a separate guide14:43
SridarKamotoki: ok so there will be link we need in the networking guide14:43
SridarKbut if we put it in neutron - it will show up as a chapter in the networking guide14:44
amotokii think the toc of networking guide needs to be improved a bit14:44
amotokiSridarK: exactly if we put it in neutron14:44
SridarKamotoki: ok thx14:45
amotokisfc/vpnaas/bgpvpn/dynamic-routing have similar problems14:45
SridarKxgerman_: do u think it will be better if we put it in neutron so it is more cohesive with the networking guide14:45
SridarKor rather all subprojects should follow a consistent model14:46
SridarKamotoki: may be we should strive for consistency with the other projects - all of us should adopt the same approach14:46
xgerman_yes, consitency is good but I think having the docs in our tree gives us more autonomy14:46
xgerman_but I am good with whatever standard we come up with14:47
amotokiSridarK: at now there is no guideline on this according to what we discussed at Denver.14:47
SridarKamotoki: ok14:47
amotokii think either approach works. most important is to write contents :)14:48
SridarKthat i agree :-)14:48
hoangcx_amotoki: If so, I think neutron doc liaison should define some detail guideline for all subprojects to follow. though?14:48
amotokihoangcx_: true to some extent :p14:49
amotokiboden is a current liaison14:49
amotokiI am involved in the process much too14:49
SridarKWhile we work thru that - let me take an action to review what we have and start pulling some things together14:49
*** AlexeyAbashkin has quit IRC14:50
xgerman_yeah, I was thinking about writing as well14:50
SridarKxgerman_: surely - lets sync up offline14:50
xgerman_+114:50
xgerman_#topic Open Discussion14:50
*** openstack changes topic to "Open Discussion (Meeting topic: fwaas)"14:50
annpI have one14:50
xgerman_go ahead14:51
SridarKchandanc: Thanks for getting this in https://review.openstack.org/#/c/538154/14:51
annpchandanc, xgerman_, sridark: Related to detect sg enable email thread14:51
chandancSridarK: ya i am close but still stuck with merging14:51
*** AlexeyAbashkin has joined #openstack-fwaas14:51
annpShall we go with my draft idea for default fwg to resolve problem of sg=noop and fwaas=ovs?14:52
chandancannp: +114:52
SridarKannp: u mean https://review.openstack.org/#/c/536234/14:52
annpIf so, I think we should remove the option https://github.com/openstack/neutron-fwaas/blob/master/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L3914:53
amotokiwhat does sg=noop mean?14:53
xgerman_there is a noop driver for SG14:53
amotokiso will SG be disabled?14:54
annpSridarK, No related to 53623414:54
xgerman_we have this as an option14:54
SridarKannp: yes14:54
*** hoangcx_ has quit IRC14:54
xgerman_an operator can choose to enable SG, FW, or both14:54
annpamotoki: I mean we set firewall_driver of security group is noop14:54
xgerman_(or none)14:55
amotokiI see.14:55
annpif we go with my draft idea i think we should remove option auto_associate_default_fwg14:55
amotokithere is 'enable_security_group' option in securitygroups_rpc.py14:56
annpand revert https://github.com/openstack/neutron-fwaas/commit/e5f5c3f44531d2b6c9d813bc8f6d69e685af8c14 this patch14:56
xgerman_mmh, there was a use case where people wanted FWaaS but only on ports they choose14:56
annpBecause I don't want to change behavior of user.14:56
xgerman_I am not 100% in that camp so removing would be ok for me14:57
chandancannp: i agree , as soon as the DFWG fix patch goes in14:57
xgerman_SridarK: thoughts?14:57
SridarKyes we went thru to have some  option for users14:58
annpI means fwaas api only allow admin to set or unset port to default fwg14:58
amotokiannp: doesn't it depend on operators' choice?14:59
annpif user want to use security group only, i think user should contact with admin14:59
SridarKif some one does not want to associate the default fwg - then they are relying on SG15:00
chandancannp: in either case he needs to contact admin15:00
SridarKor they really know what they are doing and relying on perimeter security15:00
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 pace15:00
annpamotoki: sorry, can you explain more your question?15:00
annpchandanc: +115:00
amotokiannp: no problem. I feel there seems several use cases on who can control FWG.15:01
amotokiannp: my point is what happens if operators allow users to configure default FWG by policy.15:02
amotokiannp: but it depends on usecases and we need to summarize usecases. then we can clarify what is the first target.15:02
xgerman_yeah, I think we need to release and see what the field is doing…15:03
xgerman_anyhow we are at time…15:03
amotokihehe15:03
SridarKlets continue in channel15:03
annpamotoki: can we discuss after meeting?15:03
amotokiannp: sure15:03
annpthanks.15:03
xgerman_I gotta run but will be back in like 30-45 minutes15:03
xgerman_#endmeeting15:04
*** openstack changes topic to "Queens (Meeting topic: fwaas)"15:04
openstackMeeting ended Thu Feb  1 15:04:06 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:04
openstackMinutes:        http://eavesdrop.openstack.org/meetings/fwaas/2018/fwaas.2018-02-01-14.03.html15:04
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/fwaas/2018/fwaas.2018-02-01-14.03.txt15:04
SridarKthanks all15:04
openstackLog:            http://eavesdrop.openstack.org/meetings/fwaas/2018/fwaas.2018-02-01-14.03.log.html15:04
annpChandanc, SridarK: can we continue discuss?15:04
SridarKannp: we are still thinking of the model where the user can move from default fwg to a user defined fwg15:04
chandancsure15:04
SridarKand if they remove the user defined fwg - we will apply the default fwg15:05
amotokiannp: I might miss the whole context. is there any pointer so that I can confirm the context?15:05
chandancSridarK: yes15:05
annpamotoki: take a example for more clear15:05
annpThere is 2 compute node: Compute Node A(sg_driver=noop, fwaas_driver=OVS), Compute Node B(sg_driver=ovs, fwaas_driver=ovs)15:07
annpThere is 1 controller Node run neutron-server with config auto_associate_default_firewall_group=False15:08
amotokiokay15:08
annpIF there is VM1 and VM2 are landed at Compute Node A, Then VM1 and VM2 are associated with a FWGA,15:09
annpFWGA allow icmp traffic for both direction,15:09
annpThe problem here: VM1 can't ping VM215:09
amotokiis FWGA a default FWG?15:09
annpsorry, VM1 is associated to FWGA15:10
amotokiokay15:10
annpVM2 doesn't associated to FWGA15:10
annpVM2 is associated to default SG with allow icmp rule15:11
annpWe expect VM2 can ping VM1, right?15:11
amotokion compute node A, SG driver is noop. this means no traffic filtering15:11
annpYes.15:12
amotokiboth FWGA and default SG allow icmp traffic15:12
annpamotoki: yes.15:12
amotokiso only FWG involves traffic control15:12
annpyep15:12
amotokiif the above my understanding is correct, ICMP traffic between VM1 and VM2 should be allowed.15:13
annpyes, your understanding is correct.15:13
amotokiso we can expect VM2 can ping VM1, as you said15:13
chandancamotoki:annp sorry to jump in between15:14
annpHowever, the problem VM2 can't ping VM115:14
amotokichandanc: no worries15:14
annpchandanc, no problem.15:14
chandanclet me give some context15:14
chandancas we are making statefull FW, we need conntrack to see the traffic from the start of the communication, the way to achive this is to apply basic rules to make sure all traffic passes through contrack. we do it using default FWG. other option is to rely on SG to pass the traffic through conntrack, which will fale if SG is runing on noop driver15:14
annpchandanc: thanks. amotoki: that's problem.15:15
chandanc*fail :(15:15
amotokiannp: chandanc: so, is the problem partial conntrack information?15:16
chandancya15:16
annpamotoki: If VM1 and VM2 are landed at Compute Node B, VM1 is associated to FWGA and VM2 doesn't associate to FWGA, VM1 can ping VM215:17
chandancwe need both the src/dst to be part of some FWG so that conntrack is aware15:17
annpamotoki: yes,15:17
SridarKannp: and this will not happen if we always enable default fwg (and now allow a configurable option)15:17
amotokihmm15:17
annpSridarK: yes. If we always enabled default fwg15:18
chandancSridarK: my worry with the option is, if the user enables and disables the option, he will end up with some VMs associated with default FWG and some not15:18
annpand we don't allow normal user unset port from default fwg. The problem will be solved15:19
chandancs/if the user enables/if the admin enables/15:19
SridarKchandanc: ah yes that is for admins15:19
chandancSridarK: yes15:20
chandancit also means we are forced to throughly test Default FWG :)15:20
annpchandanc: yes. :)15:21
SridarKannp: yes if the default fwg is enabled - when a user unset a user defined fwg for a port - that port will fall back to a default fwg15:21
SridarKassuming default fwg is enabled ^^15:21
annpSridarK, Yes. that's my draft idea15:22
amotokibasic question: if no SG and no FWG are applied to a port, no conntrack is involved in the packet forwarding? (sorry for my lack of understanding the context)15:23
chandancSridarK: for “assuming default fwg is enabled ^^” annp is suggesting not giving the option to admin, which i agrre provided we fix Default FWG15:24
chandancamotoki: yes,15:24
chandancamotoki: in that case no l3 processing happens15:24
amotokichandanc: thanks. ovs flow calls conntrack processing15:24
chandancamotoki: the ovs acts like l2 switch, which is faster15:25
amotokichandanc: yes15:25
chandancamotoki: yes15:25
annpchandanc +!15:25
amotokiso when we say "noop SG driver", it is different for iptable case and ovs-fw case.15:25
chandancas soon as ports become part of SG/FWG l3/conntrack is enabled on the ports15:25
amotokiyeah15:26
chandancamotoki: SG can be configured with IPtables/Openvswitch/noop15:26
chandancdriver15:26
chandancin the last case no action is done on the packet15:27
chandancwe have similar case for FWG15:27
amotokione tricky point is it depends on how it is plugged15:27
annpamotoki: yes15:28
amotokiif hybrid plug is used conntrack will be referred, but ovs native plug is used it is not true15:28
chandancamotoki: actually ovs native is also using conntrack15:28
chandancin SG15:28
amotokichandanc: is it used if SG is enabled?15:29
chandancyes amotoki15:29
amotokithanks. my understanding is same15:29
amotokihm.. I am wondering how we can classify this matrix15:29
SridarKFor what it is worth - we did not start with a configurable option for Default FWG15:30
chandancamotoki: we have one ready with the current combination that can be supported15:30
chandancand if the conntrack patch in neutron is merged we should be good to support iptables_hybrid15:31
chandanccurrent matrix, is described here https://docs.google.com/document/d/1JMpJI4ypKwU-p7Dh1wGT_eVstD8QPX9xpmBxXXQifRc towards the end15:32
amotokigood news on devstack. stack.sh succeeds if I disabled neutron devstack plugin and only enable devstack plugin15:36
amotokithere seems a probelm in 'neutron' devstack plugin15:37
chandancoh15:37
SridarKannp: back to ur original question - the knob enables folks who want try our FWG for L2 but rely on SG for defaults or a safety net15:37
SridarKbut yes this is a tricky situation15:37
SridarKI need to step away for a bit to get ready to head to work - but shall we resume some discussion when u start ur day as it is late for all of u15:38
annpSridarK, you mean FWG will run in standalone mode?15:39
SridarKi will monitor logs15:39
annpSridarK, OK. We can discuss via email15:40
SridarKannp: no i am just stating some of the reasons for knob to enable auto association15:40
chandancamotoki: i think https://review.openstack.org/#/c/538154/ is stuck due to some issue, could you take a look please15:40
amotokichandanc: http://zuul.openstack.org/ answers to you :p15:41
chandancoh, was not aware of that, let me check15:41
amotokichandanc: your patch is in the long 'integrated' queue15:41
amotokiand it stays in the gate queue for 7hr 35min15:42
annpSridarK, if you see my example above, if we giving the option, and if operator configure auto_associate_default_fwg: then FWaaS API won't work correct with VMs at Compute Node A15:42
chandancamotoki: thanks for the info :)15:42
SridarKannp: i agree15:42
amotokiif parent changes fail, gates for all pending changes will be restarted. this is the reason it takes time15:42
annpSo I'd like to remove the option.15:42
chandancamotoki: thanks i will keep a watch15:43
annpSo all vms is always a part of a FWG15:44
SridarKYes i am not really seeing how else we can get the functionality to work15:45
annpIn case: There are some vms don't want to use FWG, admin tenant can unset vms from default fwg15:45
SridarKas i said this configurable option was not the intial intent15:45
SridarKso lets discuss more when u start ur day and get to some closure - so we can move on the fix15:47
annpSridarK: So we should remove the option in Q release?15:47
SridarKDefinitely something to consider - I just want to weigh the pros and cons15:48
SridarKI will step away now - i am logged in - will check back in some time - if u guys are continuing the discussion15:50
annpSridarK: I got it. Shall we discuss via email? I guess we need time to thinking15:50
SridarKand we can continue when u are up in ur morning15:50
SridarKannp: yes15:50
SridarKannp: it must be quite late for u too ?15:50
SridarKannp: yes email is fine too - but we have to come to some workable solution for Q15:51
annpSridarK: I understand. :)15:51
SridarKannp: thx for ur diligence on this issue15:52
annpSridarK: not too late for me. But I'm feel sleepy now. :)15:52
annpamotoki, chandanc, Can we discuss via email thread?15:52
annpamotoki, chandanc, Can we continue discuss via email thread?15:53
chandancsure15:53
annpchandanc, +115:53
amotokisure. I am still catching up with the discussion15:53
annpamotoki, thanks.15:54
annpthanks all and see you tomorrow.15:54
chandanci will have to go away for diner , lets discuss tomorrow15:54
amotokichandanc: have a good time :)15:54
chandancamotoki: you too :)15:54
annpchandanc, enjoy!!!15:54
chandancannp: thanks :)15:55
chandancbye all15:55
xgerman_o/15:55
*** chandanc has quit IRC15:55
annpxgerman_ hi, we will continue discuss via email15:55
amotokihoangcx: some info on devstack failure we disucssed in the meeting. http://eavesdrop.openstack.org/irclogs/%23openstack-fwaas/%23openstack-fwaas.2018-02-01.log.html#t2018-02-01T15:36:4615:55
xgerman_k15:56
annpxgerman_ :) see you.15:56
*** annp has quit IRC15:57
*** SridarK has quit IRC16:19
*** AlexeyAbashkin has quit IRC17:40
*** AlexeyAbashkin has joined #openstack-fwaas17:41
*** AlexeyAbashkin has quit IRC17:45
*** SumitNaiksatam has joined #openstack-fwaas18:00
*** yamamoto has quit IRC18:17
*** openstackgerrit has quit IRC18:18
*** AlexeyAbashkin has joined #openstack-fwaas19:11
*** yamamoto has joined #openstack-fwaas19:18
*** bbzhao has quit IRC19:25
*** bbzhao has joined #openstack-fwaas19:26
*** yamamoto has quit IRC19:29
*** AlexeyAbashkin has quit IRC19:55
*** SumitNaiksatam has quit IRC20:22
*** hoangcx has quit IRC20:24
*** hoangcx has joined #openstack-fwaas20:39
*** hoangcx has quit IRC20:49
*** hoangcx has joined #openstack-fwaas21:03
*** hoangcx has quit IRC21:25
*** hoangcx has joined #openstack-fwaas21:29
*** hoangcx has quit IRC21:33
*** hoangcx has joined #openstack-fwaas21:48
*** hoangcx has quit IRC21:59
*** threestrands has joined #openstack-fwaas21:59
*** threestrands has quit IRC22:00
*** threestrands has joined #openstack-fwaas22:00
*** hoangcx has joined #openstack-fwaas22:13
*** hoangcx has quit IRC22:32
*** hoangcx has joined #openstack-fwaas22:46
*** mlavalle has joined #openstack-fwaas23:03
mlavallexgerman_: would you and Sridar give your opinion about this RFE: https://bugs.launchpad.net/neutron/+bug/1738738?23:06
openstackLaunchpad bug 1738738 in neutron "[Neutron][Firewall] Extend FWaaS to provide DSCP filtering" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee)23:06
mlavalleno rush. it doesn't have to be today23:06
xgerman_looking23:07
xgerman_I already was positive on it…23:08
mlavallexgerman_: is this something that the FWaaS team would like implemented in Rocky?23:21
xgerman_we haven’t done our planning but if reedip wants to work on it we welcome contributions23:21
xgerman_our main goals are bug fixes, documentation, stadium, tempest tests23:22
mlavallexgerman_: thanks for the input:-) you going to Dublin?23:23
xgerman_yes23:23
mlavallesee you there :-)23:23
xgerman_yep, looking forward!23:24
*** SridarK has joined #openstack-fwaas23:48
yushiroMorning SridarK and xgerman_  Sorry and thank you for yesterday's meeting.23:55
xgerman_n.p.23:55
mlavallehey SridarK: if you have a chance, would you please chime in here: https://bugs.launchpad.net/neutron/+bug/1738738?23:55
openstackLaunchpad bug 1738738 in neutron "[Neutron][Firewall] Extend FWaaS to provide DSCP filtering" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee)23:56
yushiroI was leaving my company's laptop with logging-in this IRC.  So, sorry for confusing.23:56
yushiromlavalle, Hi.  I'll also can go PTG and looking forward to meeting you :)23:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!