08:01:27 <yasufum> #startmeeting tacker
08:01:27 <opendevmeet> Meeting 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:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:27 <opendevmeet> The meeting name has been set to 'tacker'
08:03:52 <yasufum> First of all, can you tell me which items are going to be discussed today :)
08:04:19 <masaki-ueno> My one is for today's discussion
08:04:23 <yasufum> All of them without noted as "no update"?
08:05:18 <ma-ooyama> I have three topics today.
08:05:19 <yasufum> How about yours, hirofumi-noguchi and ma-ooyama?
08:05:48 <yasufum> ma-ooyama: thanks
08:06:01 <hirofumi-noguchi> My one is also today's discussion.
08:06:44 <yasufum> OK, thanks. It's all clear.
08:07:07 <yasufum> #topic About Bugs in CreateVnfRequest Procedure and Default VIM
08:07:20 <yasufum> masaki-ueno: can you start from your item?
08:07:25 <masaki-ueno> sure
08:08:24 <masaki-ueno> As you may know, bugs in CreateVnfRequest is reported on launchpad
08:08:32 <masaki-ueno> #link https://bugs.launchpad.net/tacker/+bug/1968680
08:09:15 <masaki-ueno> CreateVnfRequest fails if there's no default VIM in TackerDB, and I confirmed it in my environment.
08:09:56 <masaki-ueno> Also, I confirmed the proposed workaround in the bugreport works
08:10:23 <masaki-ueno> but I also noticed the bugs in the procedure
08:10:55 <masaki-ueno> CreateVnfRequest needs at least one default VIM, but it works regardless of its VIM type
08:11:26 <masaki-ueno> I mean, CreateVnfRequest for CNF works even if the default VIM is OpenStack....
08:11:46 <masaki-ueno> The behavior comes from the code:
08:11:55 <masaki-ueno> #link https://opendev.org/openstack/tacker/src/branch/master/tacker/api/vnflcm/v1/controller.py#L470
08:12:14 <masaki-ueno> And the reason why default VIM is needed in the procedure is here
08:12:20 <masaki-ueno> #link https://github.com/openstack/tacker/blob/master/tacker/api/vnflcm/v1/controller.py#L387-L397
08:12:55 <masaki-ueno> As described in SOL002, CreateVnfRequest is a procedure for creating the base of VNF instances, so VIM information is not needed here.
08:13:05 <masaki-ueno> Sorry, not SOL002 but 003
08:13:53 <masaki-ueno> The above implementation requires VIM information at CreateVnfReq, so it is a mismatch between implementation and specification.
08:14:46 <masaki-ueno> I'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:15:15 <masaki-ueno> That's all for my topic.
08:16:01 <yasufum> thanks
08:16:07 <masaki-ueno> Note that the author of bugreport has already uploaded patch that fixes user docs
08:16:12 <masaki-ueno> :)
08:16:46 <yasufum> In my opinion, fixing docs is reasonable as a quick fix.
08:17:23 <masaki-ueno> Yes, I agree with you > yasufum. I will check the fixed part of docs later.
08:19:08 <yasufum> For another topic, fix codes itself, I think it should also be fixed although it will be deprecated.
08:19:53 <yasufum> Because we've not made any agreement for the date of the deprecation.
08:22:19 <yasufum> I think we don't need to maintain actively, adding new feature or so in other words, but should keep it run well.
08:22:37 <yasufum> Any other opinion for the bug?
08:23:18 <masaki-ueno> I see. But we may have to carefully investigate codes depends on this implementation in advance, and I haven't done it yet...
08:23:34 <takahashi-tsc> Agree with yasufum, no need to make high priority, but need to fix bugs in v1 same as other features.
08:25:10 <yasufum> Thanks.
08:26:48 <yasufum> So, let update docs for users, and continue to fix the codes while updating status of the work on launchpad.
08:27:13 <masaki-ueno> +1
08:27:31 <yasufum> I have to update the priority on launchpad as "low" first :)
08:27:57 <yasufum> move on to the next topic.
08:28:11 <yasufum> #topic About CLI support for paging
08:28:30 <yasufum> hirofumi-noguchi: can you start?
08:28:35 <hirofumi-noguchi> Sure
08:28:50 <hirofumi-noguchi> My topic is about paging function.
08:29:10 <hirofumi-noguchi> In Zed PTG, we have discussed the implementation of tacker-client related to paging.
08:29:46 <hirofumi-noguchi> I share information and my opinion related to the paging implementation.
08:30:21 <hirofumi-noguchi> There 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:31:11 <hirofumi-noguchi> Even 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:56 <hirofumi-noguchi> Therefore, tacker-client should return errors when both all_records and --os-tacker-api-version 2 are specified.
08:33:12 <hirofumi-noguchi> This is my supplementary information and opinions regarding future implementation of tacker-client.
08:33:23 <hirofumi-noguchi> That’s all from my side.
08:33:42 <yasufum> thanks
08:34:17 <yasufum> takahashi-tsc: You must be interested in this topic.
08:34:57 <yasufum> what do you think?
08:35:37 <takahashi-tsc> Yes... and first, I agree with hirofumi's policy. But 1 question, is it OK that v2API ignores all_records?
08:36:15 <hirofumi-noguchi> I think we need to discuss it.
08:37:10 <takahashi-tsc> Does "ignores" mean API user cannot know whether "all_records" work or not, right?
08:37:44 <hirofumi-noguchi> Yes, tacker's process does not handle the parameter.
08:40:50 <takahashi-tsc> Hmm... honestly I'm not sure it is correct or not from REST API design practices. But it is unfiriendly to the API user.
08:42:13 <takahashi-tsc> Anyway, I agree with your direction of CLI.
08:43:14 <hirofumi-noguchi> I got it. Do you think query parameters should be validated in tacker-server?
08:47:56 <yasufum> opinion?
08:48:31 <takahashi-tsc> It seems better, but I'm not sure server should reply error.
08:48:50 <yasufum> umm
08:49:07 <takahashi-tsc> (So now I'm confirming definition of response codes ofHTTP...)
08:49:50 <yasufum> We don't have so much time for the topic actually. We can discuss it on the next meeting or tacker's channel.
08:49:54 <yasufum> What do you think?
08:50:12 <takahashi-tsc> Agree, and if possible, we want team to confirm standard http behavior.
08:50:24 <yasufum> good
08:51:00 <yasufum> hirofumi-noguchi: enough for today?
08:51:34 <hirofumi-noguchi> I also agree with yasufum and I have no more topic.
08:51:51 <yasufum> thanks
08:52:08 <yasufum> Let move on to the next one.
08:52:15 <yasufum> #topic About "Support HA-cluster (hirofumi-noguchi)"
08:52:39 <ma-ooyama> Sure
08:52:57 <yasufum> go ahead please
08:53:13 <ma-ooyama> After the previous PTG, we discussed  the topic in our team, and summarized our opinion here.
08:53:22 <ma-ooyama> https://docs.google.com/presentation/d/1tyMhbx_Qd5hwuYuOMQ9m-MGNNB9szUs1ypAklPKzOII/edit#slide=id.g121ca8da322_1_74
08:53:35 <ma-ooyama> The point is below:
08:53:51 <ma-ooyama> - We think clustering Tacker as 3 active is better way.
08:54:07 <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:42 <ma-ooyama> Please refer to the document above and give me some comments if you have.
08:56:41 <yasufum> thanks
08:56:53 <yasufum> Do you have any comment, everyone?
08:59:01 <hirofumi-noguchi> ma-ooyama: Thank you very much for sharing the detailed information. I can use it as a reference for our HA design.
09:00:04 <ma-ooyama> Thank you.
09:02:03 <ma-ooyama> You can ask me if you have any question.
09:04:16 <yasufum> Is it enough for the topic?
09:04:39 <ma-ooyama> Yes.
09:05:27 <yasufum> Can we go to the next topic?
09:06:04 <yasufum> #topic About "v1 API Refactoring (h-asahina)"
09:06:11 <ma-ooyama> Sure
09:06:27 <ma-ooyama> We also think current v1 API has some problems, but when it comes to refactoring it, we think there are some concerns.
09:06:43 <ma-ooyama> The first is about impact on exist VNFs.
09:06:58 <ma-ooyama> Operators are using VNFs deployed by current v1 API in thier commecial environment, so the refactoring must not affect those VNFs.
09:07:19 <ma-ooyama> And how to migrate to new v1 API should also be considered.
09:07:38 <ma-ooyama> The second is about impact on interface.
09:07:58 <ma-ooyama> The interface should never be changed through refactoring, because operators have already been using current v1 API in their commercial environment.
09:08:51 <ma-ooyama> And how to coexist both new and old API should also be considered because it can affect the current v1 interface
09:09:58 <ma-ooyama> This is all from my side.
09:10:27 <yasufum> thanks
09:11:03 <h_asahina> Thank 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:12:29 <h_asahina> We can leave the current v1 API until the most users finish the re-instantiation.
09:12:54 <h_asahina> I can say the same thing for the second point, i.e., Impact on interface.
09:14:26 <h_asahina> When 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:15:43 <h_asahina> Do you have other options? may be I missed some points. ma-ooyama:
09:16:23 <ma-ooyama> Thank you for your comments.
09:20:09 <ma-ooyama> If so, we will use v1 API until it is deprecated.
09:21:45 <h_asahina> After hearing your comment, I think that might be the only thing we can do.
09:22:15 <ma-ooyama> We want a new v1 API that has no affect to current VNFs, which we are operating.
09:22:36 <h_asahina> I see
09:23:51 <h_asahina> I 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:24:21 <h_asahina> Do you all have any idea? I feel it's difficult, but can we try?
09:26:52 <h_asahina> At least, we can try it experimentaly, i.e., trying manage VNF created by v1 API with v2 API, and clarify the probelems.
09:27:45 <h_asahina> but, my concern is is that enough for users?
09:27:58 <yasufum> It should be difficult in general, but it should be helpful ma-ooyama suggests us any restrictions or requirements for.
09:29:02 <ma-ooyama> At least I think operators can't re-instantiate all VNFs in commercial environments.
09:29:58 <h_asahina> How long is VNF alive?
09:30:21 <ma-ooyama> So we'd better to consider how to migrate without re-instantiation
09:31:49 <h_asahina> Sorry if I missed it, but why it's so difficult to re-instantiate VNFs? They have EOL, don't they?
09:32:34 <h_asahina> It's just because you want to use a new v1 API soon?
09:33:38 <h_asahina> or any other reasons?
09:34:24 <h_asahina> I just want to confirm the all available options for us.
09:35:46 <ma-ooyama> Because the VNFs are on service, re-instantiation has some risks.
09:35:59 <yasufum> I wondering there are so many difficulties while running your services.
09:36:14 <ma-ooyama> But as you said there is EOL and at this time we must re-instantiate it.
09:39:35 <h_asahina> So, is it correct to think that we have an option that re-instantiating VNFs when they reach EOL?
09:40:53 <h_asahina> but, 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:42:21 <yasufum> You might be right, and we don't have time remained for today ...
09:42:34 <h_asahina> agree
09:42:51 <yasufum> Why don't you continue the discussion?
09:42:58 <yasufum> on the next meeting
09:43:04 <ma-ooyama> you are right. We have VNFs that should be upgraded online. So the option without re-instatntiation is better.
09:43:16 <yasufum> i see
09:43:27 <h_asahina> I'd like to yasufum:
09:43:32 <ma-ooyama> Thank you for a lot of comment.
09:43:40 <h_asahina> thank you too.
09:43:59 <h_asahina> please continuously discuss this topic
09:44:18 <yasufum> Sorry for my fault cannot have enough time to discuss.
09:45:22 <yasufum> I'd like to start from this topic in the next meeting if you can join, ma-ooyama and h_asahina.
09:45:38 <h_asahina> I'll join
09:45:43 <ma-ooyama> Sure. Sorry for taking lots time.
09:45:51 <yasufum> thanks
09:46:46 <yasufum> So, let's close this meeting today and reopen it next time. Thanks for joining.
09:46:48 <yasufum> bye!
09:46:53 <masaki-ueno> bye
09:46:54 <h_asahina> thanks, bye
09:46:56 <ma-ooyama> Thanks bye.
09:46:56 <manpreetk> Bye
09:46:57 <takahashi-tsc> bye
09:46:58 <ueha> thanks, bye
09:46:58 <caishuwen> bye
09:46:58 <Ramona-ho-xu> bye
09:47:06 <yasufum> #endmeeting