08:01:34 <yasufum> #startmeeting tacker
08:01:34 <opendevmeet> Meeting started Tue Nov 19 08:01:34 2024 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:34 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:34 <opendevmeet> The meeting name has been set to 'tacker'
08:01:50 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:03:14 <yasufum> three topics on the etherpad, but first two items are just for sharing the current status.
08:04:19 <yasufum> The first item is for dropping diag package and waiting for another +2.
08:04:32 <yasufum> takahashi-tsc: thanks for reviewing.
08:04:59 <yasufum> And the second one is for removing legacy engine facade.
08:05:19 <yasufum> The patch has been merged and completed.
08:06:06 <yasufum> The next item is "Addressing v1 testing in FT improvement"
08:06:12 <yasufum> from takahashi-tsc.
08:06:35 <takahashi-tsc> Can I start?
08:06:47 <yasufum> thanks
08:07:27 <takahashi-tsc> OK, we discussed FT improvement at the previsous PTG. And one topic which need discussion is v1 API testing.
08:08:02 <takahashi-tsc> First, I have heard my company members, they said V1 API is still used in some projects. Then v1 API related functions should be tested.
08:08:36 <takahashi-tsc> So basically I suggest to keep V1 testing.
08:09:14 <takahashi-tsc> Discussion point is:   1. Other members agree with this direction?   2. If yes, which tests are mandatory and which tests are not mandatory.
08:09:35 <takahashi-tsc> That it, I would like to hear Tacker members' opinions.
08:10:14 <yasufum> thanks
08:11:31 <takahashi-tsc> oh, just one more thing. I already list up v1 related test sets and write my personal opinion.
08:11:39 <takahashi-tsc> in etherpad.
08:11:46 <yasufum> Let's back to the proposal at the previous ptg.
08:11:49 <yasufum> #link https://94a6feb49b19adc032b0-73ae00c4c0341f1a752104576c0d94a3.ssl.cf1.rackcdn.com/932974/3/check/openstack-tox-docs/f2803df/docs/specs/2025.1/reduce-fts/index.html
08:13:48 <yasufum> I'd like to confirm that the tests are really required to be remained on zuul as "voting" tests?
08:14:26 <yasufum> althouh you can still run the tests on local env.
08:15:14 <takahashi-tsc> That's an important point too. For example, considering something like tacker-functional-devstack-multinode-sol-vnflcm-userdata, which requires a long time and should be considered for thoroughness, it might be okay to go with a non-vote.
08:17:38 <takahashi-tsc> I think... sol-vnflcm and sol-vnfpkgm are mandatroy, but it might be OK to make others non-vote.
08:18:06 <yasufum> One of the concern is we have to wait a zuul test even if it's non-voting.
08:18:32 <yasufum> Although no need to retry if it's failed.
08:20:13 <takahashi-tsc> Hmm, you are correct. But in my understanding, the runtime of Zuul depend on the longest test among all of them.
08:21:02 <yasufum> yes
08:21:20 <takahashi-tsc> (the longest test is compliance-devstack-multinode-sol... we should shourten it,,,)
08:22:08 <takahashi-tsc> Anyway, removing sol-vnflcm-userdata does not affect waiting time of Zuul
08:22:17 <takahashi-tsc> in my understanding.
08:23:31 <yasufum> I'm trying to divide time consuming tests mainly for v2.
08:24:18 <takahashi-tsc> Ah, yes I just remembered. Yes, this leads to a discussion on whether to implement it for sol-vnflcm-userdata as well
08:24:38 <yasufum> I'm also expecting you to reduce the time of sol compliance tests.
08:24:59 <yasufum> yes
08:25:17 <yasufum> tacker-functional-devstack-multinode-sol-vnflcm-userdata
08:26:00 <yasufum> should be revised at least if we don't drop v1 tests from zuul.
08:26:11 <yasufum> at least
08:26:35 <yasufum> sorry, mistake.
08:27:49 <yasufum> Anyway, other v1 tests are acceptable to remain considering the running time.
08:29:20 <takahashi-tsc> OK. Personally, I'm starting to feel that it might be fine to keep only sol-vnflcm and sol-vnfpkgm.
08:29:38 <takahashi-tsc> But also want to hear other member's opinion.
08:30:04 <yasufum> OK, thanks.
08:30:36 <hi-koba> thank you. KDDI uses v1 and has many tenants, so we also think that v1 testing is necessary.
08:31:00 <hi-koba> Still, we support reducing the number of tests.
08:32:12 <yasufum> hi-koba: thank you for your comment.
08:32:50 <yasufum> By the way, can you do the task?
08:35:21 <hi-koba> Should I suggest ways to reduce tests based on KDDI's usage? If so, I can do it.
08:36:29 <yasufum> It's OK to divide the test scenario to reduce the total time of the test.
08:37:14 <yasufum> No need to suggest other thiings.
08:39:16 <takahashi-tsc> Are you asking also to me? Possible but depends on workload. (We will also ptoceed with deviding compliance test...)
08:39:41 <takahashi-tsc> Need to confirm our team members.
08:40:59 <yasufum> takahashi-tsc: I'd appreciate if you help us for v1, thanks.
08:41:23 <takahashi-tsc> I hope we can do it, I'll discuss internally.
08:42:07 <yasufum> Thank you for the suggestion.
08:43:33 <hi-koba> I agree with reducing the tests, but to be honest, I don’t fully understand how the testing works....
08:44:18 <yasufum> hi-koba: No need to reduce the number of tests basically.
08:45:44 <yasufum> The problem is the total time and it's OK if we can divide the test scenario into several scenarios for running them in parallel.
08:47:20 <yasufum> although it's still better to reduce the number of tests for considering maintenance.
08:49:44 <yasufum> Anyway, please continue to discuss the topic.
08:50:11 <yasufum> Can we go to the final topic?
08:50:30 <hi-koba> I see. Since I don’t understand what tasks are necessary to divide the test scenarios for parallel execution, I’m not sure if I can do it.
08:50:48 <yasufum> OK, thanks.
08:51:27 <hi-koba> I just added final topic to the etherpad.
08:51:41 <yasufum> yeah, I've found it.
08:51:49 <yasufum> about the spec freeze.
08:51:56 <hi-koba> thanks
08:52:03 <hi-koba> yes
08:52:52 <hi-koba> Could you tell me about the schedule for the spec freeze? Will it be decided from now?
08:54:45 <yasufum> I didn't make any notice for that because the number of specs is just one at the vPTG and no need to consider actually.
08:55:07 <yasufum> Do you have any plan to propose a spec now?
08:56:43 <hi-koba> We were planning to propose specs for some of the features KDDI raised during the vPTG as much as possible.
08:57:29 <yasufum> understand.
08:58:17 <hi-koba> But because of work, I’m not sure how much I can do.
09:00:24 <yasufum> You need to propose specs for all items basically.
09:01:37 <yasufum> However, it's not required for some simple proposal or so.
09:02:43 <yasufum> In my opinion, it's required for the second and third proposal of yours.
09:02:58 <yasufum> Add default_secret_key Option to [vim_keys] for Multi-Master Tacker Deployment
09:03:08 <yasufum> and
09:03:10 <yasufum> Enhancement of the Ansible Driver (sample mgmt driver)
09:03:18 <yasufum> #link https://etherpad.opendev.org/p/oct2024-ptg-tacker
09:03:56 <hi-koba> i see.
09:04:25 <yasufum> For the first item, it looks a small update and no need to do.
09:05:09 <hi-koba> thank you
09:05:32 <yasufum> Anyway, it's fine if we can decide the date of spec freeze for today.
09:05:52 <hi-koba> Understood.
09:06:34 <yasufum> Do you have any suggestion? What do you think how much time required to prepare the specs?
09:07:12 <yasufum> In my opinion, we don't need to hurry to fix the specs in this release.
09:07:29 <yasufum> So, for example, how about the end of this year?
09:08:13 <hi-koba> I think the end of the year is fine.
09:09:02 <yasufum> Thanks.
09:09:23 <hi-koba> I will proceed with preparing the 2 specs to submit by the end of the year.
09:09:26 <hi-koba> thanks
09:10:46 <yasufum> and also merge them before the deadline.
09:11:09 <yasufum> It's over the end of time of this meeting.
09:11:24 <yasufum> So, let's close the meeting if you have no more topic.
09:11:37 <takahashi-tsc> nothing from my side
09:11:43 <yasufum> good
09:11:56 <hi-koba> ok
09:12:01 <hi-koba> thanks
09:12:03 <yasufum> Thank you for joining, bye!
09:12:07 <takahashi-tsc> bye
09:12:10 <hi-koba> bye!
09:12:13 <yasufum> #endmeeting