08:01:44 <yasufum> #startmeeting tacker
08:01:44 <opendevmeet> Meeting started Tue May 10 08:01:44 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:44 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:44 <opendevmeet> The meeting name has been set to 'tacker'
08:02:19 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:02:57 <yasufum> We have one item for discussion today.
08:03:14 <yasufum> #topic About Improve V2 code's UT Coverage
08:03:23 <yasufum> from caishuwen
08:04:20 <yasufum> caishuwen: Can you share your topic shortly?
08:04:25 <caishuwen> ok
08:04:47 <caishuwen> I will start share my topic.
08:04:50 <caishuwen> Regarding improving the ut code coverage of v2 discussed earlier at the vptg conference. We have discussions within our internal team. Below is our view.
08:05:07 <caishuwen> 1. First of all, the insufficiency of UT leads to a lot of rework of FT, so although the current tacker has no major functional problems, it is still necessary to improve the coverage of UT.
08:06:09 <caishuwen> 2. As discussed at the previous meeting, a large number of UT codes will increase maintenance costs, so currently UT tests will be performed only on the public methods in the v2 lifecycle. For example some common methods in utils. It is expected to cover the codes in the major lifecycles of instantiate, scale, heal, terminate, change-ext-conn, and change-vnf-pkg.
08:08:28 <caishuwen> The above two points are our team's opinions. Do you have any opinions? or any suggestions for UT?
08:10:15 <yasufum> I'm still not sure how each of us can decide which function should be tested.
08:10:46 <yasufum> Do we need to have some guidelines for that?
08:12:15 <caishuwen> We plan to make a table of which methods in which files are expected to be tested this time.
08:17:39 <yasufum> umm
08:17:45 <caishuwen> Regarding guidelines, I think there are a few points to consider.
08:17:45 <caishuwen> 1. Common methods in all `utils` files should be tested.
08:17:45 <caishuwen> 2. The processing of tacker mainly focuses on infra-driver, vnflcm_driver, and the methods in these files should also be tested.
08:19:52 <caishuwen> 3. And in V2, we added local_nfvo code, and the return of grant_response in this file also needs to be tested.
08:20:56 <yasufum> What do you think everyone for the idea? Do you think it's enough for the purpose?
08:22:30 <yasufum> caishuwen: BTW, have you considered to change running UT in parallel?
08:22:51 <yasufum> Although current tacker's UTs are not run in parallel for some reason.
08:24:23 <caishuwen> This is not currently being considered. Is it to shorten the overall UT time?
08:24:37 <yasufum> Sure
08:25:14 <yasufum> Although it's not related to maintainance cost...
08:25:39 <caishuwen> But I noticed that some of our FT seems to be running in parallel.
08:26:28 <caishuwen> I haven't done any research on whether UT can run in parallel, so I can do some research to see if I can shorten the overall UT time.
08:26:36 <yasufum> yeah, FT is out of scope for parallelize.
08:26:40 <takahashi-tsc> Sorry but I forget the previous discussion, but if so (caishuwen's consideration points 1-3 are covered), what is *not* covered?
08:27:31 <takahashi-tsc> I think 1-3 seems important, so I want to know what will not be covered.
08:31:05 <caishuwen> I think some of the points that are not included are related to DB, and there are some common codes for each lifecycle in the controller. And some common methods in the conductor file are not included.and code to interact with external nfvo.
08:34:12 <takahashi-tsc> I see... hmm, they seem important a little. Do you think to cover them are diffucult to maintain? Or you just think they are low priority?
08:37:14 <caishuwen> I just think they are low priority.
08:38:42 <takahashi-tsc> OK, so you think they shuold covered too, but current your plan is to cover 1-3 first, right?
08:41:42 <caishuwen> yes
08:44:55 <takahashi-tsc> OK. I agree with such strategy. But separately, we shoujd discuss priorities of all functions... Maybe such discussion will be based on your plan table, I think.
08:45:59 <takahashi-tsc> This is my opinion, but I want to know other members' opinion.
08:47:34 <caishuwen> Yes, I will finish the table this week. We can discuss it at the next meeting.
08:47:49 <yasufum> I think we don't need to be so strict about which one should be covered or not actually
08:48:46 <yasufum> I agree to make some guidelines
08:49:19 <yasufum> but not so serious to keep the rule
08:50:29 <takahashi-tsc> yes, I don't think strict rules are needed. But without such list, it is difficult to decide rules even if it is rough rules. And, even if the rules are rough, the scope of discussion should be all functions.
08:51:44 <takahashi-tsc> I agree that final output of the discussion is guidelines.
08:54:22 <ueha> +1, I think it's good to have a guideline because it will be a standard for other developers to create UTs from now on.
08:58:32 <yasufum> seems no more comments on this topic.
09:00:11 <yasufum> Let's continue to discuss based on draft table will be proposed by caishuwen later.
09:00:27 <takahashi-tsc> +1
09:01:44 <yasufum> caishuwen: thanks for the progress!
09:02:36 <yasufum> So, wrap up this meeting if you have no more comment.
09:03:19 <yasufum> Thank you for joining, bye!
09:03:23 <caishuwen> bye!
09:03:29 <ueha> thanks, bye
09:03:29 <masaki-ueno> bye
09:03:30 <manpreetk> bye
09:03:32 <Ramona-ho-xu> bye
09:03:32 <h-asahina> bye
09:03:35 <yuta-kaz_> bye
09:03:35 <ma-ooyama> bye
09:03:43 <yasufum> #endmeeting