Tuesday, 2021-08-24

*** redrobot0 is now known as redrobot06:29
*** rpittau|afk is now known as rpittau07:27
yasufumhi, tacker team08:01
yasufum#startmeeting tacker08:02
opendevmeetMeeting started Tue Aug 24 08:02:26 2021 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.08:02
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:02
opendevmeetThe meeting name has been set to 'tacker'08:02
* yasufum #link https://etherpad.opendev.org/p/tacker-meeting08:04
yasufumwe have two topics from w-juso and ueha08:04
yasufumw-juso: can you start from your topic?08:05
w-jusothanks, ok08:05
w-jusoRegarding the implementation policies of FT, I updated information in Spec as well as on EtherPad.08:05
w-jusoPoint is how to check the receiving server of Notification.08:06
w-jusoAfter checking the behaviour of LCM, check the notification receiving logs at each receiving server.08:07
w-jusoCurrently checking the completion of LCM in _wait_lcm_done function of base file.08:07
w-jusoWe are considering test to be pass if receiving logs shows COMPLETED within 1200 seconds, and fail with Timeout if exceeds 1200 seconds.08:08
w-jusoAt the Receive Server where Notification is not received, consider it pass at Timeout.08:08
w-jusoThe problem is Timeout is 1200 seconds, and it takes long time to decide if test is pass.08:09
w-jusoWe are thinking of decreasing the number of seconds, but even when LCM does not successfully end, sometimes it shows Timeout and considers test as pass.08:10
w-jusoSince decicision for completion on the server which receives notification is taken in parallel, we think that this effect of above incorrect decision can be controlled. But as of now it can’t be surely said that this is not a problem.08:10
w-jusoFrom the above contents, are there any concerns regarding FT implementation policy? Or is there any insufficient information?08:11
w-jusoAlso, is the existing pattern ok for now, for timeout method?08:11
w-jusothat's all, thanks08:11
yasufumany comment?08:15
yasufumI’m not sure about a reasonable value of timeout, but 1200 sec seems  too much as you said.08:19
uehaIs it only during second receiver server wait time that you reduce the timeout time?08:22
uehaIf you will wait for the second receiver server after receiving on the first receiver server, I think it isn't necessary to have long time.08:22
w-jusothanks! I think it is a good idea.08:24
w-jusoI can't set a time right now, but how about a 1-minute so frist?08:25
yasufumI don’t have any idea actually, but we need to try to run the test several time to find out avarage, and reasonable value.08:28
yasufumAny other idea for a think of the timeout value?08:29
uehaIf it is received, it should be received almost at the same time 1st and 2nd server, right? If so, I feel 20-30 seconds is enough.08:29
w-jusoThank you, I will refer to it.08:31
w-jusoyes, I'm aware of that, too. > If it is received, it should be received almost at the same time 1st and 2nd server, right?08:32
yasufumany other comment, or go to the next topic?08:35
uehaThere are no more comments from my side. thanks.08:38
yasufumSo, can you share your topic?08:39
uehaCurrently, there is an error in the Zuul test.08:40
uehaThe reason is that the version of the Kubernetes python-client provided with pypi has been updated on Aug 17.08:40
ueha(problem detail is please refer to https://bugs.launchpad.net/tacker/+bug/194060208:41
uehaYi Feng have been working on it with the following patches and I think it will be +1 soon.08:41
uehaI think we should merge as soon as possible. So please review it after it becomes +1.08:42
uehaThat's all from my side, thanks!08:42
uehaAs far as I can see from the status of Zuul now, the failed part is successful and seems to be working well.08:46
yasufumBy the way, Is this patch is for fixing the issue?08:47
uehaWe had a similar problem using anti-affinity rule, so Yi Feng added a fixes for this problem to it.08:50
yasufumIt’s strange for me because two similar bug reports and not sure which one is for the issue discussing here.08:51
uehaThis patch fixes two bugs, #1928153 and #1940602.08:51
yasufumYes, and one is posted before the update.08:52
yasufumAnyway, I understand it is a misc question.08:52
*** akekane_ is now known as abhishekk08:53
yasufumIt will be fixed after this patch is merged, right?08:53
yasufumI’d review it soon after the meeting, thanks08:53
uehayasufum: Thank you08:55
yasufumDone all topics on etherpad, but do you have any other topic?08:56
takahashi-tscNot from myside08:57
uehaSorry, when I was watching the Zuul status, it failed with "multide-sol-separated-nfvo" task. It need recheck..08:58
uehaThere is nothing else from my side.08:59
yasufumgot it08:59
yasufumSo, wrap up this meeting.09:00
uehaThanks, bye!09:00
takahashi-tscThanks, bye!09:00
opendevmeetMeeting ended Tue Aug 24 09:00:41 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-08-24-08.02.html09:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-08-24-08.02.txt09:00
opendevmeetLog:            https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-08-24-08.02.log.html09:00
*** rpittau is now known as rpittau|afk16:00

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!