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