Tuesday, 2022-04-19

*** dasm is now known as dasm|off00:11
yasufumhi, tacker team.08:00
yasufum#startmeeting tacker08:01
opendevmeetMeeting started Tue Apr 19 08:01:27 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
yasufumFirst of all, can you tell me which items are going to be discussed today :)08:03
masaki-uenoMy one is for today's discussion08:04
yasufumAll of them without noted as "no update"?08:04
ma-ooyamaI have three topics today.08:05
yasufumHow about yours, hirofumi-noguchi and ma-ooyama?08:05
yasufumma-ooyama: thanks08:05
hirofumi-noguchiMy one is also today's discussion.08:06
yasufumOK, thanks. It's all clear.08:06
yasufum#topic About Bugs in CreateVnfRequest Procedure and Default VIM08:07
yasufummasaki-ueno: can you start from your item?08:07
masaki-uenoAs you may know, bugs in CreateVnfRequest is reported on launchpad08:08
masaki-ueno#link https://bugs.launchpad.net/tacker/+bug/196868008:08
masaki-uenoCreateVnfRequest fails if there's no default VIM in TackerDB, and I confirmed it in my environment.08:09
masaki-uenoAlso, I confirmed the proposed workaround in the bugreport works08:09
masaki-uenobut I also noticed the bugs in the procedure08:10
masaki-uenoCreateVnfRequest needs at least one default VIM, but it works regardless of its VIM type08:10
masaki-uenoI mean, CreateVnfRequest for CNF works even if the default VIM is OpenStack....08:11
masaki-uenoThe behavior comes from the code:08:11
masaki-ueno#link https://opendev.org/openstack/tacker/src/branch/master/tacker/api/vnflcm/v1/controller.py#L47008:11
masaki-uenoAnd the reason why default VIM is needed in the procedure is here08:12
masaki-ueno#link https://github.com/openstack/tacker/blob/master/tacker/api/vnflcm/v1/controller.py#L387-L39708:12
masaki-uenoAs described in SOL002, CreateVnfRequest is a procedure for creating the base of VNF instances, so VIM information is not needed here.08:12
masaki-uenoSorry, not SOL002 but 00308:13
masaki-uenoThe above implementation requires VIM information at CreateVnfReq, so it is a mismatch between implementation and specification.08:13
masaki-uenoI'd like to ask you whether this should be fixed or not, because it is peculiar to v1 API, which will be deprecated in the future development.08:14
masaki-uenoThat's all for my topic.08:15
masaki-uenoNote that the author of bugreport has already uploaded patch that fixes user docs08:16
yasufumIn my opinion, fixing docs is reasonable as a quick fix.08:16
masaki-uenoYes, I agree with you > yasufum. I will check the fixed part of docs later.08:17
yasufumFor another topic, fix codes itself, I think it should also be fixed although it will be deprecated.08:19
yasufumBecause we've not made any agreement for the date of the deprecation.08:19
yasufumI think we don't need to maintain actively, adding new feature or so in other words, but should keep it run well.08:22
yasufumAny other opinion for the bug?08:22
masaki-uenoI see. But we may have to carefully investigate codes depends on this implementation in advance, and I haven't done it yet...08:23
takahashi-tscAgree with yasufum, no need to make high priority, but need to fix bugs in v1 same as other features.08:23
yasufumSo, let update docs for users, and continue to fix the codes while updating status of the work on launchpad.08:26
yasufumI have to update the priority on launchpad as "low" first :)08:27
yasufummove on to the next topic.08:27
yasufum#topic About CLI support for paging08:28
yasufumhirofumi-noguchi: can you start?08:28
hirofumi-noguchiMy topic is about paging function.08:28
hirofumi-noguchiIn Zed PTG, we have discussed the implementation of tacker-client related to paging.08:29
hirofumi-noguchiI share information and my opinion related to the paging implementation.08:29
hirofumi-noguchiThere is a difference between v1API and v2API. v2API does not support "all_records" option from the viewpoint of preventing unpredictable high-load DB access.08:30
hirofumi-noguchiEven if "all_records" is included in the query parameter of the API request, v2API ignores it and does not return an error, but it is unfriendly to the user.08:31
hirofumi-noguchiTherefore, tacker-client should return errors when both all_records and --os-tacker-api-version 2 are specified.08:31
hirofumi-noguchiThis is my supplementary information and opinions regarding future implementation of tacker-client.08:33
hirofumi-noguchiThat’s all from my side.08:33
yasufumtakahashi-tsc: You must be interested in this topic.08:34
yasufumwhat do you think?08:34
takahashi-tscYes... and first, I agree with hirofumi's policy. But 1 question, is it OK that v2API ignores all_records?08:35
hirofumi-noguchiI think we need to discuss it.08:36
takahashi-tscDoes "ignores" mean API user cannot know whether "all_records" work or not, right?08:37
hirofumi-noguchiYes, tacker's process does not handle the parameter.08:37
takahashi-tscHmm... honestly I'm not sure it is correct or not from REST API design practices. But it is unfiriendly to the API user.08:40
takahashi-tscAnyway, I agree with your direction of CLI.08:42
hirofumi-noguchiI got it. Do you think query parameters should be validated in tacker-server?08:43
takahashi-tscIt seems better, but I'm not sure server should reply error. 08:48
takahashi-tsc(So now I'm confirming definition of response codes ofHTTP...)08:49
yasufumWe don't have so much time for the topic actually. We can discuss it on the next meeting or tacker's channel.08:49
yasufumWhat do you think?08:49
takahashi-tscAgree, and if possible, we want team to confirm standard http behavior.08:50
yasufumhirofumi-noguchi: enough for today?08:51
hirofumi-noguchiI also agree with yasufum and I have no more topic.08:51
yasufumLet move on to the next one.08:52
yasufum#topic About "Support HA-cluster (hirofumi-noguchi)" 08:52
yasufumgo ahead please08:52
ma-ooyamaAfter the previous PTG, we discussed  the topic in our team, and summarized our opinion here.08:53
ma-ooyamaThe point is below:08:53
ma-ooyama- We think clustering Tacker as 3 active is better way.08:53
ma-ooyama- We are using NFS to replicate files in our cluster but it has some problems. So we think using object storage is better way because of its consistency and durability.08:54
ma-ooyamaPlease refer to the document above and give me some comments if you have.08:54
yasufumDo you have any comment, everyone?08:56
hirofumi-noguchima-ooyama: Thank you very much for sharing the detailed information. I can use it as a reference for our HA design.08:59
ma-ooyamaThank you.09:00
ma-ooyamaYou can ask me if you have any question.09:02
yasufumIs it enough for the topic?09:04
yasufumCan we go to the next topic?09:05
yasufum#topic About "v1 API Refactoring (h-asahina)"09:06
ma-ooyamaWe also think current v1 API has some problems, but when it comes to refactoring it, we think there are some concerns.09:06
ma-ooyamaThe first is about impact on exist VNFs.09:06
ma-ooyamaOperators are using VNFs deployed by current v1 API in thier commecial environment, so the refactoring must not affect those VNFs.09:06
ma-ooyamaAnd how to migrate to new v1 API should also be considered.09:07
ma-ooyamaThe second is about impact on interface.09:07
ma-ooyamaThe interface should never be changed through refactoring, because operators have already been using current v1 API in their commercial environment. 09:07
ma-ooyamaAnd how to coexist both new and old API should also be considered because it can affect the current v1 interface09:08
ma-ooyamaThis is all from my side.09:09
h_asahinaThank you for your comment. For the first point, i.e., impact on existing VNF, I thinnk we should re-instantiate them with v2 API someday.09:11
h_asahinaWe can leave the current v1 API until the most users finish the re-instantiation.09:12
h_asahinaI can say the same thing for the second point, i.e., Impact on interface.09:12
h_asahinaWhen the users upgrade Tacker, they have to consider the re-instantiation and updating the documents, but until then, we can leave the current v1 API.09:14
h_asahinaDo you have other options? may be I missed some points. ma-ooyama:09:15
ma-ooyamaThank you for your comments.09:16
ma-ooyamaIf so, we will use v1 API until it is deprecated.09:20
h_asahinaAfter hearing your comment, I think that might be the only thing we can do.09:21
ma-ooyamaWe want a new v1 API that has no affect to current VNFs, which we are operating.09:22
h_asahinaI see09:22
h_asahinaI can't guarantee it's possible, but basically VNFM just manage LCM of VNF, so I wonder there is possibility to upgrade only VNFM without re-instantiation.09:23
h_asahinaDo you all have any idea? I feel it's difficult, but can we try?09:24
h_asahinaAt least, we can try it experimentaly, i.e., trying manage VNF created by v1 API with v2 API, and clarify the probelems.09:26
h_asahinabut, my concern is is that enough for users?09:27
yasufumIt should be difficult in general, but it should be helpful ma-ooyama suggests us any restrictions or requirements for.09:27
ma-ooyamaAt least I think operators can't re-instantiate all VNFs in commercial environments.09:29
h_asahinaHow long is VNF alive?09:29
ma-ooyamaSo we'd better to consider how to migrate without re-instantiation09:30
h_asahinaSorry if I missed it, but why it's so difficult to re-instantiate VNFs? They have EOL, don't they? 09:31
h_asahinaIt's just because you want to use a new v1 API soon?09:32
h_asahinaor any other reasons?09:33
h_asahinaI just want to confirm the all available options for us.09:34
ma-ooyamaBecause the VNFs are on service, re-instantiation has some risks.09:35
yasufumI wondering there are so many difficulties while running your services.09:35
ma-ooyamaBut as you said there is EOL and at this time we must re-instantiate it.09:36
h_asahinaSo, is it correct to think that we have an option that re-instantiating VNFs when they reach EOL?09:39
h_asahinabut, from the end-user perspective, another option that upgrading VNFM without re-instantiation could be a better option, as you said. am I right?09:40
yasufumYou might be right, and we don't have time remained for today ...09:42
yasufumWhy don't you continue the discussion?09:42
yasufumon the next meeting09:42
ma-ooyamayou are right. We have VNFs that should be upgraded online. So the option without re-instatntiation is better.09:43
yasufumi see09:43
h_asahinaI'd like to yasufum:09:43
ma-ooyamaThank you for a lot of comment.09:43
h_asahinathank you too.09:43
h_asahinaplease continuously discuss this topic09:43
yasufumSorry for my fault cannot have enough time to discuss.09:44
yasufumI'd like to start from this topic in the next meeting if you can join, ma-ooyama and h_asahina.09:45
h_asahinaI'll join09:45
ma-ooyamaSure. Sorry for taking lots time.09:45
yasufumSo, let's close this meeting today and reopen it next time. Thanks for joining.09:46
h_asahinathanks, bye09:46
ma-ooyamaThanks bye.09:46
uehathanks, bye09:46
opendevmeetMeeting ended Tue Apr 19 09:47:06 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:47
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-19-08.01.html09:47
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-19-08.01.txt09:47
opendevmeetLog:            https://meetings.opendev.org/meetings/tacker/2022/tacker.2022-04-19-08.01.log.html09:47
yu-kinjothank you, bye09:47
*** dasm|off is now known as dasm13:03
*** dasm is now known as dasm|off17:06

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