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