08:02:13 <yasufum> #startmeeting tacker
08:02:13 <opendevmeet> Meeting 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:13 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:13 <opendevmeet> The meeting name has been set to 'tacker'
08:03:41 <yasufum> This is the 1st meeting this year :)
08:04:04 <yasufum> We have three topics on the etherpad.
08:04:06 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:05:04 <yasufum> But second one from esto-aln looks no updates from the latest meeting.
08:05:13 <esto-aln> Hello
08:05:21 <esto-aln> sorry, the following topic: About Sample Ansible Driver  (esto-aln)
08:05:24 <yasufum> So, it seems two topics for today collectly.
08:05:27 <esto-aln> please ignore
08:05:42 <yasufum> s/collectly/correctly/
08:05:54 <yasufum> esto-aln: got it
08:06:41 <yasufum> h_asahina: can you start from your topic?
08:06:48 <h_asahina> ok
08:07:33 <h_asahina> As 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/+/823965
08:08:32 <h_asahina> In 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:09:57 <h_asahina> I'd appreciate if you could tell the answer for the above questions.
08:11:32 <takahshi-tsc> As 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:53 <takahshi-tsc> i.e. admin's role.
08:12:47 <yasufum> I already gave +2 because no one has had any objection for the point actually.
08:13:05 <takahshi-tsc> But... today's second topic form ma-ooyama is similar as my point. So we sholud discuss it.
08:13:14 <yasufum> yes
08:14:22 <h_asahina> I see, so you couldn't say when the patch can be merged util that point isn't clear?
08:15:16 <h_asahina> until -> unless, sorry
08:17:34 <yasufum> I think it should be discussed as how we think a operational policy.
08:18:12 <yasufum> and ma-ooyama pointed out the same point from the stand point of operator.
08:19:38 <takahshi-tsc> Should 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:21:18 <yasufum> It depends on how the FT is implemented will be implemented.
08:22:14 <h_asahina> I think, at least, the setup phase of FT is not strongly related to such operation policy. Am I right?
08:23:05 <h_asahina> Assuming the spec is merged within this week, could you see when you can finish implementing the setup phase of FT.
08:23:47 <takahshi-tsc> OK... manpreet, I think you are proceeding with development FT. What do you think about h_asahina's opinion.
08:24:50 <manpreetk> Yes 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:25:49 <h_asahina> alright. thanks. How about entier FT? if we can start this work from today.
08:27:36 <h_asahina> If it's really impossible to estimate it without discussing the above mentioned operation policy, it's fine.
08:31:49 <yasufum> any answer?
08:32:27 <manpreetk> h_asahina: Could you please confirm what are you referring as "entire FT",  are you asking about operational policy changes as well.
08:34:50 <h_asahina> I'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 created
08:35:27 <h_asahina> I mean the FT described in the current spec
08:38:35 <manpreetk> For (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:53 <manpreetk> *would share dates
08:39:33 <h_asahina> as well as the patch for the setup phase?
08:39:51 <manpreetk> Yes
08:40:17 <h_asahina> I got it. thank you so much, I'd appreciate it.
08:40:28 <manpreetk> Your welcome.
08:40:48 <yasufum> thanks
08:41:07 <ueha> Excuse 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:45:10 <h_asahina> In my understanding, from the spec, what ueha-san's saying is correct.
08:48:20 <ueha> Thank 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:50:00 <takahshi-tsc> I think 1 option is using admin and non-admin user as UserA and UserB. We can use admin user for operational policy.
08:50:09 <takahshi-tsc> But I'm ntot sure it is the best...
08:50:32 <yasufum> I wounder the same as takahashi-tsc for the FT plan.
08:54:11 <ueha> The current FT uses "nfv_user", but I expected to create new projectA/B and userA/B in the setup phase.
08:54:50 <yasufum> sure
08:56:04 <yasufum> although the names of users and projects should be more appropriate for the purpose.
09:00:52 <yasufum> Is there any other point should be cleared here?
09:03:36 <h_asahina> I 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:54 <h_asahina> or different test cases
09:03:55 <manpreetk> In 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:06:54 <h_asahina> If 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:08:20 <h_asahina> If you all think it doesn't matter, please ignore it.
09:10:42 <takahshi-tsc> Is manpreet's reply not enough? In my opinion, she try to support both (admin and non-admin case and two non-admin case).
09:11:41 <h_asahina> Ah...Sorry I misread it. please forget my comment.
09:11:53 <takahshi-tsc> Sure, thanks.
09:12:26 <yasufum> thanks
09:13:11 <yasufum> We can discuss on #tacker channel or code review on the spec if you have any other comment.
09:13:28 <yasufum> Go to the next topic :)
09:15:19 <yasufum> ma-ooyama: can you share your points although some of them have already discussed?
09:16:22 <ma-ooyama> Sure. My topic seems similar to h-asahina's second topic.
09:17:11 <ma-ooyama> As you can see on the etherpad, our opinion about multi-tenancy is like this:
09:17:46 <ma-ooyama> 1)It is not a problem that users who have admin role can operates a VNF that belongs to different tenant.
09:17:53 <ma-ooyama> 2)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:58 <ma-ooyama> 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.
09:19:26 <ma-ooyama> If 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:20:56 <ma-ooyama> This is just a opinion from the point of view of an oparator. How do you think about this?
09:22:05 <yasufum> thanks
09:22:46 <yasufum> I agree with you basically for the first item as commented before.
09:23:50 <yasufum> Do you have any other comment? everyone?
09:25:14 <takahshi-tsc> ma-ooyama's opinion seems same as mine.
09:26:19 <ueha> me too. Do users with admin-role often do like that in real operation?
09:29:16 <ueha> Just 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:30:16 <ma-ooyama> It never happend actually, but we think it should be restricted that admin user can instantiate VNF to the VIM in another tenant.
09:32:05 <ueha> Thank you. if it depends on the use case and it can be happened, so we should correct it.
09:32:14 <ma-ooyama> I think basic operation is normally perfomed by non-admin users in actual environment.
09:32:45 <yasufum> OK
09:34:55 <yasufum> For the second topic, I'd like to clear the terms.
09:35:23 <yasufum> ma-ooyama: Do you mean "tenant" is the same as "project"?
09:35:44 <ma-ooyama> yes
09:36:18 <ma-ooyama> The project of the user who get token.
09:38:06 <yasufum> So, you think only "instantiate" should be restricted among different users, even if admin, correct?
09:42:16 <ma-ooyama> I think the difference between the VNF's tenant and the VIM's tenant  is problem, so I only refered to "instantiation" only.
09:44:13 <yasufum> I understand, thanks
09:45:16 <yasufum> w-juso: do you have any comment?
09:46:46 <w-juso> thank you for discussion. I agree with the result.
09:47:00 <ueha> Sorry for interruption, isn't it the same for the VNF package's tenant and VNF's tenant that create using it?
09:49:38 <ma-ooyama> Sorry, I couldn't have thought about that case, but I suppose so.
09:50:17 <ma-ooyama> but sorry I have no answer right now.
09:51:51 <yasufum> I think there will be required to something update the spec from w-juso, so please continue to discuss on the review.
09:52:51 <ueha> Thank you, I got it. You mean we have to check how it is implemented like other.
09:53:16 <yasufum> The third item seems not so critical for me if my understanding is correct.
09:55:13 <yasufum> You've mentioned that VIM should be choosed appropriately for each test cases, right?
09:57:01 <yasufum> Or do you mean there is any other problem for choosing VIM?
09:57:03 <w-juso> I think so
09:58:59 <w-juso> there is no other problems.
09:59:42 <ma-ooyama> I mean the default VIM should be choosed from the same tenant as the VNF's tenant.
10:04:28 <yasufum> OK
10:05:54 <yasufum> I'd appreciate if you share the actual usecase, such as a command log or so, for the problem.
10:06:53 <yasufum> It's over an hour for the end of the time, so close this meeting.
10:07:32 <ma-ooyama> Sorry, sure.
10:07:34 <yasufum> You can share your log on the etherpad or launchpad.
10:08:08 <ma-ooyama> OK
10:08:17 <yasufum> ma-ooyama: no problem, thanks for your valuable feedback!
10:09:12 <yasufum> Thanks for joining, and your contributions!
10:09:18 <yasufum> bye
10:09:25 <takahshi-tsc> thanks, bye
10:09:27 <h_asahina> bye
10:09:27 <ueha> thanks, bye.
10:09:28 <manpreetk> Thanks , bye.
10:09:31 <w-juso> thanks, bye
10:09:37 <ma-ooyama> Thanks, bye.
10:09:41 <esto-aln> thanks, bye.
10:09:54 <yasufum> #endmeeting