08:02:23 <yasufum> #startmeeting tacker
08:02:23 <opendevmeet> Meeting started Tue Feb 25 08:02:23 2025 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:23 <opendevmeet> The meeting name has been set to 'tacker'
08:02:54 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:03:30 <yasufum> Let's start the meeting.
08:04:07 <yasufum> The first item is just to share the current status of the topic.
08:04:45 <yasufum> I completed the team survey for tacker team.
08:05:13 <yasufum> So, we're ready to join the next vPTG.
08:06:05 <yasufum> And the second item is for discussion about the task for reducing FT time.
08:06:21 <yasufum> from shivam
08:06:52 <shivam> Hi
08:06:55 <yasufum> hi
08:07:10 <shivam> Next topic is "CI Resource Optimization: Reducing Resource Consumption"
08:07:39 <shivam> On our patch for "Refactoring High Time-Consuming V1 Functional Test Cases", received comment regarding high CI resource consumption.
08:08:13 <shivam> As per the comment, since current CI setup runs many jobs concurrently, it consumes too much resource.
08:09:21 <shivam> A specific example mentioned in comment, explains that change is failing in pre-run on its devstack jobs whereTacker CI runs 33 DevStack jobs, each utilizing 4 nodes, with up to three retries due to deterministic failures, leading to excessive node consumption.
08:10:46 <shivam> To reduce the CI resource usage, they suggest to move some of the jobs to a periodic queue where these jobs will be executed at a fixed time interval.
08:11:31 <shivam> But I think, moving the jobs to periodic queue will affect test coverage and test feedback will be delayed.
08:12:29 <shivam> Hence, I would like to know community members opinion that What approaches or methods can be implemented to reduce CI resource usage?
08:14:17 <shivam> Also, if the suggested approach is acceptable (move some jobs to the periodic queue, even if it delays feedback for non-critical tests) or not?
08:14:23 <shivam> thanks
08:15:15 <yasufum> thanks
08:16:34 <yasufum> We've has before the similar discussion actually
08:17:22 <yasufum> although I don't know and talked about periodic queue.
08:18:17 <yasufum> The cause of the issue was the total amount of time for FT was too huge
08:19:04 <yasufum> and we had been suffered, especially at the end of release cycles.
08:19:44 <yasufum> So, We decided to reduce the time first, then the num of the tests
08:19:54 <yasufum> for easing the bad situation.
08:20:35 <yasufum> We didn't know how the resources is consumed on test env at that time.
08:21:59 <yasufum> We don't have expected to the amount of resource consuming is so much actually.
08:22:01 <shivam> generally periodic queue means (queue items will process at a defined time interval)
08:23:14 <shivam> but i think this option will impact the overall test coverage
08:25:48 <yasufum> Could you elaborate more how we can do that?
08:30:34 <yasufum> takahashi-tsc: shivam might not able to join again. Do you have any comment?
08:31:06 <takahashi-tsc> Maybe his connect is lost... My concern is, should we discuss anything with Kajinami-san or involved members? to decide Tacker's direction. Because he gave some comments to Shivam's patch.
08:32:02 <takahashi-tsc> We are still investigating the technical details, but neutron and some other projects seems to define some periodic tasks so it may be possible.
08:32:51 <yasufum> shivam: welcome again.
08:33:00 <shivam> sorry, I got disconnected
08:33:40 <shivam> To answer your question : Could you elaborate how would you do that?
08:33:50 <yasufum> I've just been told from takahashi-san about the periodic queue.
08:34:03 <shivam> ok
08:35:43 <yasufum> Is there any example for using it on neutron, right?
08:39:35 <yasufum> hello?
08:39:42 <shivam> could you elaborate your question as i missed some message when i was disconnected
08:40:45 <takahashi-tsc> https://zuul.opendev.org/t/openstack/builds?job_name=networking-sfc-tempest-periodic
08:40:57 <takahashi-tsc> This probably seems to be clearly defined as a periodic job. (I haven't looked at the details yet...)
08:41:26 <yasufum> thanks
08:42:34 <yasufum> Anyway, go back to the discussion proposed from shivam.
08:43:17 <yasufum> I think coverage is not the first priority.
08:44:01 <shivam> ok
08:44:12 <yasufum> So, your suggestion for using the queue might be acceptable.
08:44:39 <yasufum> And more, I suggested to reduce the num of tests, mainly from v1 tests, at that time.
08:45:17 <yasufum> I also suggested to run the FTs on local environment instead of running on zuul.
08:46:13 <shivam> ok, so in that case how should we assign testcase priority (for moving to periodic queue)
08:46:33 <shivam> Assign priorities to each test case within V1, V2, and Compliance?
08:46:56 <shivam> Assign priorities to the V1, V2, and Compliance sets as a whole?
08:47:10 <yasufum> My opinion is it's under active development or not exactly.
08:47:29 <yasufum> So, many of v1 tests can be the candidates.
08:48:04 <shivam> ok
08:48:38 <takahashi-tsc> also, we should confirm KDDI members' opinion.
08:48:46 <yasufum> right
08:49:20 <yasufum> If using periodic queue is more useful than just droping, I agree to do so.
08:50:57 <takahashi-tsc> +1
08:51:33 <shivam> ok, I will look into this point (which one will be better: periodic queue or dropping some testcase) and discuss in next meeting based on findings
08:52:39 <yasufum> takahashi-tsc: can you organize to have a meeting with KDDI guys because they cannot to join this meeting usually?
08:53:21 <takahashi-tsc> OK, first I will confirm with KDDI and if required we will arrange the meeting.
08:54:02 <yasufum> Thanks
08:55:04 <yasufum> I'd also ask to review this patch to ease the issue.
08:55:06 <yasufum> https://review.opendev.org/c/openstack/tacker/+/941115/comments/f1ebe18d_b9dea0de?tab=comments
08:55:57 <takahashi-tsc> Sure, I'll review asap
08:56:01 <yasufum> As discribed in my comment, a plan to use rootwrap was disappeared and it's acceptable.
08:56:08 <yasufum> thx
08:56:46 <yasufum> So, let's move on the next.
08:57:06 <yasufum> The rest of two items are for asking review.
08:57:38 <yasufum> Please join the review if it's ready.
08:58:39 <yasufum> If you have no comment, close this meeting.
08:59:11 <yasufum> good
08:59:55 <yasufum> Thanks for joining, bye!
08:59:57 <takahashi-tsc> thanks, bye.
09:00:10 <yasufum> #endmeeting