08:04:20 <yasufum> #startmeeting tacker
08:04:20 <opendevmeet> Meeting started Tue Jan 18 08:04:20 2022 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:04:20 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:04:20 <opendevmeet> The meeting name has been set to 'tacker'
08:06:38 <yasufum> We have three topics on the etherpad today.
08:06:54 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:08:22 <yasufum> Without the item from esto-aln, it's the same topic, multi-tenant spec, right?
08:09:25 <yasufum> I agree to the proposal from w-juso.
08:10:44 <w-juso> thank you for check. I'll fix it.
08:10:53 <yasufum> If anyone has a objection for the proposal, I'd like to start from ma-ooyama.
08:11:25 <ueha> I agree too. Originally, asahina-san commented on the spec.
08:13:57 <w-juso> yes, thank you asahina-san, ueha-san.
08:14:49 <h_asahina> your welcome :)
08:16:28 <ueha> :)   yasufum: seems no objection, go ahead.
08:16:49 <yasufum> ma-ooyama: are you here?
08:17:21 <ma-ooyama> Yes, I'll share my topic.
08:17:58 <ma-ooyama> I wrote details about the third opinion I explained last week in this launchpad. (https://bugs.launchpad.net/tacker/+bug/1958197)
08:18:32 <ma-ooyama> The opinion is this: 3)The default VIM of the user who excutes createVNF should be selected when instantiation is excuted without specifying VIM, because VNF's tenant is determined by users who creates the VNF.
08:19:40 <ma-ooyama> The point is that the default vim should be selected from the VNF's tenant when instantiation is executed without specifying any vim, but actually the default vim is selected from the tenant of the user who executes instantiation.
08:20:21 <ma-ooyama> I would like to confirm whether our understanding in this lanunchpad is right.
08:28:05 <takahashi-tsc> 1 confirmation, your expected result is test_vnf is instantiated with test_vim_1, right?  not instantiation is failed.
08:30:47 <ma-ooyama> I have no answer which is better, but at least test_vim_2 shouldn't be selected.
08:32:20 <ueha> I think there are two ways:
08:32:23 <ueha> 1. compare the default VIM's tenant with the VNF's tenant and give an error if they are not the same tenant.
08:32:30 <ueha> 2. if instantiate by admin-role user, Tacker uses default VIM of VNF's tenant
08:33:48 <takahashi-tsc> Yes, and at least, w-juso and manpreetk's work include 1,
08:36:24 <takahashi-tsc> I agree that we have the 2 ways, so I'd like to know the opinion about 2. i.e. Is 2, needed or not.
08:38:59 <ueha> I feel subtle to use VIM different tenants about "2" (test_user_1 uses VIM of test_tenant_2 is strange).
08:39:11 <ueha> I think "1" is better.
08:39:59 <yasufum> I think 2 is not so strange for me as a default behavior, but not sure it should be...
08:40:15 <h_asahina> Just to confirm, if rejecting 2, admin users can only instantiate VIM in admin project, right?
08:42:12 <takahashi-tsc> In my understanding, admin can instantiate VNF with explicitly specified VIM. And if VNF's tenant and VIM's tenant are same, instantiation will be success.
08:44:13 <h_asahina> That sounds natural. I mean the instantiation will be success only if VNF's tenant and VIM's tenat are same.
08:44:56 <h_asahina> I thought accepting 2 will break this rule. Am I wrong?
08:47:43 <yasufum> may be so
08:48:13 <takahashi-tsc> I think it is already agreed by team. Current discussion is about "default VIM" that is a VIM in the case that user does not specify VIM.
08:48:37 <yasufum> yes
08:48:52 <takahashi-tsc> Current behavior is, admin execute instantiation with admin's VIM, and instantiation is success. This is wrong behavior.
08:49:17 <takahashi-tsc> s/instantiateion/instantiation of non-admin's VNF/
08:49:42 <takahashi-tsc> ueha's option  1. is, tacker is reject this instantiation.
08:50:30 <takahashi-tsc> ueh's option 2. is admin use non-admin's VIM and instantiation is success. I think 2. has no problem.
08:50:39 <takahashi-tsc> But my question is, 2. is needed or not.
08:50:52 <takahashi-tsc> ueha: Is my understanding correct?
08:50:58 <yasufum> I'm wondering we don't need to define default vim if we introduce such a rule...
08:51:41 <h_asahina> I undersstood 1 and I think we should do so. What I couldn't understand is what the actual behavior of option 2 looks like.
08:51:45 <ueha> thakahashi-tsc: correct.
08:54:34 <h_asahina> I thought admin users can instantiate VNF with VIM in different tenant (non-admin users).
08:55:50 <h_asahina> If we agreed with 1, rejecting 2 sounds natural for me.
09:00:16 <h_asahina> I just want to tell 2 is not needed if I correctly understood two options that ueha-san mentioned
09:01:07 <yasufum> takahashi-tsc: what do you think? we don't have so much time left today...
09:01:13 <yasufum> for the discussion
09:01:52 <takahashi-tsc> Yes... I think reject 2. is OK. So if no other objection, I accept 1.
09:05:52 <yasufum> I'm still not sure who should be the responsibility if we accept 2.
09:07:34 <yasufum> I think we need to update the spec from your team including assignee.
09:08:07 <yasufum> Anyway, please continue to discussion on gerrit for.
09:08:09 <yasufum> Thanks
09:08:35 <yasufum> Go to the next topic
09:08:51 <yasufum> esto-aln: are you ready?
09:09:03 <esto-aln> yes
09:09:31 <esto-aln> I'd like to explain here
09:09:56 <esto-aln> Regarding Robot Patch, basically, it is completed.. however, there are 14 Failed tests.
09:10:10 <esto-aln> Currently, these tests are marked as skip using decorator.
09:10:53 <esto-aln> 12 Failed tests are related to ETSI API tests and 2 Failed Tests are tacker issue which was already a reported bug..
09:11:12 <esto-aln> So, we would like to consult on how to proceed...
09:11:21 <esto-aln> in the etherpad, we indicated 2 proposals.
09:12:06 <esto-aln> We would like to know from everyone which proposal would be best...
09:12:57 <yasufum> ok, thnaks
09:13:58 <yasufum> I understand there several reason for skipping tests.
09:14:26 <yasufum> And I think ueha must has a comment for the topic.
09:14:32 <yasufum> ueha: what do yo think?
09:14:43 <yasufum> Is there any suggestion?
09:15:56 <ueha> umm.. The plugtest was performed by another colleague, so I need to check it.
09:18:35 <yasufum> esto-aln: Is it OK to continue this topic next week because it might take some time
09:18:42 <ueha> If we accept proposal#2, does it mean that there is a test which automatically becomes pass when there is a modification of API Test on the ETSI side?
09:18:48 <esto-aln> okay, I understand..
09:19:07 <esto-aln> <ueha> yes, it will pass..
09:19:44 <ueha> If so, in my opinion 2 would be good.
09:19:58 <esto-aln> I think so, too..
09:20:31 <ueha> If we accept proposal#1, we need to see when the ETSI API tests are fixed...
09:20:41 <ueha> see -> watch
09:20:55 <esto-aln> yes, we need to monitor their fixes..
09:21:41 <yasufum> ueha: Yes, I've been concerning the same for 2, and I think it should be aoivded.
09:23:10 <yasufum> testing with non-voting is no mean for tests :)
09:23:54 <ueha> Yes, so I think 2 is good for now.
09:24:15 <esto-aln> I see.. thank you for your inputs.
09:24:25 <yasufum> Is there any comment, or can we close this meeting?
09:25:28 <yasufum> good
09:26:23 <yasufum> Thanks for joining and take care for your healt.
09:26:25 <yasufum> Bye!
09:26:33 <takahashi-tsc> thanks, bye
09:26:35 <ueha> thanks, bye.
09:26:36 <masaki-ueno> bye
09:26:40 <esto-aln> Thank you, Bye!
09:26:42 <manpreetk> Bye.
09:26:55 <yasufum> #endmeeting