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