Tuesday, 2022-03-01

yasufumhi tacker team08:01
yasufum#startmeeting tacker08:03
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:03
opendevmeetThe meeting name has been set to 'tacker'08:03
yasufumma-ooyama: are you joining?08:03
yasufumI'd like to start from your item if it's ready.08:04
yasufummove onto the next topic08:05
yasufumoops, he also mightn't be here.08:07
yasufumueha: this item is from h-asahina and you actually, right?08:08
uehaI will explain instead.08:08
uehaAs we discussed last week, we're developing another multitenat FT depending on multi-tenant FT patches.08:09
uehahttps://review.opendev.org/c/openstack/tacker/+/823965 and https://review.opendev.org/c/openstack/tacker/+/83030208:09
uehaIf the current Zuul error is caused by Heat, CNF thinks there is no problem.08:10
uehaSo 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
yasufummanpreetk: what do you think?08:11
manpreetkueha: In case of CNF, you must be adding new Zuul job?08:11
uehaOr if it will be resolved soon, I will wait. But RC1 is just around the corner, so We can't wait much..08:11
uehaYes, we will add new Zuul job.08:12
manpreetkWill this CNF testing impact VNF functional test cases??08:13
manpreetkI mean do you expect merge conflicts??08:13
uehaI don't think it will affect the VNF side because we will change the package to be used and test it.08:14
uehaI don't think there is a big merge conflict, but it may happen in common part.08:14
manpreetkCommon part? would be functional test framework.08:15
uehaIt will probably be a code section, such as running instantiate. I'm not sure if there is at the moment.08:16
manpreetkOk, then I believe it should be fine to merge CNF test cases, if there aren't any major conflicts. 08:17
manpreetkRegarding heat policy modification, yes this change might need some time( a week so)  to be fully functional. 08:19
yasufummanpreetk: Thank you for your large effort for the contribution.08:20
manpreetkyasufum: Thank you  🙂08:21
yasufumueha: Do you have any idea when your patch is uploaded?08:21
uehaWe will consider and implement to avoid merge conflicts as much as possible. thank you manpreet-san! :)08:21
manpreetkueha: Thanks and most welcome!!08:22
uehayasufum: 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
yasufumI've just asked when you'll upload the patch if you are ready to do so.08:25
uehasorry, but my colleague is actually implementing it, so I need to check when it will be uploaded.08:27
yasufumOK, thanks.08:28
yasufumIs there any comment?08:29
h_asahinathank you ueha: for the explanation. I had a network trouble.08:30
uehah_asahina: you are welcome :)08:30
yasufumI've noticed that ma-ooyama cannot join today on the etherpad.08:32
yasufumSo, I'd close this meeting if no more topics today.08:33
uehaI notice that next week is RC1 target.08:33
yasufum#link https://releases.openstack.org/yoga/schedule.html08:35
uehaSo I will focus more on reviews. and the patch I'm posting needs to be reviewed by Takahashi-san..08:35
uehaI was thinking of asking him, but he doesn't seem to be joining.08:35
manpreetkueha: Takahashi san is facing some network issue, so unable to join IRC meeting.08:36
uehamanpreetk: Thank you! Could you tell him if possible?08:37
manpreetkueha : sure :)08:37
uehathanks a lot :)08:38
uehathat's all from my side. thanks08:39
esto-alnueha: I have one point on my side08:40
uehaabout [WIP] Move Sample Kubernetes Driver Directory08:40
ueha ?08:40
esto-alnas we discussed before, since we will introduce sample ansible driver under mgmt_driver, we moved the directory of kubernetes..08:40
esto-alnso, the patch is here: https://review.opendev.org/c/openstack/tacker/+/83094508:40
esto-alncould you confirm the movement?08:41
uehaWe will test this patch, I will report the result to gerrit. :)08:41
esto-alnThank you so much!08:41
esto-alnthat's all from my side..08:42
uehasure, thanks for your patch.08:42
yasufumThank you for the discussion.08:43
yasufumany other comment?08:43
ma-ooyamaSorry to interrupt.08:44
ma-ooyamaI was finally able to access here. So sorry for delay.08:44
yasufumno problem.08:44
yasufumWe have 15 min left, so you can share topic if it takes no so much time.08:45
yasufumWhat do you think?08:45
ma-ooyamaSure. let me share my topic.08:46
ma-ooyamaAfter 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-ooyamaBut there is no need for us to have deep discussion at this moment, I think.08:46
ma-ooyamaFirst topic is about automatic state change.08:46
ma-ooyamaWe use multiple tacker-conductors like N-Act architecture in our environment, and so each tacker-conductor handles LcmOpOcc respectively.08:47
ma-ooyamaIf 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-ooyamaWe think LcmOpOccs handled by healthy tacker-conductor shouldn't be failed.08:47
ma-ooyamaSo 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-ooyamaWhat do you think about this opinion?08:48
h_asahinaThank you for your comment. Could you please elaborate on your environment?08:49
h_asahinaDo you share a single DB with multipe conductors?08:50
ma-ooyamaWe use multiple DB like N act.08:53
h_asahinaYou mean the relationship between conductor and DB is 1:1?08:55
h_asahinaWhy are the unrelated LcmOpOccs involved in automatic state changes?08:56
ma-ooyamasorry, its not correct. Sharing Act DB between multiple conductors.08:57
h_asahinaI see08:57
h_asahinaYour suggestion explicitly assumes the environment that the conductor shares Act DBs08:59
h_asahina /explicitly/implicitly/g   sorry09:00
h_asahinaI wonder if it is a appropriate N-act architecture for tacker...09:00
h_asahinaWhat 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-tscIt should not be a strong assumption, but I think we needs to be considered such pattern...09:05
h_asahinaThank 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-tscYes... I think we 09:09
takahashi-tscsorry, 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-tscIf so, now we can porceed with development for automated state change 09:10
h_asahinaI agree09:10
ma-ooyamathank you for considering our opinion. I'm glad if you think about this point after implementing functionality of automated state change.09:12
h_asahinaBTW, 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/g09:12
ma-ooyamaSorry, I can't say how often it happens, but we think implementing this function is important.09:16
h_asahinaI understand. thanks. sorry, one more thing. is it possible to recover such a problem by hand?09:17
h_asahinaI mean if the healthy LcmOpOccs are involved, can you recover it correctly. I think it's possible though...09:18
ma-ooyamaYes, retrying manually is possible.09:18
h_asahinagood. Thank you so much for the discussion.09:19
takahashi-tscBasically seems OK, but I also wrote some concerns in etherpad.09:19
yasufumtakahashi-tsc: thanks09:20
yasufumPlease continue to discuss for the topic on the etherpad, or the next vPTG if it's required.09:22
yasufumWe'd better to wrap up this meeting for today.09:24
yasufumThanks for joining, bye!09:24
manpreetkthanks, bye.09:24
h_asahinathanks, bye09:24
ma-ooyamaSure, thank you. bye.09:24
opendevmeetMeeting ended Tue Mar  1 09:24:34 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:24
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-03-01-08.03.html09:24
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-03-01-08.03.txt09:24
opendevmeetLog:            https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-03-01-08.03.log.html09:24
uehathanks bye.09:24
*** hemna8 is now known as hemna16:07
*** dasm|rover is now known as dasm|off22:39

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