| yasufum | Hi tacker team. | 08:01 |
|---|---|---|
| manpreetk | Hi | 08:01 |
| ueha | hi | 08:01 |
| takahashi-tsc | hi | 08:01 |
| yasufum | #startmeeting tacker | 08:03 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:03 |
| opendevmeet | The meeting name has been set to 'tacker' | 08:03 |
| yasufum | #link https://etherpad.opendev.org/p/tacker-meeting | 08:03 |
| yasufum | Let's start this meeting. | 08:04 |
| yasufum | Before go to items for today, I'd like to thank you to give feedbacks for our proposal for the next summit. | 08:05 |
| yasufum | We've finished to register all items from NTT. | 08:06 |
| yasufum | So, let's move on to the first item for today | 08:06 |
| yasufum | manpreetk: Can you share your issue? | 08:07 |
| manpreetk | Yes please. | 08:07 |
| manpreetk | Would like to discuss the problem faced while executing FT for multi-tenant policy in Zuul. | 08:07 |
| 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 |
| 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 |
| manpreetk | That's all from my side, thank you. | 08:07 |
| yasufum | please wait for a second... | 08:08 |
| yasufum | for understanding your topic | 08:09 |
| manpreetk | sure | 08:09 |
| yasufum | First, sorry for my lackness of understanding for the vim config. | 08:14 |
| yasufum | It might be my failure not to introduced the attribute as you pointed out. | 08:15 |
| yasufum | I think solution#1 is required. | 08:15 |
| yasufum | What do you think? | 08:16 |
| 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:17 |
| yasufum | Do you ask me just it's needed to modify, or how should be the contents? | 08:19 |
| yasufum | I'd like to make it clear the point. | 08:19 |
| manpreetk | Initially I would like to know whether we need to reintroduce this field in docs . | 08:21 |
| yasufum | I think it's needed. | 08:23 |
| manpreetk | ok | 08:25 |
| 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 |
| ueha | [3] https://github.com/openstack/tacker/blob/master/tacker/tests/functional/base.py#L168 | 08:27 |
| ueha | At L169-170, it looks like it is just assigning to the two parameters. | 08:29 |
| 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:31 |
| yasufum | I don't know the reason, but it looks something shortcut for me. | 08:32 |
| 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:34 |
| yasufum | But I think it should refer user and domain names if there exist in this test. | 08:35 |
| yasufum | For me, domain_name is useless if no reason explained. | 08:37 |
| yasufum | Although it should be remained if there is any other use of domain_name. | 08:38 |
| ueha | agree, but I wonder if this is a parameter for use only with FT. | 08:39 |
| 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 |
| manpreetk | But i haven't investigated. | 08:40 |
| 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 |
| ueha | umm.. It is also used other than tests. | 08:41 |
| 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:43 |
| manpreetk | ueha: Thanks for your opinion. | 08:45 |
| yasufum | Do you know domain_name should be the same as project_domain_name or user_domain_name? | 08:45 |
| yasufum | or can be different? | 08:46 |
| yasufum | Is there any checking in codes for the names? | 08:46 |
| manpreetk | Sorry that's something I was looking for in OpenStack docs/source code but hardly found anything relevant. | 08:47 |
| yasufum | umm... | 08:49 |
| yasufum | Even if there is no such a checking, it's better to make a rule to avoid ambiguity | 08:52 |
| yasufum | now we are having it... | 08:52 |
| yasufum | What do you think that domain_name should be the same as project_domain_name? | 08:54 |
| yasufum | I think it doesn't cause any problem, and agreeable for users. | 08:55 |
| ueha | I think the context.domain_name in "[6]" seems different from vim_config.. (Credentials that executed the Openstack command/API?) | 08:58 |
| ueha | so, it's a suggestion to change except "[6](barbicanclient)" once and see how it works. | 08:59 |
| yasufum | sure, we need to have some more testing for the codes. | 09:00 |
| yasufum | manpreetk: can you check what's happened if the values are the same or different? | 09:02 |
| yasufum | to discuss for the decision next week | 09:03 |
| manpreetk | yasufum: Sure could check that. | 09:03 |
| yasufum | thanks a lot! | 09:03 |
| yasufum | Any comment, everyone? | 09:05 |
| yasufum | good | 09:07 |
| yasufum | I've added my comment on the etherpad. | 09:07 |
| yasufum | Thanks for the discussion. | 09:08 |
| manpreetk | Thanks | 09:09 |
| ueha | Thanks too. :) | 09:09 |
| manpreetk | Thank you ueha san. | 09:09 |
| yasufum | Let's close this meeting if you don't have any other topic. | 09:10 |
| yasufum | Thank you for joining, bye! | 09:10 |
| ueha | thanks, bye | 09:11 |
| manpreetk | Thanks and Bye!! | 09:11 |
| takahashi-tsc | 1 small point, I think we shuold merge spec as soon as possible. Please review them soon. | 09:11 |
| takahashi-tsc | I'll also review them soon... | 09:11 |
| takahashi-tsc | 3 or 4 spec seem still on-goin. | 09:12 |
| takahashi-tsc | That's it, thanks | 09:12 |
| yasufum | sure, thanks! | 09:13 |
| yasufum | #endmeeting | 09:13 |
| opendevmeet | Meeting ended Tue Feb 15 09:13:26 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:13 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-15-08.03.html | 09:13 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-15-08.03.txt | 09:13 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-02-15-08.03.log.html | 09:13 |
| *** dasm|off is now known as dasm | 11:00 | |
| *** carloss is now known as carloss|afk | 11:20 | |
| *** carloss|afk is now known as carloss | 13:25 | |
| martial | Hello scientific sig friends | 21:02 |
| b1airo | o/ | 21:04 |
| martial | hello Blair | 21:04 |
| martial | resisting the urge to start meeting if it is just the two of us :) [we can slack if needed :) ] | 21:05 |
| b1airo | yeah, i'm guessing that'll be it. am wondering if we shouldn't come up with a new schedule of fortnightly or monthly meetings | 21:06 |
| martial | Hi Mike, welcome :) | 21:10 |
| jmlowe | Hey Martial | 21:10 |
| jmlowe | I finally joined a meeting again | 21:11 |
| b1airo | ha | 21:11 |
| jmlowe | Anything on the agenda? | 21:17 |
| b1airo | NeSI's annual plan :-P , oh wait, wrong meeting | 21:17 |
| b1airo | jmlowe: you guys using Ironic yet? | 21:19 |
| jmlowe | No, in the usual scramble to get through acceptance ironic plans got dropped | 21:19 |
| b1airo | for JS2 this is? | 21:20 |
| jmlowe | Yes | 21:20 |
| martial | even julian is here :) | 21:20 |
| b1airo | Do you have a vendor doing OpenStack stuff for Jetstream? | 21:20 |
| jmlowe | I did discover two interested things in the interim, one linuxbridge unicast vxlan seems to fall over around 300 nodes and my dvr floating ip patches work unmodified with openvswitch | 21:21 |
| jmlowe | Nope, I'm the vendor | 21:21 |
| b1airo | that's what i thought | 21:22 |
| b1airo | so you are planning on adding Ironic at some stage then? | 21:23 |
| jmlowe | There's never any money for software vendors in a competitive bid | 21:23 |
| jmlowe | I'm not sure I can figure out how to safely and reasonably do it with all layer 3 | 21:24 |
| b1airo | L3 to the node? | 21:24 |
| jmlowe | You'd have to put some trust in bgp from the tenants and we all know how that would work out | 21:24 |
| jmlowe | Yes, everything is /32 | 21:25 |
| b1airo | could your network not support some L2 hosts too? | 21:25 |
| jmlowe | I could probably work something out with vteps on the switches | 21:26 |
| jmlowe | Unfortunately there isn't enough time to do much | 21:29 |
| b1airo | have you put vGPU in prod? | 21:29 |
| jmlowe | It's not part of the mandate, and right now only the essentials are going to make it to production which starts in 3-4 weeks | 21:30 |
| b1airo | ah right, well good luck!! :-) | 21:31 |
| jmlowe | On the upside we did get 123GBs write and 368GBs read out of our ceph cluster | 21:32 |
| julianp | Nice. | 21:32 |
| b1airo | radosbench numbers? | 21:32 |
| jmlowe | rbd bench | 21:33 |
| jmlowe | 64 clients for write and 128 clients for read | 21:33 |
| b1airo | oh yeah, nice. how many async threads for those clients? | 21:34 |
| jmlowe | 128, 128 core milans | 21:37 |
| martial | (virtual end meeting :) ) | 22:03 |
| martial | thanks friends | 22:03 |
| julianp | Till next time! | 22:04 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!