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