Thursday, 2018-01-25

*** MarkBaker has joined #openstack-meeting-500:49
*** MarkBaker has quit IRC01:01
*** mjturek has quit IRC01:11
*** ricolin has joined #openstack-meeting-501:26
*** kei-ichi has quit IRC02:45
*** kei-ichi has joined #openstack-meeting-502:46
*** kei-ichi has quit IRC03:08
*** kei-ichi has joined #openstack-meeting-503:09
*** yamamoto has joined #openstack-meeting-503:37
*** kei-ichi has quit IRC04:54
*** kei-ichi has joined #openstack-meeting-504:55
*** Mutter_ has joined #openstack-meeting-506:37
*** Mutter_ has quit IRC06:41
*** kei-ichi has quit IRC06:44
*** kei-ichi has joined #openstack-meeting-506:45
*** kei-ichi has quit IRC06:52
*** markvoelker has quit IRC06:52
*** kei-ichi has joined #openstack-meeting-506:53
*** markvoelker has joined #openstack-meeting-506:53
*** markvoelker has quit IRC06:57
*** kei-ichi has quit IRC06:59
*** kei-ichi has joined #openstack-meeting-507:02
*** markvoelker has joined #openstack-meeting-508:54
*** kei-ichi has quit IRC09:18
*** kei-ichi has joined #openstack-meeting-509:20
*** markvoelker has quit IRC09:27
*** derekh has joined #openstack-meeting-509:29
*** kei-ichi has quit IRC09:44
*** kei-ichi has joined #openstack-meeting-509:46
*** yamamoto has quit IRC10:04
*** markvoelker has joined #openstack-meeting-510:25
*** markvoelker has quit IRC10:58
*** vkmc has quit IRC10:58
*** yamamoto has joined #openstack-meeting-511:05
*** vkmc has joined #openstack-meeting-511:05
*** yamamoto has quit IRC11:18
*** yamamoto has joined #openstack-meeting-511:31
*** markvoelker has joined #openstack-meeting-511:55
*** markvoelker has quit IRC12:29
*** yamamoto has quit IRC12:31
*** yamamoto has joined #openstack-meeting-512:31
*** yamamoto has quit IRC12:52
*** makowals has quit IRC12:54
*** makowals has joined #openstack-meeting-512:56
*** yamamoto has joined #openstack-meeting-513:07
*** makowals has quit IRC13:19
*** annp has joined #openstack-meeting-513:25
*** markvoelker has joined #openstack-meeting-513:26
*** makowals has joined #openstack-meeting-513:26
*** yamamoto has quit IRC13:42
*** cleong has joined #openstack-meeting-513:42
*** slaweq has joined #openstack-meeting-513:51
*** Mutter has joined #openstack-meeting-513:55
*** Mutter is now known as tuanvu13:55
*** tuanvu is now known as tuan_vu13:56
*** ricolin has quit IRC13:56
*** markvoelker has quit IRC13:59
*** lujinluo has joined #openstack-meeting-513:59
*** ihrachys_ has joined #openstack-meeting-514:01
*** hungpv_ has joined #openstack-meeting-514:02
ihrachys_#startmeeting neutron_upgrades14:02
openstackMeeting started Thu Jan 25 14:02:11 2018 UTC and is due to finish in 60 minutes.  The chair is ihrachys_. Information about MeetBot at http://wiki.debian.org/MeetBot.14:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:02
*** openstack changes topic to " (Meeting topic: neutron_upgrades)"14:02
openstackThe meeting name has been set to 'neutron_upgrades'14:02
ihrachys_hi!14:02
lujinluoo/14:02
tuan_vuHi everyone14:02
*** yamamoto has joined #openstack-meeting-514:02
ihrachys_before we dive in, some background on the current state of affairs in relation to release14:03
ihrachys_as you may probably know, a new major release (queens) is getting closer14:03
lujinluo\o/14:03
ihrachys_https://releases.openstack.org/queens/schedule.html14:04
ihrachys_this week is feature freeze14:04
ihrachys_we'll have a RC1 release (and hence stable/queens) in several weeks from now14:05
ihrachys_till that moment, we should be cautious landing patches that may affect stability and don't fix clear bugs14:05
ihrachys_which most OVO patches are14:05
ihrachys_we can of course continue reshaping patches in review to get them ready for when master is open14:06
lujinluounderstood.14:06
ihrachys_one sad development because of release final coming close is that we were forced to revert port binding patch that took a while to shape14:06
ihrachys_because of several issues that merging it revealed14:07
ihrachys_one is that it was not counting with mixed old/new engine facade usage14:07
ihrachys_another is postgresql installations busted14:07
lujinluoyeah, speaking of that. can i have a (stupid) question?14:07
ihrachys_we will need to get back to the white board, so to speak, repropose the patch, fix those issues, and land some time in Rocky14:08
ihrachys_lujinluo, yes!14:08
lujinluoi was trying to reproduce the postgresql issues14:08
lujinluoso i built a devstack with postgresql as backend14:08
lujinluothen i have no idea how i can reproduce the errors..14:08
lujinluocould you direct me to the conf/settings of that specific tempest tests?14:09
ihrachys_the periodic job that fails executes full suite of tempest I believe14:09
ihrachys_but let me check14:09
lujinluosure, thanks14:10
ihrachys_so this is what failed there: http://logs.openstack.org/periodic/git.openstack.org/openstack/neutron/master/legacy-periodic-tempest-dsvm-neutron-pg-full/71f9bd8/logs/testr_results.html.gz14:11
*** lamt_ has joined #openstack-meeting-514:12
lujinluogot it! will start from there14:12
ihrachys_I would imagine running those tests in a loop could get you to failure14:12
ihrachys_specifically check those that raise ServerFault14:12
lujinluonice suggestion. will follow it ;)14:12
ihrachys_since that's a sign of neutron-server internal error14:13
ihrachys_ok14:13
ihrachys_btw note that revert patch hasn't landed still: https://review.openstack.org/53691314:13
lujinluook14:14
ihrachys_in other news, gate is quite unstable lately, with multiple issues lingering14:14
ihrachys_we are trying to fix them one by one but we are not there yet14:14
ihrachys_things like job timeouts is one, functional is also unstable (ovsdb commands timing out)14:14
ihrachys_so please be patient if you get those errors over and over, that's sadly expected14:15
hungpv_Okay :(14:15
ihrachys_now, back to usual business14:16
slaweqhello, sorry for late14:16
ihrachys_slaweq, hi!14:16
lujinluohey slaweq !14:16
ihrachys_https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db14:16
ihrachys_https://review.openstack.org/#/c/521797/ "Use Router OVO in external_net_db"14:16
ihrachys_so this patch is fine now but it lacks test coverage for the module / method it touches14:17
ihrachys_so we can't really safely land it14:17
ihrachys_hungpv_, do you think you could work on adding some unit tests for the method before merging this OVO patch?14:18
hungpv_I thought you said it's called by update_rbac_policy and delete_rbac_policy ?14:18
ihrachys_I just said that I checked there is no mixed old/new engine facade issue there14:19
hungpv_Oh, if it's the case14:20
ihrachys_remember in the past, in one of older patchsets, there were some mistakes that absolutely broke the code and gate failed to catch it? that's what I am concerned about, that existing coverage won't catch anything if there are still some bugs there.14:20
hungpv_I'll be working more this issue14:20
ihrachys_so adding some unit tests would help us to sleep well :)14:21
ihrachys_ok thanks hungpv_ !14:21
ihrachys_next "https://review.openstack.org/507772 Use Network OVO in db_base_plugin"14:21
tuan_vuI’ve left a comment about current blocking point14:21
*** ricolin has joined #openstack-meeting-514:21
tuan_vuWe’re still working on it14:22
ihrachys_the current list of failures is: http://logs.openstack.org/72/507772/29/check/openstack-tox-py27/8b97a84/testr_results.html.gz14:22
ihrachys_for foreign key failure, I see it's just in object test class itself14:23
tuan_vuYes, but we haven’t figured out how to fix it14:24
slaweqtuan_vu: I didn't have time to check it yet14:24
slaweqbut I will try to help14:24
tuan_vuHi slaweq, thank you in advance14:24
ihrachys_I think it's one of those cases that just need self.update_obj_fields in setUp() for whatever field is violated14:24
tuan_vuWe really appreciate your help14:24
ihrachys_slaweq, tuan_vu, ping me if you need me to look at the foreign key issue14:25
tuan_vuThank you, ihar, we’ll try your suggestion14:25
ihrachys_another more important failure there is test_*_queries_constant failures14:26
tuan_vuYes, I’m just wondering if we can change the number of queries?14:26
tuan_vuBecause in ovo, the way it works is different a little bit14:27
ihrachys_which signals that somewhere in the patch, we fetch some models from database in an ineffective way (probably fetching a relationship for networks using a separate query)14:27
ihrachys_tuan_vu, we can't, we should find a way to avoid it14:27
ihrachys_tuan_vu, do you know which relationship triggers additional queries?14:27
tuan_vuWe need to reload “shared” attribute14:28
tuan_vuWhen update network14:28
ihrachys_why is it? can't we calculate new value from what is already passed by user / fetched from db?14:29
lujinluois it because "shared" is a synthetic field now?14:30
tuan_vuHi Luo, yes14:30
ihrachys_besides, test_network_list_queries_constant also fails, which doesn't update network14:31
lujinluoi think i have met this issue while working on Port integration. when we have aynthetic fields, the # of queries does not stay constant14:31
ihrachys_it lists networks, and probably we trigger a set of queries per network matched14:31
lujinluoyes, because get_objects() will try to fetch all their synthetic fields too14:32
tuan_vuYes, thank you Luo, your experience does help a lot14:33
lujinluobut i do not recall i found a suitable solution for that :(14:33
ihrachys_right. so one of relationships is probably of type that doesn't fetch data when parent network model is fetched. that would be a problem, no?14:33
ihrachys_I mean, type of sqlalchemy model attribute for relationship14:34
*** markvoelker has joined #openstack-meeting-514:34
ihrachys_ok, let's try from another direction. how did it work before the patch?14:34
tuan_vuHmm14:35
tuan_vuThe main problem is “shared” attribute14:35
tuan_vuBefore the patch, we use rbac for “shared”14:36
ihrachys_right. can't we calculate it for OVO the same way? we have .db_obj.rbac_entries already, right?14:36
ihrachys_if we then make rbac metaclass to use this info directly instead of refetching it (I guess that's what happens?) then we would avoid the problem?14:37
tuan_vuHmm, let me think more about your suggestion, is that ok? I’ll send you an email if that’s needed14:38
tuan_vuOr contact you via IRC14:39
ihrachys_yeah sure, we don't need to dig the code right away, but the main point, we can't disable / change this unit test.14:39
lujinluothat should work, by changing how the # of queries are calculated. besides, "shared" is not a synthetic field, please check which attribute is the one that causes this issue14:39
tuan_vuThank you, Ihar and Luo14:39
ihrachys_moving on14:39
ihrachys_https://review.openstack.org/#/c/537320/ "Use Port OVO in neutron/db/external_net_db.py"14:40
lujinluoi did recheck about the timeouts.. but i guess zuul hung somewhere...?14:40
ihrachys_lujinluo, I was to look at some port patches you have but then we stumbled on port binding revert. I was thinking, are we blocked by that one now?14:40
ihrachys_lujinluo, yeah, zuul is sick these days. I rechecked.14:40
lujinluokind of.. it's better to wait for port binding to land first, as those two patches conflicts a lot14:41
ihrachys_lujinluo, right. speaking of which... do you go to Dublin? I think mlavalle was planning a session on ovo/enginefacade issue.14:42
lujinluoit would be easier to get them in serially, not in parallel14:42
*** hoangcx_ has joined #openstack-meeting-514:42
lujinluomy employer has not decided yet, but i guess probably..14:42
lujinluoi would go14:42
ihrachys_great. btw I don't. but having someone from this group there would help. I may try to join remotely if there will be such an option14:43
lujinluooh, it is sad that you are not going :(14:43
ihrachys_yeah. I kinda lagged on trips lately for family reasons.14:44
lujinluowell, family always goes first14:45
ihrachys_anyway, moving on to the next which is14:45
ihrachys_https://review.openstack.org/#/c/537325/ "Use Meter Label OVO in neutron/db/metering/metering_db.py"14:45
ihrachys_this looks green :)14:45
lujinluoi used label.db_obj (which we should not do normally), but since we cannot use router as a synthetic field, i think this is fine. what do you think? ihrachys_14:46
*** tuan_vu has quit IRC14:46
ihrachys_so there, you pass db models in one case and objects in another case14:46
lujinluohmm right14:47
lujinluoi need to avoid that14:47
ihrachys_question is, how14:48
ihrachys_we could of course add routers field to labels but that's a bit silly from API perspective (label is not a container for routers)14:48
lujinluothe first solution came to my mind was _load_object(), but we should avoid that too14:49
lujinluoyeah14:49
ihrachys_at least for get_sync_data_for_rule, you could avoid fetching labels at all and instead have a method that returns the needed routers.14:49
lujinluohow about using get_objects()14:50
ihrachys_since you don't use anything but id from the label, and it's already known14:50
ihrachys_we could have this method embedded into Router.get_objects, so that if metering_label_id filter is passed, it does the right tihng14:50
*** tuan_vu has joined #openstack-meeting-514:51
lujinluothat sounds good. will choose that approach14:51
ihrachys_ah wait not really. you rely on shared there14:52
lujinluoyes, but instead i can pass the router_ids i fetch from label.db_obj.routers, then use get_objects()14:53
ihrachys_true but wouldn't it trigger another fetch?14:54
ihrachys_but wait, we already trigger it for shared case...14:54
lujinluoyes14:54
ihrachys_maybe that's a mistake actually that slipped in14:54
ihrachys_it was doing get_collection_query before OVO though14:55
lujinluoit got in here https://review.openstack.org/#/c/529551/5/neutron/db/metering/metering_db.py14:55
ihrachys_so I guess no one bothered about it being optimial14:55
lujinluoanyway, let's dig more in gerrit cause we only have 5 min left now!14:57
ihrachys_but actually, for that other case with all routers fetched, it's different14:57
ihrachys_because then label.db_obj.routers won't give same result14:57
ihrachys_ok let's follow up there14:57
ihrachys_slaweq, I am sorry; you joined today. did you have smth?14:58
slaweqihrachys_: no14:58
slaweqI just wanted to join :)14:58
ihrachys_ok, just checking :) thanks for joining :)14:58
lujinluoslaweq: we are happy that you are here!14:59
slaweqI will try to be here every week14:59
slaweqif I will not forget :)14:59
ihrachys_we don't really have much time left. if you have questions about some patches that were not discussed, please ping me in irc or email after this meeting, I will try to help.14:59
tuan_vuAwesome, Slawek14:59
ihrachys_slaweq, great. your help would be of great value.15:00
ihrachys_ok we are officially out of time15:00
ihrachys_ciao15:00
ihrachys_#endmeeting15:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"15:00
openstackMeeting ended Thu Jan 25 15:00:18 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/neutron_upgrades/2018/neutron_upgrades.2018-01-25-14.02.html15:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/neutron_upgrades/2018/neutron_upgrades.2018-01-25-14.02.txt15:00
tuan_vuSee you guys later15:00
openstackLog:            http://eavesdrop.openstack.org/meetings/neutron_upgrades/2018/neutron_upgrades.2018-01-25-14.02.log.html15:00
slaweqbye15:00
tuan_vu:)15:00
lujinluosee you guys15:00
*** lujinluo has quit IRC15:01
*** tuan_vu has quit IRC15:03
*** ihrachys_ is now known as ihrachys15:08
*** hoangcx_ has quit IRC15:09
*** annp has quit IRC15:22
*** slaweq has quit IRC15:57
*** slaweq has joined #openstack-meeting-515:58
*** slaweq has quit IRC16:02
*** yamahata has quit IRC16:11
*** ricolin has quit IRC16:45
*** slaweq has joined #openstack-meeting-516:49
*** slaweq has quit IRC16:53
*** hungpv_ has quit IRC17:19
*** mjturek has joined #openstack-meeting-517:20
*** lamt_ has quit IRC17:32
*** yamamoto has quit IRC17:40
*** yamamoto has joined #openstack-meeting-517:43
*** yamamoto has quit IRC17:44
*** yamamoto has joined #openstack-meeting-517:44
*** derekh has quit IRC17:54
*** yamamoto has quit IRC18:42
*** yamahata has joined #openstack-meeting-518:56
*** yamahata has quit IRC19:09
*** yamamoto has joined #openstack-meeting-519:43
*** yamamoto has quit IRC19:55
*** cleong has quit IRC21:32
*** yamahata has joined #openstack-meeting-522:02
*** yamamoto has joined #openstack-meeting-522:05
*** slaweq_ has joined #openstack-meeting-522:13
*** slaweq_ has quit IRC22:15
*** slaweq_ has joined #openstack-meeting-522:16
*** slaweq_ has quit IRC22:18
*** slaweq_ has joined #openstack-meeting-522:19
*** slaweq_ has quit IRC22:23
*** yamahata has quit IRC23:08

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