08:05:39 #startmeeting tacker 08:05:39 Meeting started Tue Mar 4 08:05:39 2025 UTC and is due to finish in 60 minutes. The chair is takahashi-tsc. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:05:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:05:39 The meeting name has been set to 'tacker' 08:06:01 Hi Tacker team, so let's start the meeting. 08:06:07 #link https://etherpad.opendev.org/p/tacker-meeting 08:06:36 First topic is FT, but yasufumi-san is not here, and related to Shivam-san's topic. 08:06:53 ok.thank you 08:07:29 Second topic is about Koba-san's patch. Koba-san, any discussion is required? or we can just proceed with review now? 08:09:00 No discussion is required for my patch. Please proceed with the review. 08:10:02 OK, thanks! Actually we are facing oslo issue... Anyway, I will review it after all of related issues are resolved. 08:11:00 If Ok, we will move to the last topic, about testing improvement. 08:11:27 Thank you. Understood. 08:12:11 Good, so let's move to the last topic. 08:12:39 Shivam-san, could you explain the discussion points from you? 08:12:56 yes 08:13:49 This topic is continuation of recently discussed topic "CI Resource Optimization: Reducing Resource Consumption" in which it was decided to proceed with the approach of moving some of the jobs to periodic queue. 08:14:56 So, A patch is created to implement the periodic queue and some tacker jobs have been moved from the check queue to the periodic queue to reduce resource usage. 08:15:21 Patch URL: https://review.opendev.org/c/openstack/tacker/+/942762 08:16:51 For this patch, retrieved node consumption (for time range 03/03/2025 to 04/03/2025) using script and it showed 67 total nodes used with an average time of 20:17:59 [nodehour] per patch. 08:18:03 On comparing to previous data (where 132 node per patch were being consumed), Node usage is reduced by about half, indicating a reduction in resource consumption. 08:19:08 But currently period/interval of periodic jobs is set for daily execution which will increase overall node consumption because of daily execution of periodic jobs even if no new patch is uploaded. 08:20:03 So, I would like to know community member's opinion on what should be ideal period (weekly or monthly) for periodic jobs. 08:21:06 Another concern is that splitting userdata and compliance tests into smaller jobs (15-17 jobs) for reducing testcase time might increase node usage again because in check queue, jobs will be increased again after split.. 08:21:45 And, this increase in node usage could negate the benefits of shifting jobs to the periodic queue. 08:22:38 so, I would like to know community members opinion on how can this affect be managed in this case. 08:22:43 thanks 08:23:22 Thanks. 08:25:04 Regarding first topic, I'm not sure how to decide it. Or, we may discuss second topic first, and based on the concrete testing list, we should discuss period for periodic jobs. 08:25:35 Any comments? 08:26:43 First topic, my personal answer is once a month. Considering the pace of our team development activities, that would be sufficient... 08:27:55 Thanks. It is useful information. This decision should be by actual developers. 08:29:23 We develop and operate in a private environment before submitting to the community, so we considered that to be sufficient. 08:30:45 Thanks, I've write your and my comments in etherpad. I believe yasufumi-san will read this later. 08:31:27 Probably, we cannot make final conclusion today. We will continue to discuss it. 08:31:53 Thank you. 08:32:49 Regarding second topic, maybe there are 2 points. "Is it OK to adopt current Yasufumi-san's selection?" and "Final ideal testing items structure." 08:33:18 #link https://review.opendev.org/c/openstack/tacker/+/942762 08:33:55 Because there are v1 users today, it is good to share v1 users' opinions today. 08:34:36 Any comments? 08:34:38 The second topic was difficult for me, but from looking at the patch, I can see that not all v1 tests have been moved to the periodic queue. 08:35:09 Excatly, it seems that some basic testing of v1 will remain. 08:35:53 There are concerns about excluding v1 tests, but if it's limited to those that are not active, there is no immediate problem. 08:36:27 Does "not under active development" mean it was determined based on commits? 08:38:27 I'm not sure.., I will leave your comment on etherpad and expect reply from yasufumi-san. 08:39:31 OK, I've copy the comments to etherpad. 08:39:37 Any comments from others? 08:39:44 OK. Thanks. 08:39:51 takahasi-san: Let me rephrase my second discussion point, so basically there is an ongoing activity for reduction v1 tests (userdata and compliance) execution time 08:41:03 where high time taking tests (userdata and compliance tests) are divided into smaller testcases 08:42:04 Yes, we should discuss such ongoing activity. But before that, I would like to confirm these test should be in "check", not "periodic" 08:42:05 userdata testcase is divided into 5 sub-tests. similarly, compliance is also divided in around 12-13 sub tests 08:42:35 If they should be in "check" and have issues of high time taking, we can move to technical discussion. 08:43:01 from user and developers perspective. 08:43:53 yes, and that is my concern that if we divide them it will increase number of testcases in check queue which will increase node consumption again 08:46:14 Maybe we should discuss step by step, first devide tests to "check" and "periodic" (already proposed from Yasufumi-san) and check if it is OK, then we restart tests dividing work and in parallel discuss if it lead increasing node consumption again 08:46:58 ok. thank you 08:47:57 In my personal opinion, current selection (v1-vnfpkgm, v1-k8s, v1-userdata-vnflcm, v1-compliance-sol) is OK as first step. And I want to know if there is some concerns from others. 08:48:45 I think that there is no problem with the content of periodic patch at this point. 08:50:39 the vnflcm_userdata test covers the basic functionality. 08:52:29 I copy juso-san and my comments in etherpad, and also copy Shivam san's comment because it is also important point ofviews. 08:54:20 As I said, we cannot conclude the discussion yet, but we can share our opinions with Yasufumi-san.Please see etherpad and if there is some misunderstading or lack of explanation, please add your comments. 08:55:29 Are there any comments you want to share in a hurry? 08:57:14 If nothing, I'd like to close the meeting. 08:57:16 Thank you. I have no comments right now. If I have any thoughts, I'll add them to the etherpad. 08:57:23 Thanks 08:57:54 nothing from myside. I'll add my additional comment to etherpad. 08:58:00 thanks 08:59:04 OK, then let's close the meeting, thank you! 08:59:14 thanks, bye 08:59:20 bye 08:59:50 #endmeeting