08:02:37 <yasufum> #startmeeting tacker 08:02:37 <opendevmeet> Meeting started Tue Nov 15 08:02:37 2022 UTC and is due to finish in 60 minutes. The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:02:37 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:02:37 <opendevmeet> The meeting name has been set to 'tacker' 08:03:11 <yasufum> #link https://etherpad.opendev.org/p/tacker-meeting 08:03:39 <hiromu> hi 08:03:44 <k_fukaya> hi 08:04:32 <yuta-kazato> hi 08:04:40 <yasufum> It seems both of items on the etherpad have some updates. 08:05:12 <yasufum> manpreetk: can you start from your item? 08:05:13 <manpreetk> Yes sure 08:05:28 <manpreetk> This is just update 08:06:40 <manpreetk> from last week discussion, regarding EOL branch, I have seek Ghanshyam san's feedback, he agrees to our suggestion and just added pointer to recreate bug in master branch. 08:08:35 <manpreetk> Thats all from my side. Thanks !! Please let me know your opinion. Shall we proceed with share discussion or if anyone has any other suggestion/feedback. 08:11:05 <yasufum> Considering the feedback comments, we don't need to do anything and without changing status, correct? 08:11:42 <yasufum> Just waiting a request to fix in the latest master if it's asked. 08:11:56 <manpreetk> Yes 08:13:11 <yasufum> Do you have any update for which status is the most appropriate? 08:13:36 <manpreetk> Seems he is ok with suggested one "wont fix". 08:14:19 <yasufum> thanks 08:14:42 <yasufum> I also agree to your suggestion. 08:15:24 <manpreetk> Thank you!! I would like to proceed with this activity. Hope thats fine with the team? 08:15:35 <yasufum> So, we can fix this item if everyone agree to the suggestion. 08:18:12 <yasufum> OK, good 08:18:21 <takahashi-tsc> I agree, seems good 08:18:25 <yasufum> thanks 08:18:26 <ueha> +1 08:19:17 <yasufum> manpreetk: can you change the status by your self, or do I need to? 08:19:29 <yasufum> I'm not sure it's allowed on your account. 08:19:44 <manpreetk> I guess i can, but in case i face any issue i'll inform you. 08:20:01 <manpreetk> Ok i ll see, and let you know. 08:20:13 <yasufum> got it 08:20:16 <yasufum> thaks 08:20:30 <yasufum> So, let's move on to the next item. 08:20:58 <yasufum> ma-ooyama: can you share your update? 08:21:20 <ma-ooyama> Sure, we have some updates about the topic of improving mgmt driver log. 08:21:43 <ma-ooyama> we got some comments last IRC, for example "Is it not enough to change output to other than stdout?", because of less explanation about why we want to work on this issues. 08:22:00 <ma-ooyama> So today I would like to explain the points. 08:22:28 <ma-ooyama> As a premise, we think the error message of configuration failure displayed by CLI command in current tacker is a little simple. 08:22:51 <ma-ooyama> For administrator of tacker, this doesn't matter because they can check the logs at tacker server and investiage the errors. 08:23:13 <ma-ooyama> But for users, they can't log in to the tacker server in general, and so there are no way for users to debug the error themselves. 08:23:42 <ma-ooyama> I think it is useful for users if they can see the details of error and revice their playbook themselves. 08:23:59 <ma-ooyama> so we want to include the error message in the result of vnflcm commands because CLI is the main interface between tacker and users. 08:25:18 <ma-ooyama> This is why we want to work on this issue. I would like to hear your opinions. 08:26:25 <yasufum> thanks 08:26:31 <yasufum> Any comment? 08:28:05 <yasufum> I'm not still sure who is the user who should get the log? 08:28:50 <yasufum> other than administrator 08:29:19 <ma-ooyama> I mean users is api consumer of tacker who want to deploy their VNFs using tacker. 08:30:12 <ma-ooyama> and administrator is who manage tacker itself. 08:31:23 <ma-ooyama> Administrator can see the logs on tacker server, and users can't, I mean. 08:35:22 <yasufum> The user cannot ask to get the log to admin, right? 08:37:40 <ma-ooyama> They can ask the log to admin, but it takes some times. 08:41:20 <yasufum> I don't opposite to your requirement to enable users to get the log 08:41:49 <yasufum> but not sure how to do so. 08:41:55 <yasufum> CLI is the best way? 08:42:21 <yasufum> s/CLI/vnflcm command/ 08:44:16 <yasufum> any comment, team? 08:47:37 <yasufum> ueha: do you have any comment? 08:48:13 <ueha> umm.. IMO, the MgmtDriver is custom implementable by the user. So if user want to change the log, user can do so. 08:48:26 <ueha> I think user can just put the information that want to see in Exception. 08:49:13 <ueha> For example, the object update of opocc in case of instantiate error seems to be done below codes. 08:49:22 <ueha> v1: https://opendev.org/openstack/tacker/src/branch/master/tacker/conductor/conductor_server.py#L2056-L2065 08:49:30 <ueha> v2: https://opendev.org/openstack/tacker/src/branch/master/tacker/sol_refactored/conductor/conductor_v2.py#L190-L194 08:51:12 <ma-ooyama> Sorry, to supplement of my proposal, I mean I want to include the information of how or where the playbooks fais but whole logs. 08:52:57 <ueha> Is that information that cannot be included in the Exception? 08:53:40 <ueha> I don't fully understand the implementation of MgmtDriver, so I'm sorry if I said something strange. 08:55:27 <ma-ooyama> Sorry, I also don't know details. 08:55:33 <ma-ooyama> I understand you mean what we want to do is already impemented , right? 08:56:23 <ma-ooyama> Developer of mgmt driver can customize what log is passed to exception. 08:56:59 <ma-ooyama> s/log/information/ 08:57:50 <ueha> Yes, I think it might so. user can customize in python codes. 08:57:59 <takahashi-tsc> Sorry for interrupt.ueha, you mean that user can pass the information freely with "implementation of MgmtDriver" and "checking the content of occ notification". right? 08:59:02 <takahashi-tsc> User can write code to raise Exception with any information because MgmtDriver is implemented by user, and notification includes context of such Exception. 08:59:56 <ueha> Thanks, takahashi-san, I think so in my understand. 09:02:57 <ma-ooyama> Thank you ueha-san and takahashi-san. If so, it is just what I said I want to do. 09:05:00 <takahashi-tsc> Hmm, if it is correct, user can already get log from stdout with current Tacker. The assumption is LCM consumer can see notification context (I think it seems correct). Another discussion point is how easy user want to see such log. 09:06:32 <takahashi-tsc> I would like to hear ma-ooyama's opinion on these discussions. Especially "how easy" is needed 09:09:35 <yasufum> ma-ooyama: Can you give us a list of items what user should get for the purpose? 09:10:18 <yasufum> Anyway, I think we don't have enough time for today becaues we have another item on the etherpad from ueha. 09:11:03 <ma-ooyama> Sorry, so please continue to discuss this next IRC. 09:11:14 <ma-ooyama> Sorry for taking much time.. 09:12:09 <yasufum> I'd like to ask you again to propose a spec to describe what should be done for getting log from usres. 09:12:19 <yasufum> Anyway, thanks for your suggestion! 09:12:45 <yasufum> So, let's move on to the last item. 09:13:35 <ueha> Ok, I will start my topic. 09:13:50 <ueha> I added the topic about Legacy API deprecation that I suggested in antelope vPTG. 09:14:16 <ueha> I created etherpad and listed Legacy APIs that are to make deprecated. 09:14:19 <ueha> https://etherpad.opendev.org/p/tacker-legacy-deprecation 09:14:31 <ueha> I also create BluePrint for this topic. 09:14:43 <ueha> https://blueprints.launchpad.net/tacker/+spec/deprecate-legacy-apis 09:15:24 <ueha> Once we reach an agreement within the team, I will start to announce to disscussML and investigate how to mark deprecate API. 09:16:01 <ueha> I'm going to investigate now, but please tell me if anyone has any information. 09:16:17 <ueha> That's all from my side. 09:16:45 <yasufum> thanks 09:17:24 <ueha> I don't have much time today, so please check it and write a comment on the etherpad if you have. 09:17:57 <yasufum> Or start again from your item in the next meeting. 09:18:32 <yasufum> Is there any comment for the item for now? 09:18:39 <yuta-kazato> Thanks, ueha-san. I have one question related to your proposal,, so I will write my comment on the etherpad! 09:19:21 <ueha> Thank you, kazato-san! 09:20:14 <ueha> I will check etherpad. Let's disscuss in the next IRC. 09:21:01 <yasufum> thx 09:21:19 <yasufum> Any other comment, or close this meeting? 09:21:55 <yasufum> good 09:22:06 <yasufum> Thank you for joining, bye! 09:22:09 <manpreetk> Thanks, Bye!! 09:22:14 <takahashi-tsc> bye 09:22:20 <ma-ooyama> thanks, bye. 09:22:21 <ueha> Thanks, bye 09:22:23 <yuta-kazato> bye 09:22:33 <yasufum> #endmeeting