08:02:55 <yasufum> #startmeeting tacker
08:02:55 <opendevmeet> Meeting started Tue Dec 21 08:02:55 2021 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:55 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:55 <opendevmeet> The meeting name has been set to 'tacker'
08:04:35 <esto-aln> hello
08:04:51 <edagawa_kc> hi
08:05:03 <yasufum> there are three topics proposed on the ehterpad today.
08:05:14 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:06:31 <yasufum> Before going to go to the first topic, I'd like to talk two things.
08:06:50 <yasufum> One is about spec freeze.
08:07:35 <yasufum> I think most of us are going to be off next week.
08:08:30 <yasufum> although several patches are still remained under reviewing.
08:09:34 <yasufum> I think we don't need to hurry for fixing these patches actually.
08:10:43 <yasufum> So, I'd like to suggest to update the date of the deadline which was agreed as "best effort" target at the previous vPTG.
08:11:32 <yasufum> I think mid of the next week is reasonable, but want to here your comment.
08:11:37 <yasufum> What do you think?
08:13:27 <ueha> +1, I think it will be difficult at the end of this month, because there are some specs I have commented that have not been revised.
08:13:27 <takahashi-tsc> mid of next month? (Jan.)
08:13:43 <yasufum> yes, you are correct
08:14:04 <takahashi-tsc> OK, +1.
08:14:07 <manpreetk> +1
08:15:25 <yasufum> thx
08:17:41 <yasufum> Considering many of us may going to go to return in the second week next month, I think 21th Fri is appropriate for the date.
08:19:22 <ueha> I agree
08:19:34 <yasufum> I'll update the date on etherpad of the previous vPTG.
08:19:37 <yasufum> #link https://etherpad.opendev.org/p/tacker-yoga-ptg
08:19:48 <takahashi-tsc> sure, thanks
08:19:58 <yasufum> Please give your comment if you have any other alternative or comment. Thanks.
08:20:26 <yasufum> thanks
08:22:08 <yasufum> My second topic is just an announcement. I'd skip IRC meeting next week
08:22:34 <yasufum> and have the next one on 11th Jan.
08:22:57 <yasufum> I'll also share it on ML later. Thanks.
08:24:11 <yasufum> If no one has a comment for the schedule, go to the first topic on etherpad.
08:24:54 <yasufum> good
08:25:22 <yasufum> ueha: can you share your topic about the current issue on gate test.
08:25:32 <ueha> Sure,
08:25:57 <ueha> currently, sol-kubernetes job often has another error.
08:26:21 <ueha> An error occurred because the processing of the heal entire did not complete in the time waiting for COMPLETED in test.
08:26:37 <ueha> This error can be resolved by increasing the timeout period during the heal entire test.
08:27:02 <ueha> I have posted the patch, so could you review it? https://review.opendev.org/c/openstack/tacker/+/822285
08:27:29 <ueha> That's all from my side, any comment?
08:30:23 <yasufum> thanks
08:31:26 <yasufum> We have several unclear timeouts which depend on infra...
08:32:59 <yasufum> It's hard to find such a failure in general
08:33:30 <yasufum> and we cannot this update fixes the issue completely.
08:34:03 <yasufum> But I think it is doable for the current situation.
08:34:49 <yasufum> It has been tested several times and looks OK.
08:35:15 <yasufum> ueha: many thanks for your effort! I'd give +2.
08:35:50 <ueha> Thanks for comments! :)
08:36:06 <takahashi-tsc> I'll also give +2, thanks
08:36:29 <ueha> takahashi-tsc: thanks!
08:38:28 <yasufum> ok, go to the next topic from edagawa_kc.
08:38:43 <edagawa_kc> Sure.
08:39:09 <edagawa_kc> Currently there is one topic I would like to confirm here regarding my spec.
08:39:26 <edagawa_kc> The detail has been described in the etherpad.
08:39:40 <edagawa_kc> The main point is whether we need returning "400 bad request" case or not during an API response.
08:39:57 <edagawa_kc> In my thought, there is no problem to only use paged case, but I would like to ask your opinions.
08:42:17 <edagawa_kc> That's all from my side.
08:44:37 <yasufum> thanks
08:44:41 <yasufum> any comment?
08:49:48 <yasufum> nothing?
08:50:49 <ueha> +1, I think it is better because there is no need to add non-SOL compliant parameter.
08:51:06 <yasufum> I think it depends on usecases although I don't suppose to opposite to your idea.
08:54:07 <yasufum> Anyway, it might be OK as ueha commented.
08:54:16 <takahashi-tsc> I think no usecase which should expect 400 bad error... but I think we should explain that GET API's default behavior is paging in API reference.
08:55:29 <edagawa_kc> I see, I understand your opinions are the same as mine. Also I will add description of this behaviour into API reference.
08:56:12 <edagawa_kc> I will start updating my spec, too. Thanks.
08:57:24 <yasufum> thanks
08:57:58 <yasufum> seems we can go to the next topic.
08:58:19 <yasufum> esto-aln: can you share your topic?
08:58:26 <esto-aln> sure
08:59:10 <esto-aln> Basically, we have a proposal to change the directory structure under: tacker/samples/mgmt_driver
08:59:25 <esto-aln> the proposal details are in the etherpad
08:59:58 <esto-aln> We have some concern points, which I discussed from line 147.
09:01:03 <esto-aln> Firstly, we would like to know whether you agree that we create sub-directory under mgmt_driver?
09:01:48 <esto-aln> Secondly, if there are concerns if we relocate the kubernetes files to "tacker/samples/mgmt_driver/kubernetes" directory..
09:02:15 <esto-aln> will it work properly if relocated?
09:02:46 <esto-aln> and are there other items which needs to be updated as an effect of the change in directory?
09:03:02 <esto-aln> That's all from my side.
09:03:45 <yasufum> I think this change has no impact other than docs because we don't have any tests for the samples.
09:03:53 <yasufum> ueha: What do you think?
09:04:58 <ueha> The kubernetesMgmtDriver's python file may also need some changes
09:06:06 <yasufum> Is it because for resolving path dependency or so in the code itself?
09:06:30 <ueha> https://opendev.org/openstack/tacker/src/branch/master/samples/mgmt_driver/kubernetes_mgmt.py#L441
09:07:05 <ueha> https://opendev.org/openstack/tacker/src/branch/master/samples/mgmt_driver/kubespray/kubespray_mgmt.py#L277
09:07:50 <ueha> It seems that the path hard coded above.
09:10:05 <yasufum> It must be one of bad habits honestly :)
09:10:42 <esto-aln> Yes, I think we have the same recognition.. but is it okay whether Ueha-san can update such source codes?
09:11:29 <ueha> You can fix it with the same patch.
09:11:43 <yasufum> Anyway, I think it is not so critical if we need just to update such a path.
09:12:07 <esto-aln> I understand.. anyway, please support us.. please do check if the changes are enough or need to have more files to update..
09:13:05 <esto-aln> yasufum: yes, I think so, too... but just in case, there might be some issue.. we would like to consult Ueha-san.
09:13:20 <yasufum> ueha: Do you mean update two thing, for kubernetes and ansible, with a single patch?
09:13:21 <ueha> Sure, when a patch is posted, test it internally.
09:15:00 <esto-aln> you mean, Ueha-san will test internally, right?
09:15:31 <ueha> yasufum: Yes, I think it should be update same patch.
09:16:36 <ueha> esto-aln: yes, may test by me or my colleague
09:16:55 <esto-aln> okay, many thanks, Ueha-san!
09:19:08 <esto-aln> any other comments?
09:19:34 <yasufum> ueha: I don't agree basically because we should make a change topic by topic without any reason should do so.
09:20:12 <yasufum> although it is a tiny change
09:20:31 <yasufum> to minimize if we have some troubles possibly
09:21:32 <yasufum> Could I confirm the reason why it's better to update with one patch?
09:21:57 <takahashi-tsc> Do you mean we should create a patch "change k8s sample directory" and a patch "add ansible driver" separetely?
09:23:44 <yasufum> takahashi-tsc: Yes. I think it's better to test the change of directly without adding ansible driver basically.
09:23:46 <ueha> It doesn't mean much, but I thought it would be bad if the function  doesn't work which is hit by one patch.
09:23:56 <ueha> I think it would be good if they could be merged with other patches in order and with no gap in time.
09:25:00 <yasufum> I understand the changes does not affect on gate tests, just want to clarify the reason.
09:25:49 <yasufum> the reason why we should make the changes with one patch.
09:27:34 <ueha> "should" is different. I'm sorry for my poor English expression.
09:27:38 <yasufum> ueha: OK, I understand you just considering about the time to be merged.
09:30:45 <yasufum> In my conclusion, I think one patch is OK if changes for currenrt mgmt driver is just two lines or so, and ueha surely tests the patch from esto-aln.
09:31:34 <esto-aln> okay, I understand the conclusion.
09:32:07 <esto-aln> We will proceed based on community's conclusion.
09:32:23 <yasufum> Thanks for discussion all!
09:33:12 <esto-aln> Thank you
09:35:28 <yasufum> any other comment?
09:36:37 <yasufum> good
09:36:58 <yasufum> done all for today
09:37:42 <yasufum> Thank you all for joining.
09:37:52 <takahashi-tsc> Thanks
09:37:56 <esto-aln> Thank you
09:37:58 <ueha> thanks, bye
09:38:00 <edagawa_kc> Bye
09:38:01 <yasufum> Have a nice holiday!
09:38:01 <manpreetk> Thanks bye
09:38:03 <esto-aln> bye
09:38:04 <yasufum> Bye
09:38:23 <yasufum> #endmeeting