08:03:07 <yasufum> #startmeeting tacker
08:03:07 <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:07 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:03:07 <opendevmeet> The meeting name has been set to 'tacker'
08:03:58 <yasufum> ma-ooyama: are you joining?
08:04:33 <yasufum> I'd like to start from your item if it's ready.
08:05:28 <yasufum> OK
08:05:55 <yasufum> move onto the next topic
08:07:22 <yasufum> oops, he also mightn't be here.
08:08:00 <yasufum> ueha: this item is from h-asahina and you actually, right?
08:08:09 <ueha> I will explain instead.
08:08:11 <ueha> yes
08:08:15 <yasufum> thx
08:09:07 <ueha> As we discussed last week, we're developing another multitenat FT depending on multi-tenant FT patches.
08:09:26 <ueha> https://review.opendev.org/c/openstack/tacker/+/823965 and https://review.opendev.org/c/openstack/tacker/+/830302
08:10:14 <ueha> If the current Zuul error is caused by Heat, CNF thinks there is no problem.
08:10:56 <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:11:30 <yasufum> manpreetk: what do you think?
08:11:50 <manpreetk> ueha: In case of CNF, you must be adding new Zuul job?
08:11:51 <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:12:37 <ueha> Yes, we will add new Zuul job.
08:13:01 <manpreetk> Will this CNF testing impact VNF functional test cases??
08:13:44 <manpreetk> I mean do you expect merge conflicts??
08:14:26 <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:52 <ueha> I don't think there is a big merge conflict, but it may happen in common part.
08:15:39 <manpreetk> Common part? would be functional test framework.
08:16:58 <ueha> It will probably be a code section, such as running instantiate. I'm not sure if there is at the moment.
08:17:59 <manpreetk> Ok, then I believe it should be fine to merge CNF test cases, if there aren't any major conflicts.
08:19:00 <ueha> Thanks
08:19:10 <manpreetk> Regarding heat policy modification, yes this change might need some time( a week so)  to be fully functional.
08:20:25 <yasufum> manpreetk: Thank you for your large effort for the contribution.
08:21:07 <manpreetk> yasufum: Thank you  🙂
08:21:41 <yasufum> ueha: Do you have any idea when your patch is uploaded?
08:21:56 <ueha> We will consider and implement to avoid merge conflicts as much as possible. thank you manpreet-san! :)
08:22:33 <manpreetk> ueha: Thanks and most welcome!!
08:24:31 <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:25:36 <yasufum> I've just asked when you'll upload the patch if you are ready to do so.
08:27:55 <ueha> sorry, but my colleague is actually implementing it, so I need to check when it will be uploaded.
08:28:11 <yasufum> OK, thanks.
08:29:55 <yasufum> Is there any comment?
08:30:23 <h_asahina> thank you ueha: for the explanation. I had a network trouble.
08:30:57 <ueha> h_asahina: you are welcome :)
08:31:46 <yasufum> good
08:32:32 <yasufum> I've noticed that ma-ooyama cannot join today on the etherpad.
08:33:04 <yasufum> So, I'd close this meeting if no more topics today.
08:33:55 <ueha> I notice that next week is RC1 target.
08:35:04 <yasufum> sure
08:35:08 <yasufum> #link https://releases.openstack.org/yoga/schedule.html
08:35:17 <ueha> So I will focus more on reviews. and the patch I'm posting needs to be reviewed by Takahashi-san..
08:35:47 <ueha> I was thinking of asking him, but he doesn't seem to be joining.
08:36:20 <manpreetk> ueha: Takahashi san is facing some network issue, so unable to join IRC meeting.
08:37:28 <ueha> manpreetk: Thank you! Could you tell him if possible?
08:37:41 <manpreetk> ueha : sure :)
08:38:04 <ueha> thanks a lot :)
08:39:22 <ueha> that's all from my side. thanks
08:40:03 <esto-aln> ueha: I have one point on my side
08:40:24 <ueha> about [WIP] Move Sample Kubernetes Driver Directory
08:40:24 <ueha> ?
08:40:44 <esto-aln> as we discussed before, since we will introduce sample ansible driver under mgmt_driver, we moved the directory of kubernetes..
08:40:55 <esto-aln> so, the patch is here: https://review.opendev.org/c/openstack/tacker/+/830945
08:41:27 <esto-aln> could you confirm the movement?
08:41:39 <ueha> We will test this patch, I will report the result to gerrit. :)
08:41:50 <esto-aln> Thank you so much!
08:42:04 <esto-aln> that's all from my side..
08:42:07 <ueha> sure, thanks for your patch.
08:43:08 <yasufum> Thank you for the discussion.
08:43:35 <yasufum> any other comment?
08:44:16 <ma-ooyama> Sorry to interrupt.
08:44:27 <ma-ooyama> I was finally able to access here. So sorry for delay.
08:44:49 <yasufum> no problem.
08:45:38 <yasufum> We have 15 min left, so you can share topic if it takes no so much time.
08:45:45 <yasufum> What do you think?
08:46:06 <ma-ooyama> Sure. let me share my topic.
08:46:23 <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:40 <ma-ooyama> But there is no need for us to have deep discussion at this moment, I think.
08:46:53 <ma-ooyama> First topic is about automatic state change.
08:47:21 <ma-ooyama> We use multiple tacker-conductors like N-Act architecture in our environment, and so each tacker-conductor handles LcmOpOcc respectively.
08:47:37 <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:52 <ma-ooyama> We think LcmOpOccs handled by healthy tacker-conductor shouldn't be failed.
08:48:12 <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:48 <ma-ooyama> What do you think about this opinion?
08:49:50 <h_asahina> Thank you for your comment. Could you please elaborate on your environment?
08:50:04 <h_asahina> Do you share a single DB with multipe conductors?
08:53:37 <ma-ooyama> We use multiple DB like N act.
08:55:47 <h_asahina> You mean the relationship between conductor and DB is 1:1?
08:56:42 <h_asahina> Why are the unrelated LcmOpOccs involved in automatic state changes?
08:57:27 <ma-ooyama> sorry, its not correct. Sharing Act DB between multiple conductors.
08:57:38 <h_asahina> I see
08:59:23 <h_asahina> Your suggestion explicitly assumes the environment that the conductor shares Act DBs
09:00:21 <h_asahina> /explicitly/implicitly/g   sorry
09:00:52 <h_asahina> I wonder if it is a appropriate N-act architecture for tacker...
09:00:59 <h_asahina> What do you all think?
09:04:05 <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:05:52 <takahashi-tsc> It should not be a strong assumption, but I think we needs to be considered such pattern...
09:07:21 <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:09:18 <takahashi-tsc> Yes... I think we
09:09:53 <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:10:28 <takahashi-tsc> If so, now we can porceed with development for automated state change
09:10:51 <h_asahina> I agree
09:12:06 <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:32 <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:51 <h_asahina> /health/healthy/g
09:16:12 <ma-ooyama> Sorry, I can't say how often it happens, but we think implementing this function is important.
09:17:55 <h_asahina> I understand. thanks. sorry, one more thing. is it possible to recover such a problem by hand?
09:18:35 <h_asahina> I mean if the healthy LcmOpOccs are involved, can you recover it correctly. I think it's possible though...
09:18:56 <ma-ooyama> Yes, retrying manually is possible.
09:19:24 <h_asahina> good. Thank you so much for the discussion.
09:19:58 <takahashi-tsc> Basically seems OK, but I also wrote some concerns in etherpad.
09:20:30 <yasufum> takahashi-tsc: thanks
09:22:50 <yasufum> Please continue to discuss for the topic on the etherpad, or the next vPTG if it's required.
09:24:01 <yasufum> We'd better to wrap up this meeting for today.
09:24:10 <yasufum> Thanks for joining, bye!
09:24:17 <takahashi-tsc> thanks
09:24:19 <manpreetk> thanks, bye.
09:24:22 <h_asahina> thanks, bye
09:24:25 <ma-ooyama> Sure, thank you. bye.
09:24:26 <masaki-ueno> bye
09:24:34 <yasufum> #endmeeting