Wednesday, 2017-08-16

*** yushiro has joined #openstack-fwaas00:44
xgerman_reedip, yushiro, sridark I think this ^^ might fox our gate failures - please review + comment00:44
reedipI hope it doesnt fox our gates :)00:44
reedipchecking00:46
reedipxgerman_ : doesnt the check validate if we are Unable to delete a FWG00:47
yushiroxgerman_, Good morning.  I checked your patch (https://review.openstack.org/#/c/494034/1) and reviewed.00:47
reedipyushiro : we are missing a test case for it, right ?00:48
xgerman_reedip we don’t have that count check on the other deletes + I think it would still throw an exception if it can’t delete — all I removed is the Not Found…00:48
reedipxgerman_ : I would like to understand why we are getting a 404 in the first place. If the FWG is already deleted, then its entry shouldnt exist in the DB, right?00:49
yushiroreedip, ah yes.00:49
reedipxgerman_ if we are calling a delete on a FWG which is already deleted, we should get 404, isnt it ?00:51
yushiroxgerman_, reedip If fwg has already been deleted, context.session.query(00:52
yushiroFirewallGroup).filter_by(id=id) returns None or [], right?00:52
xgerman_I usually return not 404 in that case but it’s debatavle00:52
xgerman_we put delete on it00:52
reedipyushiro : would return None, IIRC00:52
reedipxgerman_ : well if we have a check for the fwg at an earlier stage , i.e. in the extension , then we can remove the check in the DB00:53
reediphttps://github.com/openstack/neutron-fwaas/search?utf8=%E2%9C%93&q=%22def+delete_firewall_group%22&type=00:53
xgerman_I know that if we return 404 we make life difficult for people who have concurremcy issues callign us00:54
xgerman_so I am in favor of eating that error —00:54
reedipxgerman_ agreed that race conditions would be affected on parallel deletes. I am not against it :)00:55
reedip* against eating up the error00:56
reedipxgerman_, yushiro : Ideally if the ID doesnt exist, we might end up with an error in https://github.com/openstack/neutron-fwaas/blob/9d9799f20ca202ceeb8354a6817c856c26434869/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L355 or https://github.com/openstack/neutron-fwaas/blob/9d9799f20ca202ceeb8354a6817c856c26434869/neutron_fwaas/services/firewall/drivers/linux/iptables_fwaas_v2.py#L11000:59
yushiro_make_firewall_group_dict_with_rules()01:01
yushiroit calls get_firewall_group() and returns 40401:01
reedipwould the make_firewall_group_dict_with_rules be called for Delete? I thought it was called for Update/Create etc.01:02
reedipIt basically returns the data back to the user, IIRC01:02
yushirohttps://github.com/openstack/neutron-fwaas/blob/9d9799f20ca202ceeb8354a6817c856c26434869/neutron_fwaas/services/firewall/fwaas_plugin_v2.py#L35801:02
reedipaah01:03
reedip:)01:03
reedipdone then01:03
yushiroBefore entering DB layer, _make_firewall_group_dict_with_rules is definitely called.  However, race condition will be occurred.01:05
reedipyushiro : with respect to the race condition,there are 2 conditions01:06
reedipyushiro: if the first request deletes the FWG and the second request just arrives at checking the ID, then it would get 404, which is expected01:07
reedipyushiro: if both calls pass the get_firewall_group() as the FWG was not yet deleted, then xgerman_ 's fix fixes the issue :)01:07
xgerman_lucky me ;-)01:08
xgerman_yeah, I really like our gates to be fixed so we can have the release stuff merged01:09
yushiroMaybe yes.  Simply, delete_firewall_group in DB layer is called at same time for same ID.01:09
yushiroI just wrote UTs for it. http://paste.openstack.org/show/618458/01:19
yushiroPlease let me ask more.01:20
openstackgerritReedip proposed openstack/neutron-fwaas master: consume load_class_by_alias_or_classname from neutron-lib  https://review.openstack.org/48713901:21
reedipxgerman_  , yushiro : Meanwhile in neutron-lib migration ^^01:22
yushiroreedip, thanks.  will check.01:29
yushirocontext.session.query(FirewallGroup).filter_by(id=id)  returns oslo_db.sqlalchemy.orm.Query object  even if non-exist ID.01:30
reedipbut we are calling delete on it01:31
yushiroThen, if executed ".delete()", it returns 001:31
yushirohmm, sorry. I still don't understand correctly.  If race condition occurred, both API will return 204 ?01:33
reedipNope01:34
reedipwith the subtransaction=True, we would have only one call for WRITE on the DB01:34
reedipIIRC01:34
reedipso by the time the second one comes to delete,the first one would have deleted it and ... 40401:35
yushiro1st: delete DB successfully and return 204.   2nd: already removed and returns 404   This is current behavior.01:36
yushiroIn xgerman_'s patch, if non-exist fwg_id is specified, it doesn't return FirewallGroupNotFound.01:37
yushiro^^ in DB layer's behavior01:37
reedipYes, then we would have 20401:37
reedipso if the a Delete Request checks that a FWG exists, it goes to delete the FWG, but before it deletes it, someone else has  already deleted it, then return 20401:38
yushiroIf so, 1st: 204, 2nd: 20401:39
reedipIf the delete request cannot find the FWG in the first check, 40401:39
yushiroHmm, it seems different behavior in each layer...01:42
reedip:) Depends on which layer is interacting with the user .. its User experience after all01:44
yushirohmm, each layer(plugin, DB) raises exceptions (NotFound, Conflict, ...) for users.02:11
yushiroSo, I think it's better to fix tempest plugin...02:13
yushirobut it is OK in DB consistency perspective.02:17
openstackgerritVu Cong Tuan proposed openstack/neutron-fwaas master: FW rule applied incorrectly if port specified is a range  https://review.openstack.org/44338502:52
openstackgerritYushiro FURUKAWA proposed openstack/neutron-fwaas master: Don't return 404 when deleting a non-existant FWG  https://review.openstack.org/49403403:04
yushiroJust added UT03:04
*** yushiro is now known as yushiro_lunch03:05
*** vishwana_ has joined #openstack-fwaas03:18
*** vishwanathj has quit IRC03:21
openstackgerritVu Cong Tuan proposed openstack/neutron-fwaas master: FW rule applied incorrectly if port specified is a range  https://review.openstack.org/44338504:27
*** reedip has quit IRC05:23
*** reedip has joined #openstack-fwaas05:37
*** SridarK has joined #openstack-fwaas05:37
*** yushiro_lunch is now known as yushiro05:41
yushiroxgerman_, SridarK Let me sync my PTG status05:41
yushiroxgerman_, SridarK I can go to PTG!!  I passed travel support program :)05:42
SridarKyushiro: oh great05:45
SridarKyushiro: when are u back from PTO ?05:46
yushiroI came back since yesterday's evening.05:47
yushiroMy PTO was 11th - 16th Aug.05:47
yushirooops, 15th05:47
SridarKyushiro: ah ok05:48
SridarKwe discussed some PTG planning in our IRC05:48
SridarKhttps://etherpad.openstack.org/p/neutron-queens-ptg05:48
SridarKfew updates there in FWaaS section05:48
SridarKyushiro: i got back last night too so catching up today05:49
SridarK:-)05:49
yushiroSridarK, Aha, you too? :)  Yes, I saw meeting log.05:50
yushiroand thanks for the link of etherpad.05:51
SridarKyushiro: no worries - we will focus on the Horizon patch. I sent a reminder to Sarath to look into Akihiro's comments as well and we can do some testing as well05:58
yushiroSridarK, OK.  BTW, xgerman_ has posted https://review.openstack.org/#/c/494034  . It may be able to avoid tempest test failure.  Could you review it ?06:03
SridarKyushiro: hmm so is this the root cause of the failures06:07
SridarKi have not had a chance to check this06:07
SridarKIn a tempest scenario - it is odd that the delete has happened before the delete is called06:07
SridarKseems suspicious ?06:08
SridarKI hope we are not masking an issue06:08
SridarKBut yes i think normally it looks ok to me that if we cannot find the fwg to be deleted - so be it06:09
yushiroSridarK, Yes, I'm not sure what is root cause ( Not researched yet )06:13
yushiroSridarK, TBH, I think plugin/DB layer should be a same behavior.06:14
SridarKyushiro: yes agreed - ok i am fine with it - let me sync with xgerman_ in the AM and put in the review06:18
yushiroSridarK, Thank you.  I also check tempest test cases.06:18
yushiroOf course v2 horizon patch :)06:18
*** SridarK has quit IRC07:51
*** yamamoto has joined #openstack-fwaas08:33
*** yamamoto has quit IRC08:49
reedipyushiro: congrats08:55
reedip:)08:55
yushiroreedip, thanks !10:34
openstackgerritElena Ezhova proposed openstack/neutron-fwaas master: [DevStack] Configure iptables_v2 firewall driver for FWaaS V2.  https://review.openstack.org/49416710:54
openstackgerritElena Ezhova proposed openstack/neutron-fwaas master: [DevStack] Configure iptables_v2 firewall driver for FWaaS V2.  https://review.openstack.org/49416712:08
openstackgerritInessa Vasilevskaya proposed openstack/neutron-fwaas master: FirewallGroupPortInvalidProject can be raised now  https://review.openstack.org/49419813:03
xgerman_o/13:57
amotokican some fwaas-core approve https://review.openstack.org/493666 (relnote build fix) ?14:00
openstackgerritElena Ezhova proposed openstack/neutron-fwaas master: [DevStack] Configure iptables_v2 firewall driver for FWaaS V2.  https://review.openstack.org/49416714:30
*** reedip_ has joined #openstack-fwaas15:21
*** reedip_ has quit IRC15:42
openstackgerritMerged openstack/neutron-fwaas master: fix releasenotes build  https://review.openstack.org/49366616:22
openstackgerritAndrea Frittoli proposed openstack/neutron-fwaas master: Get default client config from config module  https://review.openstack.org/49427517:05
openstackgerritElena Ezhova proposed openstack/neutron-fwaas master: [DevStack] Configure iptables_v2 firewall driver for FWaaS V2.  https://review.openstack.org/49416717:16
xgerman_things are merging again so we might not need my patch after all…20:20
openstackgerritMerged openstack/neutron-fwaas master: Update reno for stable/pike  https://review.openstack.org/49290820:27
*** vishwana_ has quit IRC21:03
*** vishwanathj has joined #openstack-fwaas21:04
*** yamamoto has joined #openstack-fwaas21:44
*** yamamoto has quit IRC21:45
*** yamamoto has joined #openstack-fwaas21:51
*** vishwana_ has joined #openstack-fwaas21:54
*** yamamoto has quit IRC21:58
*** vishwanathj has quit IRC21:58

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