Tuesday, 2022-01-11

*** hemna9 is now known as hemna07:38
yasufumhi tacker team08:00
yasufum#startmeeting tacker08:02
opendevmeetMeeting started Tue Jan 11 08:02:13 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:02
opendevmeetThe meeting name has been set to 'tacker'08:02
yasufumThis is the 1st meeting this year :)08:03
yasufumWe have three topics on the etherpad.08:04
yasufum#link https://etherpad.opendev.org/p/tacker-meeting08:04
yasufumBut second one from esto-aln looks no updates from the latest meeting.08:05
esto-alnsorry, the following topic: About Sample Ansible Driver  (esto-aln)08:05
yasufumSo, it seems two topics for today collectly.08:05
esto-alnplease ignore08:05
yasufumesto-aln: got it08:05
yasufumh_asahina: can you start from your topic?08:06
h_asahinaAs I wrote on the etherpad, I'd like to confirm a schedule of the multi-tenant FT patch: https://review.opendev.org/c/openstack/tacker/+/82396508:07
h_asahinaIn addition, I'd like to ask you that is it possible to separate the setup phase of FT in this patch as a different patch.08:08
h_asahinaI'd appreciate if you could tell the answer for the above questions.08:09
takahshi-tscAs I reply, I'll concerned that the spec is not merged yet. Basically, remained topic seems almost minor point, but 1 topic seems to need discussion.08:11
takahshi-tsci.e. admin's role. 08:11
yasufumI already gave +2 because no one has had any objection for the point actually.08:12
takahshi-tscBut... today's second topic form ma-ooyama is similar as my point. So we sholud discuss it.08:13
h_asahinaI see, so you couldn't say when the patch can be merged util that point isn't clear?08:14
h_asahinauntil -> unless, sorry08:15
yasufumI think it should be discussed as how we think a operational policy.08:17
yasufumand ma-ooyama pointed out the same point from the stand point of operator.08:18
takahshi-tscShould we discuss it first? Maybe today's topics are "admin policy" and "schedule of the multi-tenant FT". Should we discuss them in this order?08:19
yasufumIt depends on how the FT is implemented will be implemented.08:21
h_asahinaI think, at least, the setup phase of FT is not strongly related to such operation policy. Am I right?08:22
h_asahinaAssuming the spec is merged within this week, could you see when you can finish implementing the setup phase of FT.08:23
takahshi-tscOK... manpreet, I think you are proceeding with development FT. What do you think about h_asahina's opinion.08:23
manpreetkYes we can separate setup phase of FT and development of FT would be completed by 31st Jan 2022 or latest by first week of Feb. 08:24
h_asahinaalright. thanks. How about entier FT? if we can start this work from today.08:25
h_asahinaIf it's really impossible to estimate it without discussing the above mentioned operation policy, it's fine.08:27
yasufumany answer?08:31
manpreetkh_asahina: Could you please confirm what are you referring as "entire FT",  are you asking about operational policy changes as well. 08:32
h_asahinaI'd like to hear schedules for both cases: (i) the operational policy is chagned and corresponding FT is created according to the spec; (ii) the operational policy is NOT changed and FT is created08:34
h_asahinaI mean the FT described in the current spec08:35
manpreetkFor (ii) the shared dates are 31st Jan or 1st week of Feb. But for (i) it depends on discussion and would share it later.08:38
manpreetk*would share dates08:38
h_asahinaas well as the patch for the setup phase?08:39
manpreetkYes 08:39
h_asahinaI got it. thank you so much, I'd appreciate it.08:40
manpreetkYour welcome.08:40
uehaExcuse me for interrupting. Does the FT from the viewpoint of multi-tenancy mainly consist of confirmation without Admin role? User A an User B don't have Admin role, right?08:41
h_asahinaIn my understanding, from the spec, what ueha-san's saying is correct.08:45
uehaThank you, asahina-san. In that case, the FT for admin-role is related, but it seems to be a different story from the FT for multi-tenant.. umm..08:48
takahshi-tscI think 1 option is using admin and non-admin user as UserA and UserB. We can use admin user for operational policy.08:50
takahshi-tscBut I'm ntot sure it is the best...08:50
yasufumI wounder the same as takahashi-tsc for the FT plan.08:50
uehaThe current FT uses "nfv_user", but I expected to create new projectA/B and userA/B in the setup phase.08:54
yasufumalthough the names of users and projects should be more appropriate for the purpose.08:56
yasufumIs there any other point should be cleared here?09:00
h_asahinaI feel FTs using two non-admin users are also needed separately from the FT with an admin-user for operational policy. Is it dfficult to make them as different FTs?09:03
h_asahinaor different test cases09:03
manpreetkIn the FT for Multi tenant we could have User A and USer B (admin, non admin) or (non admin, non admin) would try to implement the test setup for both cases , will try to complete within shared schedule.09:03
h_asahinaIf the FT confirms that non-admin user cannot access the resources created by an admin user, how can we distinguish the reason behind that is because the user is not admin or because the user belongs to the different tenant.09:06
h_asahinaIf you all think it doesn't matter, please ignore it.09:08
takahshi-tscIs manpreet's reply not enough? In my opinion, she try to support both (admin and non-admin case and two non-admin case).09:10
h_asahinaAh...Sorry I misread it. please forget my comment.09:11
takahshi-tscSure, thanks.09:11
yasufumWe can discuss on #tacker channel or code review on the spec if you have any other comment.09:13
yasufumGo to the next topic :)09:13
yasufumma-ooyama: can you share your points although some of them have already discussed?09:15
ma-ooyamaSure. My topic seems similar to h-asahina's second topic.09:16
ma-ooyamaAs you can see on the etherpad, our opinion about multi-tenancy is like this:09:17
ma-ooyama1)It is not a problem that users who have admin role can operates a VNF that belongs to different tenant.09:17
ma-ooyama2)It is a problem that users who have admin role can instantiate a VNF to a VIM that belongs to a tenant different from the VNF's tenant,  because  VNF's tenant is determined by users who creates the VNF.09:17
ma-ooyama3)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.09:17
ma-ooyamaIf the tenant of VNF depends on the tenant of the user who create the VNF like current implementation, the VNF should never be instantiated on the VIM in another tenant even though an admin user operates the VNF.09:19
ma-ooyamaThis is just a opinion from the point of view of an oparator. How do you think about this? 09:20
yasufumI agree with you basically for the first item as commented before.09:22
yasufumDo you have any other comment? everyone?09:23
takahshi-tscma-ooyama's opinion seems same as mine. 09:25
uehame too. Do users with admin-role often do like that in real operation?09:26
uehaJust question, I'm sorry that I don't know much about the actual operation.. Is the basic operation of the VNF performed by users without admin-role?09:29
ma-ooyamaIt never happend actually, but we think it should be restricted that admin user can instantiate VNF to the VIM in another tenant.09:30
uehaThank you. if it depends on the use case and it can be happened, so we should correct it.09:32
ma-ooyamaI think basic operation is normally perfomed by non-admin users in actual environment.09:32
yasufumFor the second topic, I'd like to clear the terms.09:34
yasufumma-ooyama: Do you mean "tenant" is the same as "project"?09:35
ma-ooyamaThe project of the user who get token.09:36
yasufumSo, you think only "instantiate" should be restricted among different users, even if admin, correct?09:38
ma-ooyamaI think the difference between the VNF's tenant and the VIM's tenant  is problem, so I only refered to "instantiation" only.09:42
yasufumI understand, thanks09:44
yasufumw-juso: do you have any comment?09:45
w-jusothank you for discussion. I agree with the result.09:46
uehaSorry for interruption, isn't it the same for the VNF package's tenant and VNF's tenant that create using it?09:47
ma-ooyamaSorry, I couldn't have thought about that case, but I suppose so.09:49
ma-ooyamabut sorry I have no answer right now.09:50
yasufumI think there will be required to something update the spec from w-juso, so please continue to discuss on the review.09:51
uehaThank you, I got it. You mean we have to check how it is implemented like other.09:52
yasufumThe third item seems not so critical for me if my understanding is correct.09:53
yasufumYou've mentioned that VIM should be choosed appropriately for each test cases, right?09:55
yasufumOr do you mean there is any other problem for choosing VIM?09:57
w-jusoI think so09:57
w-jusothere is no other problems.09:58
ma-ooyamaI mean the default VIM should be choosed from the same tenant as the VNF's tenant. 09:59
yasufumI'd appreciate if you share the actual usecase, such as a command log or so, for the problem.10:05
yasufumIt's over an hour for the end of the time, so close this meeting.10:06
ma-ooyamaSorry, sure.10:07
yasufumYou can share your log on the etherpad or launchpad.10:07
yasufumma-ooyama: no problem, thanks for your valuable feedback!10:08
yasufumThanks for joining, and your contributions!10:09
takahshi-tscthanks, bye10:09
uehathanks, bye.10:09
manpreetkThanks , bye.10:09
w-jusothanks, bye10:09
ma-ooyamaThanks, bye.10:09
esto-alnthanks, bye.10:09
opendevmeetMeeting ended Tue Jan 11 10:09:54 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)10:09
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-01-11-08.02.html10:09
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-01-11-08.02.txt10:09
opendevmeetLog:            https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-01-11-08.02.log.html10:09
*** hemna1 is now known as hemna12:30
*** dasm is now known as dasm|off22:52

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