| yasufum | Hi tacker team | 08:00 |
|---|---|---|
| manpreetk | hi | 08:00 |
| ueha | hi | 08:00 |
| masaki-ueno | hi | 08:00 |
| takahashi-tsc | hi | 08:00 |
| h_asahin1 | hi | 08:01 |
| pooja | hi | 08:01 |
| *** h_asahin1 is now known as h_asahina | 08:01 | |
| yasufum | #startmeeting tacker | 08:02 |
| opendevmeet | Meeting 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:02 |
| opendevmeet | The meeting name has been set to 'tacker' | 08:02 |
| yasufum | #link https://etherpad.opendev.org/p/tacker-meeting | 08:03 |
| yasufum | We have four items today, but it might not be able to finish all... | 08:05 |
| yasufum | Is it OK start from first one? or is there any urgent item? | 08:06 |
| manpreetk | My topics are for Yoga release so could i go first?? | 08:07 |
| pooja | I am OK. | 08:07 |
| manpreetk | yasufum: My topics are for Yoga release so could i go first? Please suggest. | 08:08 |
| yasufum | OK,please go ahead. | 08:08 |
| manpreetk | Thanks | 08:08 |
| manpreetk | My 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 |
| manpreetk | The existing tacker functional test cases use OpenStack users and projects defined in the "Default" domain. | 08:09 |
| manpreetk | IMO, the "domain-name" value in the VIM config file could be kept same as the project domain value. | 08:09 |
| manpreetk | With 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#91 | 08:11 |
| manpreetk | Would like to seek community opinion. Thanks | 08:12 |
| yasufum | thanks | 08:14 |
| yasufum | I agree to add the attribute if it's required. | 08:15 |
| manpreetk | Yes in as per current FT design 'domin-name' field is required in VIM conf file. | 08:16 |
| yasufum | Is there any other opinion? | 08:19 |
| ueha | After all, is it a parameter that is necessary only for FT? | 08:20 |
| ueha | Anyway, I understand that it is necessary to pass FT normally. I agree too. | 08:23 |
| manpreetk | ueha: Thanks for opinion. | 08:23 |
| yasufum | ueha: we can refactor to remove useless variables :) | 08:24 |
| ueha | It is not necessary suddenly, so I hope we can organize it somewhere! thanks. | 08:25 |
| yasufum | manpreetk: I'd like to review your patch again, thanks. | 08:27 |
| yasufum | So, can we go to the next topic? | 08:27 |
| manpreetk | Sure thanks!! | 08:27 |
| yasufum | Who should be the next? | 08:28 |
| ma-ooyama | My topic is not urgent. if there are some urgent topic, I'll share my topic after that. | 08:29 |
| yasufum | ma-ooyama: thanks | 08:30 |
| yasufum | manpreetk: can you go to your second item? | 08:30 |
| manpreetk | yes | 08:30 |
| manpreetk | In multi-tenant environment, FT for VNF instantiation is failing when executed from member role user. | 08:30 |
| manpreetk | Root cause: VNF stack creation failure due to lack of authentication for member role user. | 08:30 |
| manpreetk | Therefore it looks like in order to test VNF Instantiation operation in a multi-tenant environment, we might require two admin role users. | 08:30 |
| manpreetk | Note: 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 |
| manpreetk | Would like to hear community opinion. | 08:30 |
| manpreetk | That's all from my side. Thanks | 08:32 |
| yasufum | thanks | 08:36 |
| h_asahina | I'd like to confirm that is testing with two admin users meaningful in terms of multi-tenant? | 08:37 |
| manpreetk | h_asahina: Yes even I have same question, would like to know whether such scenario is appropriate. | 08:38 |
| manpreetk | Moreover use case point of view. | 08:39 |
| yasufum | IMO, having two admins is not an usual usecase... | 08:40 |
| ueha | In general, in the case of member role, is it impossible to create stacks? | 08:40 |
| ueha | Is it possible to grant additional permissions to member role..? (for example, so that stack can be created) | 08:40 |
| manpreetk | ueha: As per investigation, heat policies need to be modified to allow member role users to create stack. | 08:41 |
| yasufum | I also wonder it's doable. | 08:41 |
| manpreetk | The 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#L27 | 08:41 |
| ueha | Do you mean there is a way to change from the default Admin? | 08:43 |
| manpreetk | ueha: For heat poilcy modification I dont know. | 08:44 |
| h_asahina | ueha: FYI. When I did instantiation with user-role in my local environment, it worked. | 08:44 |
| ueha | h_asahina: user-role you said is same as member-role? | 08:47 |
| manpreetk | h_asahina: If possible could you please share your patch, will help me to understand better. | 08:47 |
| manpreetk | As in local and Zuul environment I am facing VNF creation issue for member role user. | 08:48 |
| h_asahina | manpreetk: I just applied this patch https://review.opendev.org/c/openstack/tacker/+/799022 and do LCM with a non-admin user. | 08:50 |
| yasufum | Did you add a new user, or use existing one? | 08:50 |
| h_asahina | I added a new user | 08:51 |
| yasufum | can you share how you cretead the user? | 08:52 |
| h_asahina | Just a moment please, I'm looking for the log to confirm what was the exact role... | 08:52 |
| yasufum | manpreetk: I'd like to know why you think admin priviledge is required for the task. | 08:55 |
| yasufum | From the log, it just tells the user is not authorized for creating the resource. | 08:55 |
| manpreetk | yasufum: Probably heat resources types policy is failing for VNF stack creation for member role, so solution could be admin role user. | 08:56 |
| manpreetk | But I wonder whether customer uses a non admin role user to instantiate VNF? | 08:57 |
| manpreetk | As the heat policy are old enough in OpenStack. | 08:58 |
| yasufum | That is my concern | 08:59 |
| yasufum | and more, I think the result of testing by h_asahina is the usual behavior. | 09:01 |
| h_asahina | Sorry, 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/g | 09:02 |
| h_asahina | I agree with the yasufum:'s opinion as I didn't change the heat policy at that moment. | 09:03 |
| manpreetk | yasufum: I understand your concern, but VNF instantiation is failing for member role users in multi tenant functional test cases in Zuul. | 09:05 |
| yasufum | manpreetk: We might need to check how the non-admin user is created and auth given before. | 09:05 |
| manpreetk | I have explicitly assigned member role to newly created users in multi tenant FT framework. | 09:07 |
| yasufum | umm.. | 09:07 |
| ueha | I found heat's install guide: https://docs.openstack.org/heat/latest/install/install-ubuntu.html | 09:08 |
| ueha | and `role add` command seems to be executed: openstack role add --domain heat --user-domain heat --user heat_domain_admin admin | 09:09 |
| ueha | There was also a domain that name is heat in my local environment. | 09:10 |
| ueha | Can we add the domain (=role?) of heat additionally? | 09:12 |
| ueha | to newly created user? | 09:12 |
| manpreetk | ueha: 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 |
| yasufum | OK | 09:15 |
| h_asahina | maybe it's not necessary anymore, but I found shellscript to create multitenant. | 09:17 |
| h_asahina | #!/bin/bash | 09:17 |
| h_asahina | openstack project create tenant_a | 09:17 |
| h_asahina | openstack user create --project tenant_a --password asdfasdf tenant_a_admin | 09:17 |
| h_asahina | openstack user create --project tenant_a --password asdfasdf tenant_a_user | 09:17 |
| h_asahina | openstack role add --project tenant_a --user tenant_a_admin admin | 09:17 |
| h_asahina | openstack role add --project tenant_a --user tenant_a_user member | 09:17 |
| h_asahina | Y | 09:17 |
| h_asahina | I think I did the same things for another tenant_b. | 09:19 |
| yasufum | h_asahina: thanks | 09:22 |
| yasufum | manpreetk: can you try once more for non-admin user with appropriate role? | 09:23 |
| manpreetk | yasufum: Could you please elaborate what do you mean by appropriate role. | 09:24 |
| yasufum | heat as discussed above | 09:25 |
| manpreetk | Ok thanks for confirmation | 09:25 |
| yasufum | it's over the end of the time actually, but can we go to the third topic? | 09:26 |
| manpreetk | I fear, this might impact participation of this feature in Feature freeze which is 24th Feb. | 09:26 |
| yasufum | It's OK because you've already uploaded the candidate patch. | 09:27 |
| manpreetk | yasufum: Thanks, ok would see what all I can do and share result. Thanks for discussion everyone. | 09:28 |
| yasufum | thanks! | 09:28 |
| h_asahina | Sorry. but I'd like to confirm that is it possible to meet a deadline for Yoga release? | 09:29 |
| h_asahina | We're developing another multitenat FT depending on this patch, so... | 09:31 |
| yasufum | manpreetk: do you have any idea although it depends on a result of futher testing... | 09:34 |
| yasufum | ? | 09:34 |
| manpreetk | yasufum: 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 |
| manpreetk | Please share your thought. | 09:35 |
| yasufum | I have no idea actually, but we can help you by trying to fix the issue | 09:37 |
| yasufum | by testing simiilar patches in parallel | 09:38 |
| h_asahina | The basic stracture of each test case won't be changed, right? as the problem is just Heat. | 09:38 |
| h_asahina | I understand the invenstigation takes time. | 09:39 |
| manpreetk | h_asahina: Ideally basic test structure should not change, but still without investigation its hard to confirm. | 09:39 |
| h_asahina | Ok, I got it. thanks. | 09:40 |
| yasufum | anyway, please test and upate the patch as soon as possible. | 09:41 |
| manpreetk | Sure,thanks | 09:42 |
| yasufum | thanks | 09:43 |
| yasufum | can we go to the next item? | 09:43 |
| yasufum | although it looks just a sharing | 09:43 |
| pooja | I can go next if that's Ok. | 09:44 |
| yasufum | yes | 09:44 |
| yasufum | pooja: Can I confirm your discussoin point today? | 09:47 |
| pooja | The 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 |
| pooja | aspect id. | 09:47 |
| pooja | So 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 |
| pooja | Would like to hear community opinion. | 09:50 |
| yasufum | Your suggestion is it should be done "at once", right? | 09:51 |
| pooja | Sorry I did not understand "at once" meaning. | 09:53 |
| yasufum | I've just reviewed your patch and comment from ueha, and understood it's the point. | 09:54 |
| yasufum | I'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 |
| yasufum | ueha: do you have any comment? | 09:56 |
| ueha | I agree with `It will be a new feature which will need discussions to reach appropriate solution.` | 09:58 |
| ueha | but The current implementation cannot scale "at once" and should be considered and changed at the openstack/kubernetes VIM respectively. | 09:59 |
| ueha | Furthermore, the V1 and V2 APIs are separate implementations, so I think there is a lot to consider.. | 10:00 |
| ueha | And 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 |
| yasufum | thanks | 10:03 |
| pooja | We can add this feature in next release | 10:04 |
| pooja | Since this will be a new feature , we can develop this in next release. Please let us know if this understanding is correct. | 10:06 |
| yasufum | I'm not opposed your suggestion, but thinking about priority among developing features will be proposed the next release. | 10:08 |
| yasufum | I agree to your suggestion basically. | 10:09 |
| yasufum | But I'm not still sure how it's important. | 10:10 |
| pooja | thanks | 10:10 |
| takahashi-tsc | yasufum: so anyway, what we should do next is to propose for development of multiple VDU scale at once at PTG. | 10:11 |
| takahashi-tsc | right? | 10:11 |
| yasufum | Anyway, I'd appreciate if you propose a spec in the next vPTG. | 10:11 |
| yasufum | takahashi-tsc: yes | 10:11 |
| takahashi-tsc | OK, thanks. | 10:11 |
| yasufum | I'd like to know how many the change is more exactly. | 10:12 |
| yasufum | if possible | 10:12 |
| yasufum | Sorry for taking so long time today. | 10:13 |
| yasufum | We should close this meeting if someone has no more comment. | 10:14 |
| ma-ooyama | Sure. Let me share my topic next meeting if there's time. | 10:14 |
| yasufum | ma-ooyama: sorry for today... | 10:14 |
| yasufum | Thank you for joining, bye! | 10:15 |
| ueha | thanks, bye! | 10:15 |
| manpreetk | Thanks and bye. | 10:15 |
| pooja | bye | 10:15 |
| yasufum | #endmeeting | 10:15 |
| opendevmeet | Meeting ended Tue Feb 22 10:15:41 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 10:15 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-22-08.02.html | 10:15 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-22-08.02.txt | 10:15 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-22-08.02.log.html | 10:15 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!