08:01:56 <yasufum> #startmeeting tacker
08:01:56 <opendevmeet> Meeting started Tue Jan 25 08:01:56 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:56 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:56 <opendevmeet> The meeting name has been set to 'tacker'
08:03:33 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:04:20 <yasufum> esto-aln: thx for updating the etherpad
08:04:38 <yasufum> and we have two topics today.
08:05:07 <yasufum> First one is from edagawa_kc
08:05:49 <yasufum> Do you have any trouble for the gate test, right?
08:06:19 <yasufum> could you share your topic?
08:06:26 <edagawa_kc> Sure.
08:06:39 <edagawa_kc> At first, thank you for your reviewing the spec of this feature.
08:07:06 <edagawa_kc> Currently I'm in functional testing phase and facing two issues.
08:07:37 <edagawa_kc> Issue 1: Functional test of paging records causes TIMED_OUT in Zuul due to handling large number of pages.
08:07:49 <edagawa_kc> Issue 2: Appropriate default number of records contained in a page hasn't been decided (currently defined "100" as tentative).
08:08:51 <edagawa_kc> The detail is described in etherpad. I would like to ask your opinions/ideas to resolve them.
08:11:53 <edagawa_kc> Regarding issue 1, I suggested five options to avoid issue. For my side, option 1' or 2 is better way, but I want to ask your opinion.
08:12:02 <yasufum> Before that, there are several failures not only in ft but also others such as tox-cover
08:12:29 <yasufum> Don't we need to take care about them now?
08:12:41 <edagawa_kc> Yes, I have already noticed that and will fix it.
08:12:52 <yasufum> ok
08:15:30 <edagawa_kc> That' all from my side.
08:19:56 <ueha> As for option 2, you wrote "it affects other existing test cases using tacker.conf.", what kind of effect does it have?
08:20:00 <yasufum> Alhtough I don't how much time cost for the test itself, is opt 3 available?
08:22:52 <ueha> If paging does not work in other tests, I think there is no effect. right?  If so, I think Option 2 is simple and good.
08:26:28 <edagawa_kc> As for the effect of option 2, for example, if we want to verify new test case with using value "3" for future, it needs changing tacker.conf definition.
08:27:51 <edagawa_kc> I'm afraid the word "existing" is somehow incorrect. It means "the other tests".
08:31:22 <ueha> Thanks, I got it. If we use option 1' or 3, do you mean that we can test according to the value?
08:34:31 <edagawa_kc> As for issue 3, current behavior is that instantiation and termination repeats many times and each operation needs time to be completed.
08:35:35 <edagawa_kc> Ｉ intend to fix this behavior more and shorten TAT so as not to become TIMED_OUT.
08:38:11 <edagawa_kc> For example, preparing large records as pre-condition, using FAILURE process on purpose, etc.,
08:40:34 <yasufum> It seems so expensive comparing with our purpose of the test...
08:41:11 <edagawa_kc> "If we use option 1' or 3, do you mean that we can test according to the value?" -> In option 1', actual paged behavior is only once.
08:41:11 <ueha> The time out occur because it have to do a lot of LCM operations to prepare the data to test the paging query..
08:41:45 <yasufum> I think the feature is not so important actually as introducing a new FT.
08:41:52 <yasufum> ueha: What do you think?
08:42:42 <ueha> Yes, I think so.
08:44:16 <edagawa_kc> You are mentioning Option 4, aren't you?
08:44:33 <yasufum> If it's reasonable for the purpose
08:45:44 <yasufum> In my conclusion, it's ok to implement is as UT, but how to test should be discussed later, on gerrit possibly.
08:47:01 <edagawa_kc> Understood.
08:48:01 <yasufum> edagawa_kc: Is the issue 2 also about the FT?
08:50:18 <edagawa_kc> Issue 2 affects entire paging feature, but we can also discuss this issue on gerrit.
08:50:46 <yasufum> got it
08:51:23 <yasufum> I've just wondered if we can skip the issue2 because we don't so much time today.
08:51:32 <yasufum> So, go to the next topic.
08:52:08 <yasufum> hirogumi-noguchi: can you share your topic?
08:52:13 <hirofumi-noguchi> sure
08:52:25 <hirofumi-noguchi> My topic is about proposal to abolish default vim.
08:52:59 <hirofumi-noguchi> Current Tacker can register default VIM, which is used when some API requests and Grant response does not include vimConnectionInfo > vimId.
08:53:34 <hirofumi-noguchi> Though this implementation has advantages, there are also problems with vim's policy such as an issue which we have discussed last week in “About multi-tenant policy (ma-ooyama)”.
08:53:52 <hirofumi-noguchi> When instantiation is executed without specifying VIM, the default VIM of the user who executes instantiate is selected.
08:54:14 <hirofumi-noguchi> I think vim should be specified in the API request or Grant response basically.
08:54:27 <yasufum> sure
08:54:28 <hirofumi-noguchi> So I don't think the lack of a default vim is a problem.
08:54:50 <hirofumi-noguchi> In my opinion, it is better that Tacker will return error in cases where the default vim was previously required.
08:55:13 <hirofumi-noguchi> Since default vim is outside the scope of ETSI NFV SOL, I think it is an implementation issue.
08:55:23 <hirofumi-noguchi> I would like to hear your opinions.
08:55:31 <hirofumi-noguchi> That' all from my side. Thank you.
08:56:19 <yasufum> thanks
08:57:40 <yasufum> I'm not sure the reason why default vim was introduced, I agree with hirofumi
08:58:07 <yasufum> because we don't need to have difficulties discussed as previous meeting
08:58:16 <yasufum> if we drop the feature
08:58:42 <yasufum> I think it's simple and better.
09:01:31 <hirofumi-noguchi> I think the default vim is inherited from the legacy code.
09:01:57 <yasufum> My only concern is that there is any operator expectig to use default vim.
09:01:58 <hirofumi-noguchi> Regarding vim registration, SOL code also uses a legacy implementation.
09:03:51 <yasufum> Is there any comment for the suggestion?
09:04:38 <takahashi-tsc> I also agree that we do not need features for default VIM, And I also want to know operator's opinion.
09:08:04 <ueha> +1, sorry for late because my computer was freezed..
09:09:22 <yasufum> I think it's almost unlikely that operators want to keep default vim in tacker personally.
09:11:01 <yasufum> There are no objections right now.
09:11:25 <yasufum> hirofumi: Could you upload a blueprint for the topic as first step,
09:11:49 <hirofumi-noguchi> I got it.
09:12:29 <ma-ooyama> I don't have clear opinion about whether default vim is needed.
09:12:40 <ma-ooyama> But it is possible that some user may use NFVO that use default VIM because of limitation of its implimentation, but sorry I don't know the case.
09:12:57 <yasufum> OK, thanks.
09:14:14 <yasufum> Please continue to discuss because it's no urgent topic.
09:15:05 <yasufum> We can have discussion in the next ptg if it's needed.
09:17:24 <hirofumi-noguchi> OK. I got it. Thank you.
09:17:42 <yasufum> ma-ooyama: I'd appreciate if you give us any futher update, especially about NFVO stand point.
09:19:17 <yasufum> Any other comment?
09:19:23 <ma-ooyama> Sure, I will.
09:20:06 <yasufum> ma-ooyama: thanks
09:20:36 <yasufum> seems nothing more
09:21:00 <yasufum> So, wrap up this meeting
09:21:17 <yasufum> Thank you for joining, bye!
09:21:19 <takahashi-tsc> thanks, bye!
09:21:23 <h-asahina_> bye
09:21:26 <manpreetk> bye
09:21:28 <ueha> Thanks, bye.
09:21:29 <ma-ooyama> thanks, bye
09:21:32 <esto-aln> thanks, bye
09:21:34 <hirofumi-noguchi> Thanks, bye.
09:21:44 <yasufum> #endmeeting