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