| yasufum | Hi, tacker team. | 08:00 |
|---|---|---|
| manpreetk | Hi | 08:00 |
| h-asahina | hi | 08:00 |
| Ramona-ho-xu | hi | 08:00 |
| masaki-ueno | hi | 08:00 |
| caishuwen | hi | 08:01 |
| takahashi-tsc | hi | 08:01 |
| ma-ooyama | hi | 08:01 |
| yasufum | #startmeeting tacker | 08:01 |
| opendevmeet | Meeting started Tue Apr 26 08:01:34 2022 UTC and is due to finish in 60 minutes. The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:01 |
| opendevmeet | The meeting name has been set to 'tacker' | 08:01 |
| yasufum | Can I confirm today's topics? | 08:02 |
| yasufum | #link https://etherpad.opendev.org/p/tacker-meeting | 08:04 |
| yasufum | We don't need to discuss topics labeled as 'no update'? | 08:04 |
| yasufum | right? | 08:05 |
| ma-ooyama | I think so. | 08:05 |
| takahashi-tsc | I move my topic to the bottom because there is no topic. Probably we should move topics which is not today's to bottom | 08:07 |
| yasufum | ma-ooyama: It must be the first item for today, "About CLI support for paging" | 08:07 |
| yasufum | takahashi-tsc: thanks | 08:07 |
| ma-ooyama | Sorry, do you mean this? "About "v1 API Refactoring (h-asahina)" (ma-ooyama)" | 08:09 |
| yasufum | yes | 08:10 |
| ma-ooyama | Sure. | 08:10 |
| ma-ooyama | First, I want to confirm my understanding below is right. | 08:11 |
| ma-ooyama | Migration from v1 API to v2 API requires re-instantiation due to the different API versions, but this is a different discussion point from the Refactoring to be discussed in this issue | 08:11 |
| ma-ooyama | What do you think? | 08:12 |
| yasufum | maybe so | 08:14 |
| h-asahina | I agree with you. Deprecation/Refactoring and Migration are the different topcis. | 08:14 |
| ma-ooyama | Thanks. So we should discuss the migration from existing v1 to new v1. | 08:15 |
| ma-ooyama | Regarding the migration from the existing v1 API to the new v1 API, there are VNFs already operating with the existing v1 API, so the consideration of the impact on those VNFs is needed. | 08:15 |
| ma-ooyama | Since rebuilding a VNF used in a commercial environment carries the risk of service running and the timing of EOL varies from VNF to VNF, it is better to consider the DB migration without re-instantiation. | 08:16 |
| ma-ooyama | This is our opinion. | 08:17 |
| h-asahina | Thanks. We're seeking the way to realize DB migration from the old v1 to the new v1. | 08:17 |
| h-asahina | but, there are many barriers, so we need to continuously discuss the feasibility of this plan. | 08:18 |
| h-asahina | I understand your demand, but let me confirm the difficulty of re-instantiation. | 08:18 |
| ma-ooyama | Thanks. Let us discuss it further. | 08:19 |
| h-asahina | Even if each VNF has different EOL, it looks still possible to re-instantiate VNF when it reaches to EOL like rolling update. | 08:20 |
| h-asahina | Could you tell me what is the actual difficulty here? | 08:20 |
| h-asahina | Note that it's not rolling update actually, it's just a metaphor. | 08:21 |
| ma-ooyama | For example, there are some VNF that reach EOL after 10 years. | 08:22 |
| ma-ooyama | For more such VNFs, it requires that using the current v1 API without re-instantiation. | 08:26 |
| ma-ooyama | in later 10 years. | 08:26 |
| h-asahina | I see. 10 years might be enough long time.... | 08:28 |
| h-asahina | Thanks. I understand the necessity of the migration from the old v1 to the new v1. | 08:29 |
| yasufum | Thanks | 08:30 |
| yasufum | I'm not sure it's a general requirement for us, but let continue to discuss. | 08:31 |
| yasufum | Can we go to the next topic if you have no more comment? | 08:32 |
| ma-ooyama | Thank you for your discussion. I'm looking forward to contacting with you for later issues. | 08:32 |
| h-asahina | me too. thanks. please move on yasufum: | 08:33 |
| yasufum | good | 08:33 |
| yasufum | #topic About Refactoring | 08:33 |
| ma-ooyama | Sure. | 08:33 |
| ma-ooyama | After the previous PTG, we discussed the topic of "Refactoring (caishuwen)" in our team. | 08:33 |
| ma-ooyama | We think current v1 implementatoin that doesn't actually delete records but updates the delete field to 1 doesn't matter. | 08:33 |
| ma-ooyama | Because the history of what record is deleted is needed and to clean up old records is user's responsiblity. | 08:34 |
| ma-ooyama | What do you think? | 08:34 |
| yasufum | #link https://etherpad.opendev.org/p/tacker-zed-ptg | 08:35 |
| caishuwen | I agree with your opinion. This topic was brought up just for database performance reasons. | 08:35 |
| ma-ooyama | https://hackmd.io/cGgvfdl-ToKASRiWfw_hcA | 08:35 |
| ma-ooyama | Thanks. | 08:38 |
| caishuwen | But I have a question, do our users know that after the delete operation, the record in the database will not be deleted. | 08:38 |
| ma-ooyama | I think this is general implementation about database and so users may know that. | 08:41 |
| caishuwen | If users don't know, should we update the existing user guide documentation to remind users about this? | 08:41 |
| ma-ooyama | I think it is better. | 08:45 |
| caishuwen | Thanks. That's all my opinion. | 08:46 |
| ma-ooyama | Sorry but I don't know details of user guide now. | 08:47 |
| yasufum | I'm not sure the purpose of describing the behavior actually. | 08:47 |
| yasufum | Is it for telling users to delete entries in the DB by themselve or so? | 08:48 |
| yasufum | I'd like to make it clear what's expected users to do by updating docs. | 08:50 |
| caishuwen | Yes, tell the user that if the record in the database is really no longer needed, the record can be deleted by themselve. | 08:50 |
| caishuwen | If a large amount of historical data affects the performance of the database. | 08:51 |
| yasufum | Umm, it might contradict with suggestion from ma-ooyama | 08:55 |
| yasufum | that current behaivor of not deleting entries. | 08:55 |
| yasufum | is not a problem. | 08:56 |
| yasufum | If we really need to delete the entries at last, I think it's better to implement delettion. | 08:57 |
| ma-ooyama | Does Caishuwen mean it is better to describe how to manualy delete records in user guide? | 08:58 |
| caishuwen | yes | 08:59 |
| caishuwen | I think ma-ooyama's opinion is that it is up to the user to delete the record or not. | 09:00 |
| ma-ooyama | You are right. so I agree with that. | 09:00 |
| ma-ooyama | Are there some commands to delete records like nova-manage in tacker? | 09:01 |
| yasufum | We have a similar tool, tacker-db-manage, but I haven't tries to delete a record with it. | 09:04 |
| ma-ooyama | Thanks. | 09:09 |
| yasufum | ma-ooyama: For my lack of understanging of nova-manage, can you give me an example of usage of deleting? | 09:09 |
| yasufum | Any url of doc for describing it? | 09:10 |
| ma-ooyama | Sorry, I don't know details of how to use commands to delete. The url is here. https://docs.openstack.org/nova/latest/cli/nova-manage.html | 09:11 |
| yasufum | Thanks, I'll chack it. | 09:11 |
| ma-ooyama | Thank you. | 09:11 |
| yasufum | Anyway, how we delete entries on DB must be covered in its manual. So, we should make it clear what should be explained in tacker's docs without such a usage of DB itself. | 09:14 |
| yasufum | I've understood docs of tacker-db-manage is not enough for explaining usages and we have to update :) | 09:16 |
| ma-ooyama | Thanks. I agree with your opinion. | 09:17 |
| caishuwen | Me too. | 09:17 |
| yasufum | I think you can learn the behavior of tacker-db-manage from its help message for now. | 09:18 |
| yasufum | Thanks for the discussion. | 09:18 |
| yasufum | Is there any other comment to topic? | 09:19 |
| takahashi-tsc | I'm a little concerned that tacker-db-manage support management of few of all tacker tables.... | 09:19 |
| takahashi-tsc | No topic from myside. | 09:20 |
| yasufum | We might need to have some updates for tacker-db-manage possibly, thanks. | 09:21 |
| yasufum | OK, it seems enough for today. | 09:22 |
| yasufum | Thank you for joining, bye! | 09:22 |
| ma-ooyama | Thanks, bye. | 09:22 |
| Ramona-ho-xu | bye | 09:22 |
| takahashi-tsc | Thanks, bye | 09:22 |
| caishuwen | bye | 09:22 |
| masaki-ueno | bye | 09:23 |
| manpreetk | bye | 09:23 |
| h-asahina | bye | 09:23 |
| yasufum | #endmeeting | 09:23 |
| opendevmeet | Meeting ended Tue Apr 26 09:23:14 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:23 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-26-08.01.html | 09:23 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-26-08.01.txt | 09:23 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-26-08.01.log.html | 09:23 |
| yuta-kazato | bye | 09:23 |
| yu-kinjo | bye | 09:23 |
| *** dasm|off is now known as dasm | 12:04 | |
| dmendiza[m] | gmann: 👋 | 14:32 |
| dmendiza[m] | gmann: are we meeting for Policy Pop-up today? | 14:33 |
| gmann | dmendiza[m]: yes, we are in https://meetpad.opendev.org/secure-rbac | 14:33 |
| *** dasm is now known as dasm|off | 21:40 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!