Tuesday, 2022-01-18

yasufumhi tacker team08:02
yasufum#startmeeting tacker08:04
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:04
opendevmeetThe meeting name has been set to 'tacker'08:04
yasufumWe have three topics on the etherpad today.08:06
yasufum#link https://etherpad.opendev.org/p/tacker-meeting08:06
yasufumWithout the item from esto-aln, it's the same topic, multi-tenant spec, right?08:08
yasufumI agree to the proposal from w-juso.08:09
w-jusothank you for check. I'll fix it.08:10
yasufumIf anyone has a objection for the proposal, I'd like to start from ma-ooyama.08:10
uehaI agree too. Originally, asahina-san commented on the spec.08:11
w-jusoyes, thank you asahina-san, ueha-san.08:13
h_asahinayour welcome :)08:14
ueha:)   yasufum: seems no objection, go ahead.08:16
yasufumma-ooyama: are you here?08:16
ma-ooyamaYes, I'll share my topic.08:17
ma-ooyamaI wrote details about the third opinion I explained last week in this launchpad. (https://bugs.launchpad.net/tacker/+bug/1958197)08:17
ma-ooyamaThe 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:18
ma-ooyamaThe 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:19
ma-ooyamaI would like to confirm whether our understanding in this lanunchpad is right.08:20
takahashi-tsc1 confirmation, your expected result is test_vnf is instantiated with test_vim_1, right?  not instantiation is failed.08:28
ma-ooyamaI have no answer which is better, but at least test_vim_2 shouldn't be selected.08:30
uehaI think there are two ways:08:32
ueha1. compare the default VIM's tenant with the VNF's tenant and give an error if they are not the same tenant.08:32
ueha2. if instantiate by admin-role user, Tacker uses default VIM of VNF's tenant08:32
takahashi-tscYes, and at least, w-juso and manpreetk's work include 1,08:33
takahashi-tscI 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:36
uehaI feel subtle to use VIM different tenants about "2" (test_user_1 uses VIM of test_tenant_2 is strange).08:38
uehaI think "1" is better.08:39
yasufumI think 2 is not so strange for me as a default behavior, but not sure it should be...08:39
h_asahinaJust to confirm, if rejecting 2, admin users can only instantiate VIM in admin project, right?08:40
takahashi-tscIn 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:42
h_asahinaThat sounds natural. I mean the instantiation will be success only if VNF's tenant and VIM's tenat are same.08:44
h_asahinaI thought accepting 2 will break this rule. Am I wrong?08:44
yasufummay be so08:47
takahashi-tscI 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
takahashi-tscCurrent behavior is, admin execute instantiation with admin's VIM, and instantiation is success. This is wrong behavior.08:48
takahashi-tscs/instantiateion/instantiation of non-admin's VNF/08:49
takahashi-tscueha's option  1. is, tacker is reject this instantiation.08:49
takahashi-tscueh's option 2. is admin use non-admin's VIM and instantiation is success. I think 2. has no problem.08:50
takahashi-tscBut my question is, 2. is needed or not.08:50
takahashi-tscueha: Is my understanding correct?08:50
yasufumI'm wondering we don't need to define default vim if we introduce such a rule...08:50
h_asahinaI 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
uehathakahashi-tsc: correct.08:51
h_asahinaI thought admin users can instantiate VNF with VIM in different tenant (non-admin users).08:54
h_asahinaIf we agreed with 1, rejecting 2 sounds natural for me. 08:55
h_asahinaI just want to tell 2 is not needed if I correctly understood two options that ueha-san mentioned09:00
yasufumtakahashi-tsc: what do you think? we don't have so much time left today...09:01
yasufumfor the discussion09:01
takahashi-tscYes... I think reject 2. is OK. So if no other objection, I accept 1.09:01
yasufumI'm still not sure who should be the responsibility if we accept 2.09:05
yasufumI think we need to update the spec from your team including assignee.09:07
yasufumAnyway, please continue to discussion on gerrit for.09:08
yasufumGo to the next topic09:08
yasufumesto-aln: are you ready?09:08
esto-alnI'd like to explain here09:09
esto-alnRegarding Robot Patch, basically, it is completed.. however, there are 14 Failed tests.09:09
esto-alnCurrently, these tests are marked as skip using decorator.09:10
esto-aln12 Failed tests are related to ETSI API tests and 2 Failed Tests are tacker issue which was already a reported bug..09:10
esto-alnSo, we would like to consult on how to proceed...09:11
esto-alnin the etherpad, we indicated 2 proposals.09:11
esto-alnWe would like to know from everyone which proposal would be best...09:12
yasufumok, thnaks09:12
yasufumI understand there several reason for skipping tests.09:13
yasufumAnd I think ueha must has a comment for the topic.09:14
yasufumueha: what do yo think?09:14
yasufumIs there any suggestion?09:14
uehaumm.. The plugtest was performed by another colleague, so I need to check it.09:15
yasufumesto-aln: Is it OK to continue this topic next week because it might take some time09:18
uehaIf 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
esto-alnokay, I understand..09:18
esto-aln<ueha> yes, it will pass..09:19
uehaIf so, in my opinion 2 would be good.09:19
esto-alnI think so, too..09:19
uehaIf we accept proposal#1, we need to see when the ETSI API tests are fixed...09:20
uehasee -> watch09:20
esto-alnyes, we need to monitor their fixes..09:20
yasufumueha: Yes, I've been concerning the same for 2, and I think it should be aoivded.09:21
yasufumtesting with non-voting is no mean for tests :)09:23
uehaYes, so I think 2 is good for now.09:23
esto-alnI see.. thank you for your inputs.09:24
yasufumIs there any comment, or can we close this meeting?09:24
yasufumThanks for joining and take care for your healt.09:26
takahashi-tscthanks, bye09:26
uehathanks, bye.09:26
esto-alnThank you, Bye!09:26
opendevmeetMeeting ended Tue Jan 18 09:26:55 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:26
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-01-18-08.04.html09:26
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-01-18-08.04.txt09:26
opendevmeetLog:            https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-01-18-08.04.log.html09:26
*** soniya29 is now known as soniya29|afk10:00
*** soniya29|afk is now known as soniya2912:27
*** dasm|off is now known as dasm13:31
martialhello team21:11
*** dasm is now known as dasm|23:02
*** dasm| is now known as dasm|off23:02

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!