| *** hemna4 is now known as hemna | 07:38 | |
| yasufum | Hi tecker team | 08:00 |
|---|---|---|
| ueha | hi | 08:00 |
| manpreetk | Hi | 08:00 |
| masaki-ueno | hi | 08:00 |
| esto-aln | hi | 08:01 |
| takahashi-tsc | hi | 08:01 |
| h_asahina | hi | 08:02 |
| yasufum | #startmeeting tacker | 08:02 |
| opendevmeet | Meeting started Tue Feb 1 08:02:28 2022 UTC and is due to finish in 60 minutes. The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:02 |
| opendevmeet | The meeting name has been set to 'tacker' | 08:02 |
| yasufum | #link https://etherpad.opendev.org/p/tacker-meeting | 08:03 |
| yasufum | Before starting item on etherpad, I'd like to share our plan of NTT for OpenInfra Summit. | 08:05 |
| yasufum | The registration is now opening | 08:06 |
| yasufum | and the deadline is 10th Feb. | 08:06 |
| yasufum | I'm wondering to propose two items from NTT | 08:07 |
| yasufum | and asking some members in our team to join to have collaborative session. | 08:07 |
| yasufum | One is about Tacker usecase mixed VMs and containers aiming to show its feasibility | 08:10 |
| yasufum | for the latest actual usecases such as 5GC | 08:10 |
| yasufum | and another one is about feedbacks from operators with the latest requirements. | 08:10 |
| yasufum | I'd like to some more details in the next meeting. | 08:11 |
| yasufum | We have one more item, although it's not of Tacker but Keystone, from a_asahina. | 08:12 |
| yasufum | The contents will be shared in today's keystone meeting. | 08:12 |
| yasufum | a_asahina: could you have any other comment for now? | 08:13 |
| h_asahina | no, I don't | 08:13 |
| yasufum | OK, thanks | 08:13 |
| yasufum | Any comment, everyone? | 08:14 |
| yasufum | good | 08:15 |
| yasufum | So, let's move on to the item on the etherpad. | 08:15 |
| yasufum | a_asahina: Can you start? | 08:16 |
| h_asahina | okey, my topic is about error handling when tacker-conductor is down | 08:17 |
| h_asahina | I think we've already told this topic. So, some of you might rember. | 08:18 |
| h_asahina | First of all, the error handling means the error handling when the LcmOpOcc is locked to PROCESSING state (or any other -ING state) | 08:20 |
| h_asahina | In the last conversation, we decided to add cancel command to handle this problem. | 08:20 |
| h_asahina | but, in v2 API, we won't choose that option. | 08:21 |
| h_asahina | instead, we'll add the functionalities to change -ING state LcmOpOcc to FAILED_TEMP state automatically when tacker-conductor starts. | 08:22 |
| h_asahina | I think it's not a problem because operateors can do retry command manually if the non-locked LcmOpOcc is involved in the automatic transition. | 08:24 |
| h_asahina | If you have any concern, please let me know. | 08:24 |
| h_asahina | That's all from my side. | 08:25 |
| takahashi-tsc | Thanks, there is no concern about your direction itself. But why you choose it in the case of v2? | 08:26 |
| h_asahina | Do you mean why I didn't choose this in v1 but v2? | 08:27 |
| takahashi-tsc | Yes. | 08:27 |
| h_asahina | Simply becuase I follows the discussion in Xena-PTG which mentioned automatic transitions might cause a problem. | 08:28 |
| h_asahina | but when I think it again, I came to realize that it's not a serious problem. | 08:29 |
| h_asahina | I we need to do some retry after the automatic transition, we can simply add that functionalities later. | 08:30 |
| h_asahina | In this sense, we don't have a specific reason to reject the automatic transition. | 08:31 |
| h_asahina | Does this answer for you? | 08:31 |
| takahashi-tsc | Is "the discussion in Xena-PTG" https://etherpad.opendev.org/p/tacker-xena-ptg#L244 ? | 08:31 |
| h_asahina | yes | 08:31 |
| takahashi-tsc | Understood. So you think automatic transition is better solution than to implement cancel. | 08:32 |
| h_asahina | yes | 08:32 |
| h_asahina | but I've already implemented cancel in v1. I think we can leave it, but in v2, we should implement the automatic transition. | 08:33 |
| h_asahina | Do you disagree to leave it? | 08:36 |
| takahashi-tsc | OK, I agree with it, but I'd like to know takcer team's opinion. Especially, operator members opinion. | 08:36 |
| h_asahina | So do I | 08:36 |
| yasufum | How can we proceed the discussion? | 08:38 |
| yasufum | I think ma-ooyama is only the person here may have a comment for | 08:39 |
| takahashi-tsc | Simply, I'd like to know ma-ooyama's opinion... (sorry for the sudden question) | 08:39 |
| yasufum | :) | 08:40 |
| yasufum | hmm... he might be leaving | 08:42 |
| ma-ooyama | Sorry, I don't know which is better now. | 08:42 |
| ma-ooyama | Sorry for late comment. | 08:42 |
| takahashi-tsc | Thanks. If there os no strong request, I think automatictransiton is better. | 08:43 |
| yasufum | sounds good | 08:43 |
| h_asahina | Thank you for your comments, ma-ooyama: takahashi-tsc. | 08:44 |
| ueha | Sorry, just confirmation. As we've discussed before, can we assume that the tacker-conductor is normal and that only one VNF does not get stuck in PROCESSING? | 08:44 |
| h_asahina | Sorry, what do you mean "only one VNF does not get stuck"? | 08:45 |
| ueha | When the tacker-conductor is normal and other VNFs are operating normally | 08:46 |
| h_asahina | I think yes... | 08:47 |
| ueha | only one VNF is freezed in PROCESSING state | 08:47 |
| ueha | If so, I think there is no problem. thanks. | 08:47 |
| h_asahina | Could you share your thought? | 08:48 |
| h_asahina | Do you think there is a problem in the situation where multiple VNF are frozen? | 08:49 |
| ueha | I was worried if there was a pattern where I had to restart the tacker-conductor while the other VNFs were working properly. | 08:50 |
| *** akekane_ is now known as abhishekk | 08:51 | |
| ueha | and I wonder if there is no problem with the fact that it is inoperable by the user and can only be run by the administrator of the tacker-server. | 08:51 |
| h_asahina | You mean VNFs working properly will be involved in the automatic transition and changed to FAILED_TEMP? | 08:52 |
| h_asahina | The second point you mentioned (i.e., users can not fix the LcmOpOcc frozen in -ING), might be a problem, but I think it's a maitainer's problem. | 08:53 |
| h_asahina | I mean when the LcmOpOcc is frozen in -ING state, tacker-conductor doesn't work properly with high probability. | 08:54 |
| h_asahina | So, a maintainer is an appropriate role to fix it, not a user. | 08:55 |
| ueha | Okay, understand. | 08:55 |
| h_asahina | For the first point, as I mentioned above, an operator can retry the involved LcmOpOcc manually. | 08:56 |
| h_asahina | And if we want to do this (i.e., retry) automatically, we can add a new functioanlities. | 08:57 |
| h_asahina | Even if the LcmOpOcc working propery is involved in the automatic transition, it will work propery again by `retry` if the `retry` works correctly. | 08:58 |
| h_asahina | Does this answer for your question? | 08:58 |
| ueha | I got, even if the LcmOpOcc working propery is involved in the automatic transition, it will work propery again by `retry` if the `retry` works correctly. | 09:00 |
| ueha | sorry, | 09:00 |
| ueha | I was simply concerned that no other user could operate it while the tacker-conductor was restarting. | 09:00 |
| yasufum | thanks for the discussion. | 09:01 |
| yasufum | It's always difficult to take care of such a unexpected situation. | 09:02 |
| yasufum | I think it might be better to clear our policy in anywhere in our docs. | 09:03 |
| yasufum | I'm not sure where should be now. | 09:03 |
| yasufum | I'd appreciate if anyone have a proposal for the matter. | 09:04 |
| yasufum | Anyway, it's the end of the time today. | 09:04 |
| yasufum | Do you have any other comment, or can we close this meeting? | 09:04 |
| yasufum | ok, seems nothing. | 09:06 |
| yasufum | Thanks for joining, bye! | 09:06 |
| masaki-ueno | bye | 09:06 |
| manpreetk | bye | 09:06 |
| ueha | thanks, bye | 09:06 |
| h_asahina | thanks. Thank you for the discussion ueha:. | 09:06 |
| ma-ooyama | thanks, bye | 09:06 |
| h_asahina | bye | 09:06 |
| esto-aln | bye | 09:06 |
| yasufum | #endmeeting | 09:06 |
| opendevmeet | Meeting ended Tue Feb 1 09:06:58 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-01-08.02.html | 09:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-01-08.02.txt | 09:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-01-08.02.log.html | 09:06 |
| *** dasm|off is now known as dasm | 13:02 | |
| *** dasm is now known as dasm|rover | 13:02 | |
| martial | hello friends :) | 21:26 |
| *** dasm|rover is now known as dasm|off | 22:23 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!