08:03:07 <yasufum> #startmeeting tacker
08:03:07 <opendevmeet> Meeting started Tue Oct 26 08:03:07 2021 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:03:07 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:03:07 <opendevmeet> The meeting name has been set to 'tacker'
08:03:56 <yasufum> There are two topics on etherpad today.
08:04:00 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:04:15 <manpreetk> hi
08:04:21 <yasufum> hi
08:04:49 <yasufum> h-asahina and w-juso
08:04:49 <w-juso> hi
08:04:52 <yasufum> hi
08:05:27 <yasufum> Is it OK to start from first item, h-asahina?
08:05:34 <h_asahina> yes
08:06:06 <yasufum> go ahead please
08:06:07 <h_asahina> As I wrote in etherpad, recently, I submitted this patch: https://review.opendev.org/c/openstack/tacker/+/815211
08:06:43 <h_asahina> for this bug report: https://bugs.launchpad.net/tacker/+bug/1924917
08:07:33 <h_asahina> Actually, I had two plans to fix it, so I'd like to discuss which one is better.
08:08:35 <h_asahina> The first approach is more consistent with the current implementation, but might incur DB bottleneck.
08:09:20 <h_asahina> The second approach is opposite. It doesn't cause DB bottle neck, but might not be able to do the same operation as the current implementation.
08:10:49 <h_asahina> In the submitted patch, I took the first approach. So, the question is which one is more important: avoiding DB bottleneck or keeping consistency of the LCM operation with the current implementation.
08:11:49 <h_asahina> If you need more information to answer it, please tell me. I'll explain the details of bugs.
08:13:53 <yasufum> Is that all?
08:14:16 <yasufum> any comment, everyone?
08:17:22 <yasufum> I remember that we agreed to not store any temporal status data in database at some previous meeting.
08:18:57 <yasufum> For the point of view, It might be better to take your option a.
08:19:40 <h_asahina> I see
08:20:21 <h_asahina> In that case, we have to give up the correct operation of rollback and retry. Is it ok?
08:21:42 <h_asahina> Of cource, users can fix by hand, something like running `openstack stack delete`
08:21:50 <yasufum> However, it depends on how the usecase is critical if we think of changing the decision.
08:23:05 <takahashi-tsc> In my opinion, option a is OK. Because this is abnormal case and sometimes stored error_point does not work even if we adopt option b.
08:24:06 <h_asahina> Yes, that makes sense.
08:24:08 <takahashi-tsc> Rather than error_handling, Tacker should provide force-terminate procedure.
08:25:52 <h_asahina> You mean adding option like `openstack vnflcm terminate --force`?
08:26:44 <h_asahina> or just taking the approach a.
08:27:09 <takahashi-tsc> That is 1 example, but yes. need such operation. > terminate --force
08:27:54 <h_asahina> I think, in that case, we have to change API, don't we? That's why I didn't take that solution.
08:30:53 <takahashi-tsc> Yes... Hmm, I understand your point. But the need depends on usecase...
08:32:17 <h_asahina> If we're allowed to change API even if it results in the violation of SOL definition, I think the solution will be more simple.
08:35:58 <yasufum> I don’t think we have to keep the APIs as same as SOL completely if it is required.
08:36:35 <yasufum> without changing behaviors defined in the standards.
08:37:20 <yasufum> I think `—force` does not overwrite the SOL standards, right?
08:37:37 <yasufum> It just an extension.
08:37:50 <h_asahina> Yes. I think so too
08:37:57 <yasufum> Altough it just my opinion.
08:38:12 <takahashi-tsc> I think so too.
08:38:41 <h_asahina> Ok, I'll change the patch, and add the --force option.
08:38:53 <yasufum> We can suggest such a feature to ETSI standards futhermore
08:39:16 <yasufum> if it seems agreeable for them.
08:39:32 <h_asahina> yeah, that's a good idea.
08:39:41 <yasufum> we can make our policy clear on documentation.
08:41:19 <yasufum> if we take such a thinking of extension
08:41:46 <yasufum> Anyway, I agree to h_asahina and takahashi-tsc for the discussion.
08:42:08 <h_asahina> ok, thanks, for me, what we have to do is clear now.
08:42:20 <yasufum> other comments?
08:43:45 <takahashi-tsc> Not form myside, thanks.
08:44:04 <yasufum> thanks
08:44:14 <yasufum> So, we can go to the next topic.
08:45:22 <yasufum> w-juso: did you make an update on Oct 24 for the meeting, right?
08:45:43 <w-juso> no update, I could discussed our policies, so I'll move it to the bottom.
08:50:40 <yasufum> Do you mean you will move it to the last part of old topics?
08:51:23 <w-juso> yes
08:53:12 <yasufum> OK. I would like to ask you to add the conclusion of the discussion because it is a little bit hard to understand what is the decision at a glance.
08:53:20 <yasufum> thanks
08:53:56 <yasufum> Oops, I have found one more topic for today.
08:54:14 <yasufum> from kentaro
08:54:22 <yasufum> kentaro: can you share your topic?
08:54:33 <kentaro> Yes.
08:54:56 <kentaro> I added a new topic, [Promotion of alignment from OpenStack Tacker to O-RAN SC].
08:55:11 <kentaro> Firstly, the overall purpose of this proposal is
08:55:18 <kentaro> to promote the widespread use of Tacker by inclusion of Tacker code in the VNFM part of the open source code set to be released by O-RAN Software Community (O-RAN SC).
08:55:36 <kentaro> And the background to this proposal is as follows.
08:55:42 <kentaro> 1. O-RAN SC is a Linux Foundation project supported and funded by O-RAN to lead the implementation of the O-RAN specifications in Open Source.
08:55:49 <kentaro> 2. O-RAN SC is developing open source software composed of a combination of existing open source code to realize O-RAN components and systems.
08:55:57 <kentaro> 3. O-RAN SC has announced a call for contributions to the MANO interface that are directly related to Tacker.
08:56:04 <kentaro> 4. As a user of Tacker, NTT DOCOMO is considering the application of Tacker to the vRAN domain, and expects to incorporate Tacker into the O-RAN standard reference model.
08:56:25 <kentaro> The concrete action plan is supposed to be as follows.
08:56:36 <kentaro> Firstly, we should discuss with OpenInfra Foundation,
08:56:45 <kentaro> to get their approval to proceed this alignment activity with the intention of the OpenStack organization,
08:56:54 <kentaro> and to request their support as the entire OpenStack community. (e.g. appealing to the public about the activity)
08:57:02 <kentaro> After that we will be able to contact O-RAN SC.
08:57:20 <kentaro> We will give a presentation to O-RAN SC on how Tacker community can contribute.
08:57:29 <kentaro> I suppose we will provide Tacker sample code and documentation to O-RAN SC and support their technical review.
08:57:38 <kentaro> That's all my explanation.
08:57:44 <kentaro> Let me know if you have any questions or comments.
09:00:11 <yasufum> Do you have any reference for O-RAN, such as project home page or so for helping our understanding.
09:01:44 <kentaro> O-RAN SC website:  https://www.o-ran.org/software
09:02:20 <kentaro> Latest release code from O-RAN SC:  https://docs.o-ran-sc.org/en/latest/
09:02:30 <yasufum> thx
09:04:47 <yasufum> By the way, what do you think who should or might be the representitive for the action plans?
09:05:15 <yasufum> It looks several plans on the note.
09:08:03 <kentaro> Basically, I think the Tacker community itself will position as the responsible body toward O-RAN SC.
09:09:56 <kentaro> We'll decide on a case-by-case basis who will work under the name of the Tacker community.
09:10:20 <kentaro> for each action plan.
09:12:23 <yasufum> one more question.
09:14:00 <yasufum> Is there any milestone or goal for the actions, such as doing a PoC or making agreement?
09:15:44 <kentaro> The goal is to have Tacker included in the code sets that O-RAN SC releases approximately every six months.
09:18:12 <kentaro> The next E version will be released in January or February of next year, and I hope to have at least O-RAN SC's agreement on the direction to incorporate Tracker by then.
09:18:58 <kentaro> That is the most recent milestone.
09:20:16 <yasufum> I have roughly understood the purpose of your proposal, also still not sure if terms of release are suitable for our release cycles or so.
09:21:58 <yasufum> Is there any other comment?
09:22:12 <yasufum> everyone
09:24:31 <yasufum> good
09:26:55 <yasufum> I think it seems enough for today.
09:27:06 <yasufum> So, close this meeting.
09:27:15 <yasufum> Thanks for joining, bye!
09:27:20 <manpreetk> bye
09:27:25 <kentaro> bye
09:27:25 <takahashi-tsc> bye
09:27:29 <w-juso> bye
09:27:31 <esto-aln> bye
09:27:35 <ueha> bye
09:27:39 <yasufum> #endmeeting