08:02:14 <yasufum-o> #startmeeting tacker
08:02:14 <opendevmeet> Meeting started Tue Mar  8 08:02:14 2022 UTC and is due to finish in 60 minutes.  The chair is yasufum-o. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:14 <opendevmeet> The meeting name has been set to 'tacker'
08:03:32 <yasufum-o> There are five topics today.
08:04:26 <yasufum-o> I'd like to share my items, 2nd and 3rd, because it's just announcements.
08:04:58 <yasufum-o> 2nd one is about yoga release of python-tackerclient.
08:05:33 <yasufum-o> There are some patches dropped in stable
08:06:27 <yasufum-o> So, update for statle is required.
08:06:48 <yasufum-o> I'm not still sure the reason, but I would like to upload from NTT.
08:07:10 <yasufum-o> 3rd item is about RC1..
08:07:46 <yasufum-o> Please keep in mind the deadline.
08:08:13 <yasufum-o> any comment?
08:09:00 <yasufum-o> good
08:09:27 <yasufum-o> So, can we go to the 1st item next?
08:09:46 <ueha> yes, 1st one is my topic.
08:09:58 <yasufum-o> thx, go ahead.
08:10:01 <ueha> We found a error when we implementing multi-tenant FT on the CNF side.
08:10:08 <ueha> We operated to termination with member role resulted in the following error:
08:10:19 <ueha> Error: Entity namespace for "vnf_resources" has no property "tenant_id"
08:10:51 <ueha> I think this error happens not only in CNF but also in VNF because it happens in the common processing unit [1].
08:11:00 <ueha> [1] https://opendev.org/openstack/tacker/src/branch/master/tacker/vnflcm/vnflcm_driver.py#L677-L678
08:11:19 <ueha> In order to terminate successfully with member role, should we add a `tenant_id` to `vnf_resource` as well as vnf_lcm_subscriptions or vnf_lcm_op_occs like patch [2]? or any other fix?
08:11:27 <ueha> [2] https://review.opendev.org/c/openstack/tacker/+/799022
08:11:49 <ueha> w-juso or manpreetk: What do you think about this error and fix? and could you post patch for this error?
08:12:22 <ueha> Didn't it happen when you tested in a local environment?
08:12:45 <ueha> that's all from myside, thanks,
08:14:59 <ueha> w-juso and manpreetk: any answer?
08:17:47 <manpreetk> ueha: Thanks for sharing. As you are aware VNF instantiation for member role is not working, therefore such scenario was not tested. But yes we could investigate the issue and upload patch.
08:18:36 <manpreetk> But again testing might be a issue, or may be on hold until VNF instantiation is enable for member role.
08:20:22 <ueha> I see.. Do you think it will work on the RC1 deadline?
08:21:23 <manpreetk> ahh that might be difficult as need to investigate.
08:22:45 <ueha> In that case, we can't merge because the CNF multi-tenant test doesn't pass. umm..
08:23:38 <ueha> Should we write in the issue of release note that the operation in member role does not work normally in Y version?
08:24:03 <ueha> what do you think?
08:24:55 <manpreetk> ueha: Yes as per my shared topic, member role user is unable to instantiate VNF and the solution might need some more time.
08:25:44 <ueha> OK, let's discuss it again on your topic.
08:26:39 <manpreetk> ueha:Thanks
08:26:44 <ueha> CNF seems to work well if the above problem is solved.
08:27:24 <ueha> So, the problem is whether to fix only CNF in Y release..
08:28:01 <yasufum-o> thanks
08:29:35 <ueha> Thanks, any other comments? If not, let's move on to the next topic.
08:31:28 <yasufum-o> manpreetk: please share your topic
08:31:33 <manpreetk> Thanks
08:32:20 <manpreetk> Please check L47
08:33:33 <manpreetk> Currently the proposed VNF instantiation solution for member role is not working. More investigation is required in the following areas:
08:33:33 <manpreetk> Identify blocking policies through source code.
08:33:33 <manpreetk> Debug the complete workflow with member role user with respect to infra setups like policy modification for nova, heat, etc (any other blocking policy).
08:33:34 <manpreetk> Somehow this activity would consume a good amount of time and could be addressed in the upcoming release.
08:35:07 <manpreetk> Please share your opinion, thats all from my side.
08:36:05 <yasufum-o> thanks
08:36:47 <takahashi-tsc> IMO, higher priority is to resolve the issue which Ueha-san shared. And very sorry but to resolve Heat role issue needs much time and not in time in Yoga release...
08:41:32 <yasufum-o> ueha: Do you have any suggestion for the fix?
08:42:04 <ueha> No, I don't have..
08:43:00 <ueha> release note of `bp/multi-tenant-policy` has been merged: https://review.opendev.org/c/openstack/tacker/+/830037
08:43:13 <ueha> If it can't make it to Y release, do we have to correct this?
08:43:23 <yasufum-o> possibly
08:44:21 <h_asahina> isn't possible to simply try to add the lacked property to vnf_resources? ueha:
08:47:06 <ueha> We haven't tried it yet, but I think it's possible. but I don't know if we have time to do it..
08:47:28 <ueha> I'll check with my colleague.
08:47:34 <h_asahina> thanks
08:48:37 <h_asahina> BTW, multitenat functionality is already available for admin role users? I think the problem only appears for member role users.
08:51:34 <h_asahina> In other words, is it possible to release multi-tenant for admin role users in Yoga and exntend it for member role users in Zeta?
08:55:03 <ueha> manpreetk: what do you think?
08:55:20 <manpreetk> +1 yes i agree with h_asahina.
08:57:35 <h_asahina> thank you two. I think that is a realistic goal. At least, we can provide multi-tenant for admin users.
08:58:49 <yasufum-o> manpreetk: Does it satistify the requirements in spec?
08:58:57 <yasufum-o> #link https://specs.openstack.org/openstack/tacker-specs/specs/yoga/multi-tenant-policy.html
09:02:41 <manpreetk> yasufum-o: No this does not satisfy spec requirement, but we could edit release note with missing functionality and partially implement in Y release.
09:06:32 <yasufum-o> I understand we don't have any alternative options for the issue for now.
09:07:22 <manpreetk> yasufum-o:Thanks
09:07:41 <yasufum-o> Anyway, we should talk about this spec in the next vPTG.
09:08:19 <manpreetk> sure
09:09:28 <yasufum-o> thanks
09:09:46 <yasufum-o> Go on to the next topic
09:09:52 <ma-ooyama> Sure. I would like to talk to you about two topics related to the sample VNF package I am working on https://review.opendev.org/c/openstack/tacker/+/832226.
09:10:17 <ma-ooyama> First, the sample can't be instantiated because of the bug of https://bugs.launchpad.net/tacker/+bug/1948925.
09:10:33 <ma-ooyama> I made a patch for this bug on https://review.opendev.org/c/openstack/tacker/+/832224, and would like you to review this.
09:11:06 <ma-ooyama> Second, the sample can't be scaled out because of the bug of https://bugs.launchpad.net/tacker/+bug/1963900.
09:11:24 <ma-ooyama> I think it is difficult to have the bug fixed before yoga release. So I want to confirm whether the following is OK.
09:11:39 <ma-ooyama> - In Yoga release, scale operation won't be supported in this sample.
09:11:48 <ma-ooyama> - Add the explanation that this sample can't support scale operation now to user guide or read me.
09:12:00 <ma-ooyama> - Fix the bug in future release, and then remove the explanation above.
09:13:38 <ma-ooyama> What do you think about this?
09:15:08 <yasufum-o> thanks
09:15:19 <yasufum-o> do you have any comment?
09:16:44 <ueha> I see the patch (https://review.opendev.org/c/openstack/tacker/+/832226) include scalable deployment flavour VNFD and BaseHot.
09:18:05 <ueha> Do you mean that you leave this VNFD and BaseHot as they are and write "not support" in document or README?
09:19:54 <ma-ooyama> I think those VNFD and BaseHot is still located in the sample, but adding explanation that scale out operation is not supported now.
09:22:06 <ueha> I am wondering if there is no problem with putting the sample that we know won't work.
09:22:58 <ueha> Can't you insert it after fixing the bug? What do other think?
09:24:56 <yasufum-o> ma-ooyama: Is there any reason why it's must be included in yoga?
09:27:37 <ma-ooyama> Sorry, I originaly thought it is a matter of tacker implementation and so whole sample package can be merged.
09:28:05 <ma-ooyama> But I understood your opinion.
09:30:02 <ma-ooyama> I understood it is better to include scalable deployment flavour after scale oparation is suceed.
09:31:49 <ueha> thanks
09:32:58 <ma-ooyama> In this case, is there something to do against losing the part of usecases in yoga release.
09:34:04 <ma-ooyama> I mean where should I explain that the scale flavour is implemented in future.
09:36:26 <ueha> I think commit message and document/README? I don't know if there is any other place to write..
09:37:27 <ueha> any other ideas?
09:39:32 <yasufum-o> I'm not sure the purpose, but seems ok.
09:42:28 <yasufum-o> ma-ooyama: any other question?
09:43:30 <ma-ooyama> Sorry I want to confirm that the sample that doesn't include scalable deployment flavour can be merged in yoga release?
09:44:55 <yasufum-o> Do you mean only rst files will be remained in this patch?
09:45:00 <yasufum-o> https://review.opendev.org/c/openstack/tacker/+/832226
09:46:54 <yasufum-o> takahashi-tsc: oops, I've found the 6th item appears.
09:46:55 <ma-ooyama> I mean the deployment flavour of ha can be remained, or whole sample should be merged after scale operation works.
09:47:43 <takahashi-tsc> Sorry, I forget to write my topic before this meeting. So I just annouce at this meeting today.
09:48:02 <yasufum-o> takahashi-tsc: got it
09:48:51 <yasufum-o> ma-ooyama: I think it's acceptable, but please check the details in your updated patch.
09:49:29 <yasufum-o> for former one.
09:49:57 <yasufum-o> ueha: do you agree?
09:50:16 <ueha> Yes, I agree.
09:50:23 <yasufum-o> thanks
09:50:29 <ma-ooyama> I understood. Thank you for a lot of comment.
09:50:46 <yasufum-o> you're welcome!
09:51:11 <yasufum-o> So, the last topic
09:51:32 <yasufum-o> takahashi-tsc: can you share it shortly?
09:51:34 <takahashi-tsc> Sorry for the late, I think we have no time ... so shout annoucement.
09:52:13 <takahashi-tsc> Please see https://etherpad.opendev.org/p/tacker-meeting#L607
09:52:43 <takahashi-tsc> We discussed O-RAN SC activities before. I'm also interested in RAN area, so I participated O-RAN SC meeting.
09:53:12 <takahashi-tsc> Basically, O-RAN SC members allow Tacker community to contribute for O-RAN SC. So I want to start contribute.
09:53:25 <yasufum-o> great!
09:53:57 <takahashi-tsc> And, I'm also looking for members who work with me. Today we have not enough time, but I'd like to continue to discuss how to proceed.
09:54:02 <takahashi-tsc> That's all, thanks.
09:55:07 <yasufum-o> Thanks for sharing your progress.
09:57:23 <yasufum-o> do you have any comment?
09:57:27 <yasufum-o> everyone
09:59:05 <ueha> We will support but the deployment system has not been established and the internal participation procedure has not been completed. We will participate as soon as we are ready!
09:59:13 <ueha> thanks.
09:59:20 <takahashi-tsc> Thanks!
10:00:05 <yasufum-o> I hope we'll continue the discussion for expanding our activity.
10:00:50 <yasufum-o> We should close this meeting today.
10:00:57 <yasufum-o> Thanks for joining, bye!
10:01:00 <manpreetk> Thanks, bye.
10:01:03 <ueha> thanks, bye
10:01:06 <masaki-ueno> bye
10:01:06 <ma-ooyama> Thanks.
10:01:22 <takahashi-tsc> bye
10:01:27 <yasufum-o> #endmeeting