Tuesday, 2022-04-26

yasufumHi, tacker team.08:00
yasufum#startmeeting tacker08:01
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:01
opendevmeetThe meeting name has been set to 'tacker'08:01
yasufumCan I confirm today's topics?08:02
yasufum#link https://etherpad.opendev.org/p/tacker-meeting08:04
yasufumWe don't need to discuss topics labeled as 'no update'?08:04
ma-ooyamaI think so.08:05
takahashi-tscI 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
yasufumma-ooyama: It must be the first item for today, "About CLI support for paging"08:07
yasufumtakahashi-tsc: thanks08:07
ma-ooyamaSorry, do you mean this? "About "v1 API Refactoring (h-asahina)" (ma-ooyama)"08:09
ma-ooyamaFirst, I want to confirm my understanding below is right.08:11
ma-ooyamaMigration 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 issue08:11
ma-ooyamaWhat do you think?08:12
yasufummaybe so08:14
h-asahinaI agree with you. Deprecation/Refactoring and Migration are the different topcis.08:14
ma-ooyamaThanks. So we should discuss the migration from existing v1 to new v1.08:15
ma-ooyamaRegarding 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-ooyamaSince 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-ooyamaThis is our opinion. 08:17
h-asahinaThanks. We're seeking the way to realize DB migration from the old v1 to the new v1.08:17
h-asahinabut, there are many barriers, so we need to continuously discuss the feasibility of this plan.08:18
h-asahinaI understand your demand, but let me confirm the difficulty of re-instantiation.08:18
ma-ooyamaThanks. Let us discuss it further.08:19
h-asahinaEven 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-asahinaCould you tell me what is the actual difficulty here?08:20
h-asahinaNote that it's not rolling update actually, it's just a metaphor.08:21
ma-ooyamaFor example, there are some VNF that reach EOL after 10 years.08:22
ma-ooyamaFor more such VNFs, it requires that using the current v1 API without re-instantiation.08:26
ma-ooyamain later 10 years.08:26
h-asahinaI see. 10 years might be enough long time....08:28
h-asahinaThanks. I understand the necessity of the migration from the old v1 to the new v1.08:29
yasufumI'm not sure it's a general requirement for us, but let continue to discuss.08:31
yasufumCan we go to the next topic if you have no more comment?08:32
ma-ooyamaThank you for your discussion. I'm looking forward to contacting with you for later issues.08:32
h-asahiname too. thanks. please move on yasufum:08:33
yasufum#topic About Refactoring 08:33
ma-ooyamaAfter the previous PTG, we discussed  the topic of "Refactoring  (caishuwen)" in our team.08:33
ma-ooyamaWe think current v1 implementatoin that doesn't actually delete records but updates the delete field to 1 doesn't matter.08:33
ma-ooyamaBecause the history of what record is deleted is needed and to clean up old records is user's responsiblity.08:34
ma-ooyamaWhat do you think?08:34
yasufum#link https://etherpad.opendev.org/p/tacker-zed-ptg08:35
caishuwenI agree with your opinion. This topic was brought up just for database performance reasons.08:35
ma-ooyamaThanks. 08:38
caishuwenBut 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-ooyamaI think this is general implementation about database and so users may know that.08:41
caishuwenIf users don't know, should we update the existing user guide documentation to remind users about this?08:41
ma-ooyamaI think it is better.08:45
caishuwenThanks. That's all my opinion.08:46
ma-ooyamaSorry but I don't know details of user guide now.08:47
yasufumI'm not sure the purpose of describing the behavior actually.08:47
yasufumIs it for telling users to delete entries in the DB by themselve or so?08:48
yasufumI'd like to make it clear what's expected users to do by updating docs.08:50
caishuwenYes, tell the user that if the record in the database is really no longer needed, the record can be deleted by themselve.08:50
caishuwenIf a large amount of historical data affects the performance of the database.08:51
yasufumUmm, it might contradict with suggestion from ma-ooyama08:55
yasufumthat current behaivor of not deleting entries.08:55
yasufumis not a problem.08:56
yasufumIf we really need to delete the entries at last, I think it's better to implement delettion.08:57
ma-ooyamaDoes Caishuwen mean it is better to describe how to manualy delete records in user guide?08:58
caishuwenI think ma-ooyama's opinion is that it is up to the user to delete the record or not.09:00
ma-ooyamaYou are right. so I agree with that.09:00
ma-ooyamaAre there some commands to delete records like nova-manage in tacker?09:01
yasufumWe have a similar tool, tacker-db-manage, but I haven't tries to delete a record with it.09:04
yasufumma-ooyama: For my lack of understanging of nova-manage, can you give me an example of usage of deleting?09:09
yasufumAny url of doc for describing it?09:10
ma-ooyamaSorry, 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.html09:11
yasufumThanks, I'll chack it.09:11
ma-ooyamaThank you.09:11
yasufumAnyway, 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
yasufumI've understood docs of tacker-db-manage is not enough for explaining usages and we have to update :)09:16
ma-ooyamaThanks. I agree with your opinion.09:17
caishuwenMe too.09:17
yasufumI think you can learn the behavior of tacker-db-manage from its help message for now.09:18
yasufumThanks for the discussion.09:18
yasufumIs there any other comment to topic?09:19
takahashi-tscI'm a little concerned that tacker-db-manage support management of few of all tacker tables....09:19
takahashi-tscNo topic from myside.09:20
yasufumWe might need to have some updates for tacker-db-manage possibly, thanks.09:21
yasufumOK, it seems enough for today.09:22
yasufumThank you for joining, bye!09:22
ma-ooyamaThanks, bye.09:22
takahashi-tscThanks, bye09:22
opendevmeetMeeting ended Tue Apr 26 09:23:14 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:23
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-26-08.01.html09:23
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-26-08.01.txt09:23
opendevmeetLog:            https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-26-08.01.log.html09:23
*** dasm|off is now known as dasm12:04
dmendiza[m]gmann: 👋14:32
dmendiza[m]gmann: are we meeting for Policy Pop-up today?14:33
gmanndmendiza[m]: yes, we are in https://meetpad.opendev.org/secure-rbac14:33
*** dasm is now known as dasm|off21:40

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!