08:01:20 <yasufum> #startmeeting tacker 08:01:20 <opendevmeet> Meeting started Tue Feb 8 08:01:20 2022 UTC and is due to finish in 60 minutes. The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:20 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:01:20 <opendevmeet> The meeting name has been set to 'tacker' 08:02:02 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting 08:02:57 <yasufum> start the meeting 08:03:17 <yasufum> The first item is mine. 08:04:16 <yasufum> As mentioned in the previous meeting, I'd like to share the contents for the next summit. 08:04:42 <yasufum> There are three items from us. 08:05:57 <yasufum> I'd appreciate if you give us your feedback on the etherpad. 08:06:28 <yasufum> Do you have any comment, or can we go to the next topic? 08:07:25 <yasufum> good 08:07:47 <yasufum> The second item is about the next vPTG. 08:08:54 <yasufum> It will be held from April 4th to 8th. 08:09:35 <yasufum> I've already reserved rooms for our team. 08:11:01 <yasufum> It's the same as previous vPTG, 6-8 UTC each day, at Austin. 08:12:02 <yasufum> Although I believe it's OK for everyone, but give me ask if you have any request for. 08:13:48 <yasufum> The deadline is Marth 11th, so I'd like to fix it before the week. 08:14:16 <yasufum> Anyway, I'll send a e-mail to announce our candidate dates on ML. 08:15:45 <yasufum> Let's move on to the next topic. 08:15:58 <yasufum> esto-aln: can you share your topic? 08:16:02 <esto-aln> yes 08:16:15 <esto-aln> thank you for having me.. I would like to proceed with my topic.. 08:16:56 <esto-aln> We found some issue with tacker during the compliance test (of robot patch).. 08:17:43 <esto-aln> Please refer to line 17 for the Log snippet... I indicated in bold those logs that I need to highlight.. 08:18:04 <esto-aln> This issue only occurs sometimes... 08:18:45 <esto-aln> so it is difficult to reproduce this issue.. we have not successfully reproduced such issue in our environment.. 08:19:19 <esto-aln> Based on our investigation, we saw to possible causes (2 points) which I shared in Line 30. 08:20:02 <esto-aln> We would like to consult, if someone from community team is familiar at this part of tacker.. 08:20:44 <esto-aln> whether our assumption is correct or if they have another idea for the cause? 08:21:10 <yasufum> thanks 08:21:55 <yasufum> Is the error happened only on your patch, or all? 08:22:23 <yasufum> I'm not sure the details of logs you shared. 08:24:20 <esto-aln> <yasufum> Is the error happened only on your patch, or all? --> We encountered this issue on our patch.. 08:25:54 <ueha> It's not a fundamental solution, but how about changing the vnfInstance name for each test? 08:25:54 <ueha> Have you already tried it? 08:27:25 <esto-aln> Yes, we already did it.. 08:27:48 <esto-aln> but probably this is still an issue.. 08:28:28 <esto-aln> since vnfInstance name might probably be set with the same name. 08:28:40 <esto-aln> by some use.. 08:28:46 <esto-aln> sorry... by some "user" 08:30:30 <ueha> Does it mean that VnfInstance name is defined on the side of SOL test codes? 08:32:47 <esto-aln> Yes, vnfInstance name was defined in the SOL test codes.. and the errors that occurred corresponded to these test cases which contains vnfInstance name (having the same name) 08:33:26 <ueha> umm.. I understood.. 08:33:58 <esto-aln> Currently, we have removed the vnfInstance name so that tacker generates the vnf Instance name... 08:35:10 <esto-aln> but the point is that using the vnfInstance name and having deleted_at to be updated up to the seconds.. will trigger this issue.. 08:35:29 <esto-aln> using the vnfInstance name ---> using the same vnf Instance name 08:36:09 <esto-aln> sorry for the mistake.. 08:37:09 <takahashi-tsc> I heart that now there is no issues for development of applying Robot, because we can controll VNF name by test code. esto-aln's question is, is it OK that "deleting VNFs in 1 second leads to error"? 08:37:44 <yasufum> I think it's acceptable. 08:38:30 <yasufum> By the way, such a case can be happened on the test, but usual cases, right? 08:38:46 <esto-aln> Our assumption is that this might be possible bug.. 08:40:06 <esto-aln> Yes, it will happen in usual cases. 08:40:42 <yasufum> Do you mean we should fix the code itself other than test anyway? 08:42:26 <esto-aln> Yes, I think so.. 08:46:03 <takahashi-tsc> I think it is OK that Tacker team just decide whether this issue will be fix or not. But at least, "DBDuplicateEntry" seems a little strange for users. 08:46:10 <takahashi-tsc> This is just my opinion. 08:47:00 <yasufum> Simply we can have two choices, changing the format of the key, or waiting for a second in the function. 08:47:48 <yasufum> Although I don't want to take the former one. 08:47:57 <yasufum> Do you have any other idea? 08:49:46 <takahashi-tsc> Does "waiting~~~" mean users should wait 1 second(and we should explain it in docs)? or Tacker wait a second in delete procedure when DBDuplicateEntry is detected? 08:50:42 <yasufum> I mean later one, waiting inside tacker. 08:50:58 <yasufum> I'm not still sure it's feasible or not. 08:53:59 <yasufum> I don't oppose the idea to ask users to wait as a second best solution... 09:00:16 <takahashi-tsc> Hmm, I think we do not need to decide today, We will confirm it(wait a second) is feasible or not and will share the result. 09:01:23 <yasufum> i see 09:02:24 <yasufum> esto-aln: Why don't you continue to discuss on gerrit? 09:05:38 <esto-aln> yes, it's okay or let's discuss at IRC.. 09:07:05 <yasufum> thanks 09:07:35 <yasufum> All topics done for today. 09:12:28 <yasufum> let's close this meeting. 09:12:34 <yasufum> Thanks for joining, bye! 09:12:41 <takahashi-tsc> thanks bye 09:12:44 <ueha> thanks, bye 09:12:48 <esto-aln> thank you very much, bye! 09:13:13 <manpreetk> bye. 09:13:24 <ma-ooyama> thanks, bye 09:13:37 <masaki-ueno> bye 09:13:54 <yasufum> #endmeeting