Tuesday, 2022-02-22

yasufumHi tacker team08:00
*** h_asahin1 is now known as h_asahina08:01
yasufum#startmeeting tacker08:02
opendevmeetMeeting started Tue Feb 22 08:02:30 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
yasufum#link https://etherpad.opendev.org/p/tacker-meeting08:03
yasufumWe have four items today, but it might not be able to finish all...08:05
yasufumIs it OK start from first one? or is there any urgent item?08:06
manpreetkMy topics are for Yoga release so could i go first??08:07
poojaI am OK.08:07
manpreetkyasufum: My topics are for Yoga release so could i go first? Please suggest.08:08
yasufumOK,please go ahead.08:08
manpreetkThanks 08:08
manpreetkMy first topic https://etherpad.opendev.org/p/tacker-meeting#L17 is a follow-up discussion. As per last week discussion, VIM config files are loaded in tacker functional test cases. The investigation was conducted with respect to FT.08:09
manpreetkThe existing tacker functional test cases use OpenStack users and projects defined in the "Default" domain. 08:09
manpreetkIMO, the "domain-name" value in the VIM config file could be kept same as the project domain value.08:09
manpreetkWith respect to the above conclusion, changes were done in gen_config file. Please refer to gen_config file changes done in FT patch for multi tenant policy [1]. 08:11
manpreetk [1] https://review.opendev.org/c/openstack/tacker/+/823965/24/tools/gen_vim_config.sh#9108:11
manpreetkWould like to seek community opinion. Thanks 08:12
yasufumI agree to add  the attribute if it's required.08:15
manpreetkYes in as per current FT design 'domin-name' field is required in VIM conf file. 08:16
yasufumIs there any other opinion?08:19
uehaAfter all, is it a parameter that is necessary only for FT?08:20
uehaAnyway, I understand that it is necessary to pass FT normally. I agree too.08:23
manpreetkueha: Thanks for opinion. 08:23
yasufumueha: we can refactor to remove useless variables :)08:24
uehaIt is not necessary suddenly, so I hope we can organize it somewhere! thanks.08:25
yasufummanpreetk: I'd like to review your patch again, thanks.08:27
yasufumSo, can we go to the next topic?08:27
manpreetkSure thanks!! 08:27
yasufumWho should be the next?08:28
ma-ooyamaMy topic is not urgent. if there are some urgent topic, I'll share my topic after that.08:29
yasufumma-ooyama: thanks08:30
yasufummanpreetk: can you go to your second item?08:30
manpreetkIn multi-tenant environment,  FT for VNF instantiation is failing when executed from member role user.08:30
manpreetkRoot cause: VNF stack creation failure due to lack of authentication for member role user.  08:30
manpreetkTherefore it looks like in order to test VNF Instantiation operation in a multi-tenant environment, we might require two admin role users.08:30
manpreetkNote:  In current tacker functional testing design, we have one admin role user (nfv-user) and two member role user(test-user-1 and test-user-2).08:30
manpreetkWould like to hear community opinion.08:30
manpreetkThat's all from my side. Thanks08:32
h_asahinaI'd like to confirm that is testing with two admin users meaningful in terms of multi-tenant?08:37
manpreetkh_asahina: Yes even I have same question, would like to know whether such scenario is appropriate.08:38
manpreetkMoreover use case point of view.08:39
yasufumIMO, having two admins is not an usual usecase...08:40
uehaIn general, in the case of member role, is it impossible to create stacks?08:40
uehaIs it possible to grant additional permissions to member role..? (for example, so that stack can be created)08:40
manpreetkueha: As per investigation, heat policies need to be modified to allow member role users to create stack.08:41
yasufumI also wonder it's doable.08:41
manpreetkThe policy for resource types in heat is by default admin project, refer to https://opendev.org/openstack/heat/src/branch/master/heat/policies/resource_types.py#L2708:41
uehaDo you mean there is a way to change from the default Admin?08:43
manpreetkueha: For heat poilcy modification I dont know. 08:44
h_asahinaueha: FYI. When I did instantiation with user-role in my local environment, it worked.08:44
uehah_asahina: user-role you said is same as member-role?08:47
manpreetkh_asahina: If possible could you please share your patch, will help me to understand better.08:47
manpreetkAs in local and Zuul environment I am facing VNF creation issue for member role user.08:48
h_asahinamanpreetk: I just applied this patch https://review.opendev.org/c/openstack/tacker/+/799022 and do LCM with a non-admin user.08:50
yasufumDid you add a new user, or use existing one?08:50
h_asahinaI added a new user08:51
yasufumcan you share how you cretead the user?08:52
h_asahinaJust a moment please, I'm looking for the log to confirm what was the exact role...08:52
yasufummanpreetk: I'd like to know why you think admin priviledge is required for the task.08:55
yasufumFrom the log, it just tells the user is not authorized for creating the resource.08:55
manpreetkyasufum: Probably heat resources types policy is failing for VNF stack creation for member role, so solution could be admin role user.08:56
manpreetkBut I wonder whether customer uses a non admin role user to instantiate VNF?08:57
manpreetkAs the heat policy are old enough in OpenStack.08:58
yasufumThat is my concern08:59
yasufumand more, I think the result of testing by h_asahina is the usual behavior.09:01
h_asahinaSorry, I didn't find logs for member creation, but basically I followed this https://docs.openstack.org/keystone/latest/admin/cli-manage-projects-users-and-roles.html#assign-a-role and use member role defined by default.09:01
h_asahina /didn't/could't/g09:02
h_asahinaI agree with the yasufum:'s opinion as I didn't change the heat policy at that moment.09:03
manpreetkyasufum: I understand your concern, but VNF instantiation is failing for member role users in multi tenant functional test cases in Zuul.09:05
yasufummanpreetk: We might need to check how the non-admin user is created and auth given before.09:05
manpreetkI have explicitly assigned member role to newly created users in multi tenant FT framework.09:07
uehaI found heat's install guide: https://docs.openstack.org/heat/latest/install/install-ubuntu.html09:08
uehaand `role add` command seems to be executed: openstack role add --domain heat --user-domain heat --user heat_domain_admin admin09:09
uehaThere was also a domain that name is heat in my local environment.09:10
uehaCan we add the domain (=role?) of heat additionally?09:12
uehato newly created user?09:12
manpreetkueha: Thanks for sharing, this need to be check openstack user creation CLI, whether we could provide multiple domains. I dont know about this much.09:13
h_asahinamaybe it's not necessary anymore, but I found shellscript to create multitenant.09:17
h_asahinaopenstack project create tenant_a09:17
h_asahinaopenstack user create --project tenant_a --password asdfasdf tenant_a_admin09:17
h_asahinaopenstack user create --project tenant_a --password asdfasdf tenant_a_user09:17
h_asahinaopenstack role add --project tenant_a --user tenant_a_admin admin09:17
h_asahinaopenstack role add --project tenant_a --user tenant_a_user member09:17
h_asahinaI think I did the same things for another tenant_b.09:19
yasufumh_asahina: thanks09:22
yasufummanpreetk: can you try once more for non-admin user with appropriate role?09:23
manpreetkyasufum: Could you please elaborate what do you mean by appropriate role.09:24
yasufumheat as discussed above09:25
manpreetkOk thanks for confirmation09:25
yasufumit's over the end of the time actually, but can we go to the third topic?09:26
manpreetkI fear, this might impact participation of this feature in Feature freeze which is 24th Feb.09:26
yasufumIt's OK because you've already uploaded the candidate patch.09:27
manpreetkyasufum: Thanks, ok would see what all I can do and share result. Thanks for discussion everyone.09:28
h_asahinaSorry. but I'd like to confirm that is it possible to meet a deadline for Yoga release?09:29
h_asahinaWe're developing another multitenat FT depending on this patch, so...09:31
yasufummanpreetk: do you have any idea although it depends on a result of futher testing...09:34
manpreetkyasufum: Yes this investigation might take time and probably could we merge this patch without VNF instantiation and meanwhile I will continue working upon the solution.09:35
manpreetkPlease share your thought.09:35
yasufumI have no idea actually, but we can help you by trying to fix the issue09:37
yasufumby testing simiilar patches in parallel09:38
h_asahinaThe basic stracture of each test case won't be changed, right? as the problem is just Heat.09:38
h_asahinaI understand the invenstigation takes time.09:39
manpreetkh_asahina: Ideally basic test structure should not change, but still without investigation its hard to confirm.09:39
h_asahinaOk, I got it. thanks.09:40
yasufumanyway, please test and upate the patch as soon as possible.09:41
yasufumcan we go to the next item?09:43
yasufumalthough it looks just a sharing09:43
poojaI can go next if that's Ok.09:44
yasufumpooja: Can I confirm your discussoin point today?09:47
poojaThe topic is explained at https://etherpad.opendev.org/p/tacker-meeting #40. We have done analysis for bug https://bugs.launchpad.net/tacker/+bug/1906779 and found out that multiple vdus can not be scaled at once for same aspect id in current tacker implementation. We need to give different aspect id for scaling different vdus as per existing design.  As per SOL documentation different vdus should get scaled for same 09:47
poojaaspect id.09:47
poojaSo we think that https://bugs.launchpad.net/tacker/+bug/1906779 is not a bug. It will be a new feature which will need discussions to reach appropriate solution.09:50
poojaWould like to hear community opinion.09:50
yasufumYour suggestion is it should be done "at once", right?09:51
poojaSorry I did not understand "at once" meaning. 09:53
yasufumI've just reviewed your patch and comment from ueha, and understood it's the point.09:54
yasufumI've just noticed in your suttestion "But as per SOL001(*1)  It should be possible to scale multiple vdus at once for same aspect id."09:55
yasufumueha: do you have any comment?09:56
uehaI agree with `It will be a new feature which will need discussions to reach appropriate solution.` 09:58
uehabut The current implementation cannot scale "at once" and should be considered and changed at the openstack/kubernetes VIM respectively.09:59
uehaFurthermore, the V1 and V2 APIs are separate implementations, so I think there is a lot to consider..10:00
uehaAnd I don't know if there is a demand to scale multiple VDUs at once. we can run the scale command separately by defining aspectId per VDU.10:02
poojaWe can add this feature in next release10:04
poojaSince this will be a new feature , we can develop this in next release. Please let us know if this understanding is correct.  10:06
yasufumI'm not opposed your suggestion, but thinking about priority among developing features will be proposed the next release.10:08
yasufumI agree to your suggestion basically.10:09
yasufumBut I'm not still sure how it's important.10:10
poojathanks 10:10
takahashi-tscyasufum: so anyway, what we should do next is to propose for development of multiple VDU scale at once at PTG.10:11
yasufumAnyway, I'd appreciate if you propose a spec in the next vPTG.10:11
yasufumtakahashi-tsc: yes10:11
takahashi-tscOK, thanks.10:11
yasufumI'd like to know how many the change is more exactly.10:12
yasufumif possible10:12
yasufumSorry for taking so long time today.10:13
yasufumWe should close this meeting if someone has no more comment.10:14
ma-ooyamaSure. Let me share my topic next meeting if there's time. 10:14
yasufumma-ooyama: sorry for today...10:14
yasufumThank you for joining, bye!10:15
uehathanks, bye!10:15
manpreetkThanks and bye.10:15
poojabye 10:15
opendevmeetMeeting ended Tue Feb 22 10:15:41 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)10:15
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-22-08.02.html10:15
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-22-08.02.txt10:15
opendevmeetLog:            https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-22-08.02.log.html10:15

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