08:07:58 <yasufum> #startmeeting tacker
08:07:58 <opendevmeet> Meeting started Tue Jun 14 08:07:58 2022 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:07:58 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:07:58 <opendevmeet> The meeting name has been set to 'tacker'
08:08:06 <yuta-kazato> hi
08:08:13 <yasufum> hi
08:08:19 <h_asahina> hi
08:08:20 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:11:30 <yasufum_> oops, I’ve terminated for a while…
08:15:31 <yasufum> sorry, can you see my message?
08:15:50 <ueha> yes, I can see
08:15:52 <takahashi-tsc> Now yes,
08:15:53 <yuta-kazato> yes. I can see.
08:15:57 <Ramona-ho-xu> yes
08:16:03 <yasufum> thx
08:16:42 <yasufum> manpreet: I’ d ask you again, is there any update for RBAC for heat?
08:17:42 <manpreetk> yasufum: Sorry no updates as the policy popup meeting was postpone due to OpenInfra Berlin Event. Would update once receive any information. Thanks
08:18:00 <yasufum> OK, thanks!
08:20:23 <yasufum_> Let’s start from the first topici.
08:20:45 <yasufum_> #topic Next PTG
08:21:17 <yasufum> It will be held on October 17-20 at Columbus, Ohio
08:21:32 <yasufum> I mean it’s not a virtual event.
08:24:46 <yasufum> Although we are not sure situation of COVID-19 will be well, I’d like to have a meeting on the event.
08:27:33 <yasufum_> takahashi-tsc: My network codition is so bad, so could you host the meeting?
08:27:38 <yasufum_> :(
08:27:47 <takahashi-tsc> sure.
08:28:09 <yasufum> It’s just the second topic remained.
08:28:14 <yasufum> thx
08:28:15 <takahashi-tsc> yasufum, is there any other message about next PTG?
08:29:02 <yasufum> just one thing, I’d ask community if we can have hybrid meeting, onsite and online.
08:29:16 <yasufum> if possible.
08:30:01 <takahashi-tsc> Thanks. Yes it is better that PTG is hybrid meeting...
08:31:21 <takahashi-tsc> Anyway, if you get any information, please share it with us. Everyone, if you know any information, please share with us!
08:32:00 <takahashi-tsc> Then can we move to next topics? edagawa_kc, can you start?
08:33:12 <edagawa_kc> Sure.
08:33:26 <edagawa_kc> I would like to discuss the pagination feature in CLI.
08:33:53 <edagawa_kc> I have implemented the feature in Tacker server side according to ETSI SOL013 in Yoga cycle. Now I am considering how to design the pagination feature also in CLI side.
08:34:20 <edagawa_kc> In Zed vPTG, I have suggested some options for the design, but no conclusion have been reached. Now I would like to suggest a new option which can solve demerits in existing ones.
08:34:51 <edagawa_kc> I described the detail of that in [New option] part in the etherpad.
08:35:26 <edagawa_kc> I investigated the feasibility about this behavior, and found there already is the code which possibly enable such a behavior in client side.
08:35:56 <edagawa_kc> Therefore I would like to suggest implementing this CLI feature into target APIs according to existing code.
08:36:21 <edagawa_kc> That's all from my side.
08:37:21 <takahashi-tsc> Thanks, in my understanding, "suggested some options" is
08:37:24 <takahashi-tsc> https://etherpad.opendev.org/p/tacker-zed-ptg#L109
08:37:28 <takahashi-tsc> Is it correct?
08:37:48 <edagawa_kc> Yes, correct.
08:38:09 <takahashi-tsc> OK, thanks. Any comments?
08:38:46 <ma-ooyama> I have a comment.
08:39:10 <ma-ooyama> As the user, we want to retrieve all records by executing a command only once.
08:39:52 <ma-ooyama> So I think the implementation of "New option" looks good.
08:40:34 <edagawa_kc> Thank you for the comment, I see.
08:41:51 <takahashi-tsc> thanks, any other comments? I also think new option is better, because there is already some implementation.
08:43:47 <hirofumi-noguchi> Let me confirm the processing of new option.
08:45:04 <hirofumi-noguchi> With this new option, all_record functionality implemented on the client side and normal paging process is executed on the server side?
08:47:47 <hirofumi-noguchi> v2 API doesn't support the all option on the server side, but I wondered if this option could be used for v2 API.
08:48:54 <hirofumi-noguchi> Is my understanding correct or not?
08:49:07 <edagawa_kc> Your understanding is correct. In this case, server side behaves pagination. This is different from "all_records" feature in server side.
08:49:51 <hirofumi-noguchi> Thx, I see.
08:50:17 <hirofumi-noguchi> I was confused with all_record.
08:53:54 <takahashi-tsc> Any other comments? I think new option is basically agreed. Details of the spec will be discussed in gerrt.
08:54:10 <takahashi-tsc> Do anyone object new option?
08:56:00 <ueha> I agree too. thanks for suggestion the new option. :)
08:56:12 <takahashi-tsc> Good. edagawa_kc, I think you should update spec. please update your spec, and let's discuss it in gerrt.
08:56:47 <edagawa_kc> I see. I will update it and then post to gerrit. Thank you.
08:57:08 <takahashi-tsc> Good, so that's it. Any other topics for today's meeting?
08:57:35 <yasufum> nothing
08:58:22 <takahashi-tsc> OK, let's close today's meeting. Thank you everyone! bye
08:58:36 <ma-ooyama> bye
08:58:39 <ueha> thanks, bye
08:58:39 <yasufum> thanks, bye!
08:58:40 <caishuwen> bye
08:58:40 <edagawa_kc> bye
08:58:42 <manpreetk> bye
08:58:48 <takahashi-tsc> #endmeeting
09:02:20 <yuta-kazato> bye
09:04:23 <takahashi-tsc> ? The meeting is not closed yet?
09:04:42 <takahashi-tsc> #endmeeting
09:05:41 <masaki-ueno> #endmeeting seems to be enable only for the one who called #startmeeting...
09:07:24 <takahashi-tsc> Hmm, could you ask yasufum to close this meeting?
09:12:39 <takahashi-tsc> I sent email to yasufum.
09:13:32 <masaki-ueno> I also sent slack message to yasufum. Thanks :)
09:13:44 <takahashi-tsc> thanks!
09:17:04 <yasufum> #endmeeting