| yasufum | hi tacker team | 08:01 |
|---|---|---|
| manpreetk | hi | 08:01 |
| ueha | hi | 08:01 |
| yasufum | #startmeeting tacker | 08:03 |
| opendevmeet | Meeting started Tue Mar 1 08:03:07 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 | ma-ooyama: are you joining? | 08:03 |
| yasufum | I'd like to start from your item if it's ready. | 08:04 |
| yasufum | OK | 08:05 |
| yasufum | move onto the next topic | 08:05 |
| yasufum | oops, he also mightn't be here. | 08:07 |
| yasufum | ueha: this item is from h-asahina and you actually, right? | 08:08 |
| ueha | I will explain instead. | 08:08 |
| ueha | yes | 08:08 |
| yasufum | thx | 08:08 |
| ueha | As we discussed last week, we're developing another multitenat FT depending on multi-tenant FT patches. | 08:09 |
| ueha | https://review.opendev.org/c/openstack/tacker/+/823965 and https://review.opendev.org/c/openstack/tacker/+/830302 | 08:09 |
| ueha | If the current Zuul error is caused by Heat, CNF thinks there is no problem. | 08:10 |
| ueha | So I want to confirm that is it possible to merge the FT for CNF first and rebase the FT for VNF onto the FT for CNF later? | 08:10 |
| yasufum | manpreetk: what do you think? | 08:11 |
| manpreetk | ueha: In case of CNF, you must be adding new Zuul job? | 08:11 |
| ueha | Or if it will be resolved soon, I will wait. But RC1 is just around the corner, so We can't wait much.. | 08:11 |
| ueha | Yes, we will add new Zuul job. | 08:12 |
| manpreetk | Will this CNF testing impact VNF functional test cases?? | 08:13 |
| manpreetk | I mean do you expect merge conflicts?? | 08:13 |
| ueha | I don't think it will affect the VNF side because we will change the package to be used and test it. | 08:14 |
| ueha | I don't think there is a big merge conflict, but it may happen in common part. | 08:14 |
| manpreetk | Common part? would be functional test framework. | 08:15 |
| ueha | It will probably be a code section, such as running instantiate. I'm not sure if there is at the moment. | 08:16 |
| manpreetk | Ok, then I believe it should be fine to merge CNF test cases, if there aren't any major conflicts. | 08:17 |
| ueha | Thanks | 08:19 |
| manpreetk | Regarding heat policy modification, yes this change might need some time( a week so) to be fully functional. | 08:19 |
| yasufum | manpreetk: Thank you for your large effort for the contribution. | 08:20 |
| manpreetk | yasufum: Thank you 🙂 | 08:21 |
| yasufum | ueha: Do you have any idea when your patch is uploaded? | 08:21 |
| ueha | We will consider and implement to avoid merge conflicts as much as possible. thank you manpreet-san! :) | 08:21 |
| manpreetk | ueha: Thanks and most welcome!! | 08:22 |
| ueha | yasufum: Sorry, what is "any idea"..? I have no idea at the moment, but we will implement it first without setting the patches as a parent patch. | 08:24 |
| yasufum | I've just asked when you'll upload the patch if you are ready to do so. | 08:25 |
| ueha | sorry, but my colleague is actually implementing it, so I need to check when it will be uploaded. | 08:27 |
| yasufum | OK, thanks. | 08:28 |
| yasufum | Is there any comment? | 08:29 |
| h_asahina | thank you ueha: for the explanation. I had a network trouble. | 08:30 |
| ueha | h_asahina: you are welcome :) | 08:30 |
| yasufum | good | 08:31 |
| yasufum | I've noticed that ma-ooyama cannot join today on the etherpad. | 08:32 |
| yasufum | So, I'd close this meeting if no more topics today. | 08:33 |
| ueha | I notice that next week is RC1 target. | 08:33 |
| yasufum | sure | 08:35 |
| yasufum | #link https://releases.openstack.org/yoga/schedule.html | 08:35 |
| ueha | So I will focus more on reviews. and the patch I'm posting needs to be reviewed by Takahashi-san.. | 08:35 |
| ueha | I was thinking of asking him, but he doesn't seem to be joining. | 08:35 |
| manpreetk | ueha: Takahashi san is facing some network issue, so unable to join IRC meeting. | 08:36 |
| ueha | manpreetk: Thank you! Could you tell him if possible? | 08:37 |
| manpreetk | ueha : sure :) | 08:37 |
| ueha | thanks a lot :) | 08:38 |
| ueha | that's all from my side. thanks | 08:39 |
| esto-aln | ueha: I have one point on my side | 08:40 |
| ueha | about [WIP] Move Sample Kubernetes Driver Directory | 08:40 |
| ueha | ? | 08:40 |
| esto-aln | as we discussed before, since we will introduce sample ansible driver under mgmt_driver, we moved the directory of kubernetes.. | 08:40 |
| esto-aln | so, the patch is here: https://review.opendev.org/c/openstack/tacker/+/830945 | 08:40 |
| esto-aln | could you confirm the movement? | 08:41 |
| ueha | We will test this patch, I will report the result to gerrit. :) | 08:41 |
| esto-aln | Thank you so much! | 08:41 |
| esto-aln | that's all from my side.. | 08:42 |
| ueha | sure, thanks for your patch. | 08:42 |
| yasufum | Thank you for the discussion. | 08:43 |
| yasufum | any other comment? | 08:43 |
| ma-ooyama | Sorry to interrupt. | 08:44 |
| ma-ooyama | I was finally able to access here. So sorry for delay. | 08:44 |
| yasufum | no problem. | 08:44 |
| yasufum | We have 15 min left, so you can share topic if it takes no so much time. | 08:45 |
| yasufum | What do you think? | 08:45 |
| ma-ooyama | Sure. let me share my topic. | 08:46 |
| ma-ooyama | After discussion about "Error handling for tacker-conductor down (h-asahina)" at Feb 1st, I have discussed that in my team, and would like to share our opinions. | 08:46 |
| ma-ooyama | But there is no need for us to have deep discussion at this moment, I think. | 08:46 |
| ma-ooyama | First topic is about automatic state change. | 08:46 |
| ma-ooyama | We use multiple tacker-conductors like N-Act architecture in our environment, and so each tacker-conductor handles LcmOpOcc respectively. | 08:47 |
| ma-ooyama | If all LcmOpOccs in -ING state are changed to FAILED_TEMP when one tacker-conductor is restarted, LcmOpOccs handled by other healthy tacker-conductor is also changed. | 08:47 |
| ma-ooyama | We think LcmOpOccs handled by healthy tacker-conductor shouldn't be failed. | 08:47 |
| ma-ooyama | So if functionality to change state automatically will be implemented, we think it is needed to implement functionality that can know which LcmOpOccs are handled by which tacker-conductor. | 08:48 |
| ma-ooyama | What do you think about this opinion? | 08:48 |
| h_asahina | Thank you for your comment. Could you please elaborate on your environment? | 08:49 |
| h_asahina | Do you share a single DB with multipe conductors? | 08:50 |
| ma-ooyama | We use multiple DB like N act. | 08:53 |
| h_asahina | You mean the relationship between conductor and DB is 1:1? | 08:55 |
| h_asahina | Why are the unrelated LcmOpOccs involved in automatic state changes? | 08:56 |
| ma-ooyama | sorry, its not correct. Sharing Act DB between multiple conductors. | 08:57 |
| h_asahina | I see | 08:57 |
| h_asahina | Your suggestion explicitly assumes the environment that the conductor shares Act DBs | 08:59 |
| h_asahina | /explicitly/implicitly/g sorry | 09:00 |
| h_asahina | I wonder if it is a appropriate N-act architecture for tacker... | 09:00 |
| h_asahina | What do you all think? | 09:00 |
| takahashi-tsc | (Sorry I can join this call now). I think, the structure which ma-ooyama explain is typical pattern for High availabilty of OpenStack controller. | 09:04 |
| takahashi-tsc | It should not be a strong assumption, but I think we needs to be considered such pattern... | 09:05 |
| h_asahina | Thank you, takahashi-tsc:. If so, I feel adding such a functionality makes sense as it won't harm the implementation of automatic state change but will help to create HA architecture. | 09:07 |
| takahashi-tsc | Yes... I think we | 09:09 |
| takahashi-tsc | sorry, we can add such (handled by which tacker-conductor in multi-process environment.) feature can be added after automated state change feature is implemented. | 09:09 |
| takahashi-tsc | If so, now we can porceed with development for automated state change | 09:10 |
| h_asahina | I agree | 09:10 |
| ma-ooyama | thank you for considering our opinion. I'm glad if you think about this point after implementing functionality of automated state change. | 09:12 |
| h_asahina | BTW, how often do you think the above problem (health LcmOpOccs are involvecd in the automatic state chanve) happen? ma-ooyama:. I'd like to know urgency. | 09:12 |
| h_asahina | /health/healthy/g | 09:12 |
| ma-ooyama | Sorry, I can't say how often it happens, but we think implementing this function is important. | 09:16 |
| h_asahina | I understand. thanks. sorry, one more thing. is it possible to recover such a problem by hand? | 09:17 |
| h_asahina | I mean if the healthy LcmOpOccs are involved, can you recover it correctly. I think it's possible though... | 09:18 |
| ma-ooyama | Yes, retrying manually is possible. | 09:18 |
| h_asahina | good. Thank you so much for the discussion. | 09:19 |
| takahashi-tsc | Basically seems OK, but I also wrote some concerns in etherpad. | 09:19 |
| yasufum | takahashi-tsc: thanks | 09:20 |
| yasufum | Please continue to discuss for the topic on the etherpad, or the next vPTG if it's required. | 09:22 |
| yasufum | We'd better to wrap up this meeting for today. | 09:24 |
| yasufum | Thanks for joining, bye! | 09:24 |
| takahashi-tsc | thanks | 09:24 |
| manpreetk | thanks, bye. | 09:24 |
| h_asahina | thanks, bye | 09:24 |
| ma-ooyama | Sure, thank you. bye. | 09:24 |
| masaki-ueno | bye | 09:24 |
| yasufum | #endmeeting | 09:24 |
| opendevmeet | Meeting ended Tue Mar 1 09:24:34 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:24 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-03-01-08.03.html | 09:24 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-03-01-08.03.txt | 09:24 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-03-01-08.03.log.html | 09:24 |
| ueha | thanks bye. | 09:24 |
| esto-aln | bye | 09:28 |
| *** hemna8 is now known as hemna | 16:07 | |
| *** dasm|rover is now known as dasm|off | 22:39 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!