08:02:38 <yasufum> #startmeeting tacker
08:02:38 <opendevmeet> Meeting started Tue Jun 21 08:02:38 2022 UTC and is due to finish in 60 minutes.  The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:38 <opendevmeet> The meeting name has been set to 'tacker'
08:02:51 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting
08:04:18 <yasufum> We have three topic today.
08:05:22 <yasufum> I'd like to start from third topic because it can be done shortly.
08:05:43 <yasufum> #topic Proposal for extension of spec freeze
08:06:18 <yasufum> Do you have any other comments than two +1s on the etherpad?
08:08:53 <yasufum> hirofumi-noguchi: Do you have any idea for the extended deadline, how many times required to complete your specs?
08:10:28 <hirofumi-noguchi> How about extending deadline by one month, the end of july?
08:12:14 <yasufum> #link https://releases.openstack.org/zed/schedule.html
08:13:51 <yasufum> any comment on the idea?
08:14:16 <yasufum> or agree?
08:14:27 <takahashi-tsc> +1
08:14:31 <yuta-kazato> +1 I agree with hirofumi-noguchi
08:14:36 <w-juso> +1
08:15:06 <manpreetk> +1
08:15:22 <masaki-ueno> +1
08:15:23 <ueha> +1
08:15:27 <yasufum> thx
08:16:24 <yasufum> We've agreed to extend spec freeze to the end of July.
08:16:53 <yasufum> Go to the first topic if no more comments.
08:17:12 <yasufum> #topic centos-9-stream testing
08:18:52 <psingla> As it is decided that centos-8-stream testing will be dropped in Zed release , So we are planning to add centos-9-stream testsets in ZUUL.
08:20:42 <yasufum> OK, thanks.
08:20:46 <psingla> For this work, we want to know the community opinion about whether we should update or use the existing centos-8-stream blueprint or we need to create a new blueprint for centos-9-stream.
08:21:49 <psingla> Existing blueprint link for centos-8-stream : https://blueprints.launchpad.net/tacker/+spec/centos-stream-testing
08:23:44 <yasufum> I think we don't need to have tests for CentOS8 anymore and the bp and spec should be updated for.
08:23:53 <yasufum> takahashi-tsc: What do you think?
08:24:49 <takahashi-tsc> Agree. New BP is not needed.
08:25:31 <ueha> +1, I think it is better to update the existing spec and move it to the zed folder. The test patche have not been merged in the yoga version.
08:27:44 <yasufum> thanks
08:28:14 <psingla> The centos-8-stream testing spec is merged in Yoga release.
08:28:46 <yasufum> I think it's discussed enough for the topic.
08:29:00 <yasufum> So, go to the second topic.
08:29:28 <takahashi-tsc> test patches are not merged, but spec is merged. ueha, do you mean we should create *new* parch for "updating and moving existing spec"?
08:30:59 <ueha> Yes, New BP is not necessary but the existing BP should be update.
08:31:56 <takahashi-tsc> And spec too, right? So need patch for updating existing spec.
08:31:57 <ueha> Sorry, BP -> Spec
08:32:10 <takahashi-tsc> Ah, OK.
08:33:26 <yasufum> I've just updated the bp for CentOS "9", and a typo :)
08:33:35 <psingla> Thanks.
08:33:36 <yasufum> #link https://blueprints.launchpad.net/tacker/+spec/centos-stream-testing
08:33:49 <yasufum> The spec only remained to be update.
08:33:58 <psingla> thanks
08:34:03 <yasufum> Can we go to the next one?
08:34:11 <yasufum> You're welcome.
08:34:45 <edagawa_kc> Sure.
08:34:48 <yasufum> #topic Regarding API pagination issue and how to fix it
08:35:08 <yasufum> pls share your topic shortly.
08:35:13 <edagawa_kc> I have three topics regarding API paging feature. Let me start from Topic 1.
08:35:30 <edagawa_kc> Okey, I see.
08:35:54 <edagawa_kc> Currently there is an issue regarding API pagination implemented in Yoga. The detail is reported in launchpad.
08:36:10 <edagawa_kc> The root cause is that paging information is not shared in case of multi-server environment.
08:36:29 <edagawa_kc> To avoid this issue, I would like to introduce new pagination framework used in Nova.
08:36:46 <edagawa_kc> It is partially used also in Tacker, so we can follow it and implement to API pagination, too.
08:36:59 <edagawa_kc> I would like to ask your opinion. That's all about topic 1.
08:38:19 <yasufum> thanks
08:41:28 <yasufum> Is your proposal in topic 1 just fixing the issue without introducing any of now behavior, correct?
08:41:40 <yasufum> s/now/new/
08:42:24 <edagawa_kc> Basically yes.
08:43:08 <yasufum> hmm
08:43:30 <edagawa_kc> Actually, generating nextpage marker uuid is changed, but the behavior in client side will not changed.
08:49:27 <yasufum> You mean "nextpage_opaque_marker" more correctly, and the value of it will be changed to an ID in DB?
08:49:42 <yasufum> I'm not sure about pagination in nova actually.
08:52:50 <edagawa_kc> Your understanding is correct. Currently marker uuid is generated inside server, but in Nova's feature, the ID in DB is used.
08:53:13 <edagawa_kc> The ID is shared in DB, so such a issue will not occur.
08:53:24 <edagawa_kc> The marker parameter is the ID of the last item in the previous list.
08:53:51 <yasufum> In other word, you don't change the name of the variable "nextpage_opaque_marker", right?
08:55:00 <edagawa_kc> Yes, this name is defined by ESTI, so it should not be changed.
08:55:18 <yasufum> OK, now I'm clear about your proposal.
08:55:36 <yasufum> Do you have any other comment, everyone?
08:56:20 <yasufum> OK.
08:57:22 <yasufum> edagawa_kc: What is the point in topic2?
08:57:59 <edagawa_kc> Topic 2 is about the difference between current and Nova's pagination condition.
08:58:41 <edagawa_kc> In short, it is convenient to implement the process of adding "rel:next" into response body in server side.
08:59:12 <edagawa_kc> This is because no need to modify client side.
08:59:57 <edagawa_kc> However, current behavior is also compliant with ESTI, so we should not remove it.
09:00:30 <yasufum> i see
09:04:07 <yasufum> is that all?
09:04:26 <edagawa_kc> Yes.
09:07:08 <yasufum> any comment?
09:07:17 <h_asahina> is it difficult to change the client side?
09:08:20 <h_asahina> It seems the difference is just a location of "rel:next" (or "rel=next")
09:09:49 <h_asahina> if my understanding is correct, two different attributes having the same role (or functionality) should be maintained.
09:10:39 <h_asahina> sorry if i'm wrong.
09:11:13 <edagawa_kc> For first question, actually it is not so difficult. The main reason of my proposal is that there is no change in client side any more.
09:11:51 <edagawa_kc> Also your understanding regarding different attributes having the same role is correct.
09:14:07 <h_asahina> it might be unfavorable in terms of maintainability
09:15:22 <h_asahina> so if it's easy, changing the client side to fit the changes in the server would be better. please note that I said it just for the maintainability.
09:18:07 <takahashi-tsc> edagawa_kc, maybe there is if branch which check "rel:next" in body. Is it some common function? or is it in Tacker-client repository(i.e. code is cloned?)
09:18:56 <takahashi-tsc> If it is common funtion, changing CLI side is not good. But it is in tacker-client separately, h_asahina's proposal is better.
09:19:38 <takahashi-tsc> This is my opinion.
09:20:30 <edagawa_kc> This function is internally implemented in Tacker-client repository. So it can be modified with some changes from Nova's behavior.
09:21:04 <takahashi-tsc> I see, if so, I think changing client is better...
09:22:14 <edagawa_kc> I understand. I will consider to changing client side. Thank you for the suggestion.
09:22:37 <h_asahina> good. thank you :)
09:22:57 <yasufum> No less-compatibility for the standards by this change?
09:26:28 <yasufum> edagawa_kc: ?
09:27:00 <edagawa_kc> What do you mean by "standard"? In ESTI standard side, this change is not affected.
09:27:12 <edagawa_kc> As for openstack standard, there is some difference, but no impact exists because this is only the issue between server and client.
09:27:32 <yasufum> it's definetely ETSI
09:29:08 <yasufum> I'm not still sure is there any restriction for proposal, but looks no problem about it.
09:30:23 <edagawa_kc> It is no problem.
09:31:25 <yasufum> For topic3, is it a tiny issue actually, or not?
09:32:30 <edagawa_kc> It is tiny issue, so I can proceed with implementation. Please discuss in gerrit review later.
09:33:29 <yasufum> agree
09:34:40 <yasufum> Do you agree to the proposal, topic1-3, everyone?
09:37:02 <masaki-ueno> +1
09:37:10 <k_fukaya> +1
09:37:20 <ueha> +1
09:37:45 <yasufum> :)
09:38:07 <yasufum> no opposition for now.
09:38:45 <yasufum> let's close this meeting if no more comment.
09:39:12 <yasufum> Sorry for taking your time so much.
09:39:26 <yasufum> Thank you for joining, Bye!
09:39:30 <takahashi-tsc> Bye
09:39:31 <edagawa_kc> Thank you for your suggestions today. Bye.
09:39:36 <yuta-kazato> bye!
09:39:38 <h_asahina> bye
09:39:54 <yasufum> #endmeeting