08:02:26 <yasufum> #startmeeting tacker
08:02:26 <opendevmeet> Meeting 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:26 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:26 <opendevmeet> The meeting name has been set to 'tacker'
08:04:03 * yasufum #link https://etherpad.opendev.org/p/tacker-meeting
08:04:27 <yasufum> we have two topics from w-juso and ueha
08:05:00 <yasufum> w-juso: can you start from your topic?
08:05:13 <w-juso> thanks, ok
08:05:52 <w-juso> Regarding the implementation policies of FT, I updated information in Spec as well as on EtherPad.
08:06:12 <w-juso> https://review.opendev.org/c/openstack/tacker-specs/+/787135
08:06:35 <w-juso> Point is how to check the receiving server of Notification.
08:07:06 <w-juso> After checking the behaviour of LCM, check the notification receiving logs at each receiving server.
08:07:31 <w-juso> Currently checking the completion of LCM in _wait_lcm_done function of base file.
08:07:52 <w-juso> https://github.com/openstack/tacker/blob/master/tacker/tests/functional/sol/vnflcm/base.py#L773
08:08:10 <w-juso> We are considering test to be pass if receiving logs shows COMPLETED within 1200 seconds, and fail with Timeout if exceeds 1200 seconds.
08:08:42 <w-juso> At the Receive Server where Notification is not received, consider it pass at Timeout.
08:09:20 <w-juso> The problem is Timeout is 1200 seconds, and it takes long time to decide if test is pass.
08:10:04 <w-juso> We 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:42 <w-juso> Since 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:11:05 <w-juso> From the above contents, are there any concerns regarding FT implementation policy? Or is there any insufficient information?
08:11:34 <w-juso> Also, is the existing pattern ok for now, for timeout method?
08:11:56 <w-juso> that's all, thanks
08:15:16 <yasufum> thanks
08:15:36 <yasufum> any comment?
08:19:08 <yasufum> I’m not sure about a reasonable value of timeout, but 1200 sec seems  too much as you said.
08:22:04 <ueha> Is it only during second receiver server wait time that you reduce the timeout time?
08:22:52 <ueha> If 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:24:13 <w-juso> thanks! I think it is a good idea.
08:25:46 <w-juso> I can't set a time right now, but how about a 1-minute so frist?
08:28:10 <yasufum> I 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:29:00 <yasufum> Any other idea for a think of the timeout value?
08:29:26 <ueha> If 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:31:51 <w-juso> Thank you, I will refer to it.
08:32:41 <w-juso> yes, 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:35:19 <yasufum> OK
08:35:39 <yasufum> any other comment, or go to the next topic?
08:38:35 <ueha> There are no more comments from my side. thanks.
08:39:41 <yasufum> So, can you share your topic?
08:39:56 <ueha> Yes,
08:40:11 <ueha> Currently, there is an error in the Zuul test.
08:40:33 <ueha> The reason is that the version of the Kubernetes python-client provided with pypi has been updated on Aug 17.
08:41:00 <ueha> (problem detail is please refer to https://bugs.launchpad.net/tacker/+bug/1940602
08:41:26 <ueha> Yi Feng have been working on it with the following patches and I think it will be +1 soon.
08:41:35 <ueha> https://review.opendev.org/c/openstack/tacker/+/791123
08:42:07 <ueha> I think we should merge as soon as possible. So please review it after it becomes +1.
08:42:24 <ueha> That's all from my side, thanks!
08:44:55 <yasufum> thanks
08:46:20 <ueha> As far as I can see from the status of Zuul now, the failed part is successful and seems to be working well.
08:47:15 <yasufum> By the way, Is this patch is for fixing the issue?
08:47:39 <ueha> Yes
08:50:35 <ueha> We had a similar problem using anti-affinity rule, so Yi Feng added a fixes for this problem to it.
08:51:25 <yasufum> It’s strange for me because two similar bug reports and not sure which one is for the issue discussing here.
08:51:56 <ueha> This patch fixes two bugs, #1928153 and #1940602.
08:52:26 <yasufum> Yes, and one is posted before the update.
08:52:51 <yasufum> Anyway, I understand it is a misc question.
08:53:23 <yasufum> It will be fixed after this patch is merged, right?
08:53:58 <ueha> Yes
08:53:59 <yasufum> I’d review it soon after the meeting, thanks
08:55:08 <ueha> yasufum: Thank you
08:56:18 <yasufum> OK
08:56:47 <yasufum> Done all topics on etherpad, but do you have any other topic?
08:57:12 <takahashi-tsc> Not from myside
08:58:29 <ueha> Sorry, when I was watching the Zuul status, it failed with "multide-sol-separated-nfvo" task. It need recheck..
08:59:10 <ueha> There is nothing else from my side.
08:59:32 <yasufum> got it
09:00:12 <yasufum> So, wrap up this meeting.
09:00:23 <yasufum> bye!
09:00:28 <ueha> Thanks, bye!
09:00:29 <masaki-ueno> bye
09:00:31 <takahashi-tsc> Thanks, bye!
09:00:33 <w-juso> bye
09:00:36 <manpreetk> bye
09:00:41 <yasufum> #endmeeting