08:03:09 <yasufum> #startmeeting tacker
08:03:09 <opendevmeet> Meeting started Tue Feb 15 08:03:09 2022 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:03:09 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:03:09 <opendevmeet> The meeting name has been set to 'tacker'
08:03:25 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:04:15 <yasufum> Let's start this meeting.
08:05:28 <yasufum> Before go to items for today, I'd like to thank you to give feedbacks for our proposal for the next summit.
08:06:25 <yasufum> We've finished to register all items from NTT.
08:06:50 <yasufum> So, let's move on to the first item for today
08:07:27 <yasufum> manpreetk: Can you share your issue?
08:07:40 <manpreetk> Yes please.
08:07:52 <manpreetk> Would like to discuss the problem faced while executing FT for multi-tenant policy in Zuul.
08:07:52 <manpreetk> Please refer to L7 for problem detail, to summarize, the functional test case for multi-tenant policy fails while initializing heatclient for the newly created user, a `Keyerror` is observed for `domain_name`. The `domain_name` field is part of VIM config file for example check `tacker/tests/etc/samples/local-vim.yaml` , this field is refer in class method 'heatclient' define in test base class 'BaseTackerTest'. The
08:07:52 <manpreetk> multi-tenant FT setup creates VIM config files using `tools/gen_vim_config.sh`. The script does not add the "domain_name" field while creating the VIM config file. I have proposed two possible solutions and would like to seek community opinion.
08:07:52 <manpreetk> That's all from my side, thank you.
08:08:55 <yasufum> please wait for a second...
08:09:00 <yasufum> for understanding your topic
08:09:20 <manpreetk> sure
08:14:41 <yasufum> First, sorry for my lackness of understanding for the vim config.
08:15:43 <yasufum> It might be my failure not to introduced the attribute as you pointed out.
08:15:56 <yasufum> I think solution#1 is required.
08:16:07 <yasufum> What do you think?
08:17:35 <manpreetk> Thank you yasufum for your opinion, yes solution#1 looks good to me as well. But I have additional question regarding related docs, would like to hear your opinion.
08:19:16 <yasufum> Do you ask me just it's needed to modify, or how should be the contents?
08:19:43 <yasufum> I'd like to make it clear the point.
08:21:26 <manpreetk> Initially I would like to know whether we need to reintroduce this field in docs .
08:23:48 <yasufum> I think it's needed.
08:25:24 <manpreetk> ok
08:27:38 <ueha> I'm sorry that I don't know much about openstack vim configuration, but when I look at "[3]" do we really only need two things, "user_domain_name" and "project_domain_name"?
08:27:41 <ueha> [3] https://github.com/openstack/tacker/blob/master/tacker/tests/functional/base.py#L168
08:29:20 <ueha> At L169-170, it looks like it is just assigning to the two parameters.
08:31:24 <manpreetk> ueha: Honestly I don't have much details , even I have same understanding that domain for project and user should be important. As suggested in solution#2 L25, we need to have deep analysis for changing source code.
08:32:21 <yasufum> I don't know the reason, but it looks something shortcut for me.
08:34:33 <yasufum> It expect that user_domain_name and project_domain_name are the same, and we can give just domain_name as common one.
08:35:49 <yasufum> But I think it should refer user and domain names if there exist in this test.
08:37:20 <yasufum> For me, domain_name is useless if no reason explained.
08:38:13 <yasufum> Although it should be remained if there is any other use of domain_name.
08:39:20 <ueha> agree, but I wonder if this is a parameter for use only with FT.
08:40:28 <manpreetk> There is one reference other than FT, [6] https://github.com/openstack/tacker/blob/6fc64560e23560903b05954e4a8105d8f7375631/tacker/keymgr/barbican_key_manager.py#L94
08:40:28 <manpreetk> But i haven't investigated.
08:41:25 <ueha> If the "domain_name" parameter is only for use with FT, and are not needed in the actual vim_config, I don't think we need to add it to vim_config_generator.
08:41:48 <ueha> umm.. It is also used other than tests.
08:43:48 <ueha> Anyway, I think "Solution#1" is no problem if you add it as a temporary fixes and delete it later because of the time it takes to investigate.
08:45:06 <manpreetk> ueha: Thanks for your opinion.
08:45:56 <yasufum> Do you know domain_name should be the same as project_domain_name or user_domain_name?
08:46:08 <yasufum> or can be different?
08:46:56 <yasufum> Is there any checking in codes for the names?
08:47:58 <manpreetk> Sorry that's something I was looking for in OpenStack docs/source code but hardly found anything relevant.
08:49:44 <yasufum> umm...
08:52:04 <yasufum> Even if there is no such a checking, it's better to make a rule to avoid ambiguity
08:52:33 <yasufum> now we are having it...
08:54:29 <yasufum> What do you think that domain_name should be the same as project_domain_name?
08:55:53 <yasufum> I think it doesn't cause any problem, and agreeable for users.
08:58:30 <ueha> I think the context.domain_name in "[6]" seems different from vim_config.. (Credentials that executed the Openstack command/API?)
08:59:33 <ueha> so, it's a suggestion to change except "[6](barbicanclient)" once and see how it works.
09:00:26 <yasufum> sure, we need to have some more testing for the codes.
09:02:06 <yasufum> manpreetk: can you check what's happened if the values are the same or different?
09:03:06 <yasufum> to discuss for the decision next week
09:03:19 <manpreetk> yasufum: Sure could check that.
09:03:33 <yasufum> thanks a lot!
09:05:12 <yasufum> Any comment, everyone?
09:07:09 <yasufum> good
09:07:32 <yasufum> I've added my comment on the etherpad.
09:08:28 <yasufum> Thanks for the discussion.
09:09:06 <manpreetk> Thanks
09:09:10 <ueha> Thanks too. :)
09:09:22 <manpreetk> Thank you ueha san.
09:10:20 <yasufum> Let's close this meeting if you don't have any other topic.
09:10:54 <yasufum> Thank you for joining, bye!
09:11:02 <ueha> thanks, bye
09:11:03 <manpreetk> Thanks and Bye!!
09:11:04 <takahashi-tsc> 1 small point, I think we shuold merge spec as soon as possible. Please review them soon.
09:11:16 <takahashi-tsc> I'll also review them soon...
09:12:14 <takahashi-tsc> 3 or 4 spec seem still on-goin.
09:12:54 <takahashi-tsc> That's it, thanks
09:13:09 <yasufum> sure, thanks!
09:13:26 <yasufum> #endmeeting