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