08:02:07 <yasufum-o> #startmeeting tacker 08:02:07 <opendevmeet> Meeting started Tue Nov 8 08:02:07 2022 UTC and is due to finish in 60 minutes. The chair is yasufum-o. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:02:07 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:02:07 <opendevmeet> The meeting name has been set to 'tacker' 08:02:23 <yasufum-o> #link https://etherpad.opendev.org/p/tacker-meeting 08:03:45 <yasufum-o> There three items on the etherpad today. 08:04:49 <yasufum-o> But the second one seems we already discussed in the previous meeting. 08:05:17 <yasufum-o> So, two items actually. 08:05:29 <yasufum-o> manpreetk: can you start from your item? 08:05:37 <manpreetk> Sure thanks 08:05:37 <yasufum-o> Thanks for the update. 08:06:24 <yasufum-o> #topic Tacker Bug Triage Discussion 08:06:56 <manpreetk> My topic is regarding Bug Triage. In OpenStack 2023.1 Antelope cycle proposal is to categorise and prioritise bugs with status "New". 08:06:56 <manpreetk> If ee we agree with the proposal then I would like to seek your opinion regarding suggestions shared in etherpad https://etherpad.opendev.org/p/tacker-bugtriage. 08:06:56 <manpreetk> * Action Items 08:06:56 <manpreetk> * Participation and Duration 08:06:56 <manpreetk> * Open Questions 08:09:48 <manpreetk> So "Action item" comprise of how to categorise and prioritise with reference to OpenStack Bug Triage process. 08:10:23 <manpreetk> But how to conduct this Bug Triage activity in Tacker? 08:10:44 <manpreetk> If you guys have any suggestion/feedback/improvement please let me know. 08:12:22 <yasufum-o> thanks 08:13:18 <yasufum-o> any comment? 08:15:04 <manpreetk> Additionally "Open Questions" would also help in categorising and prioritising bugs, need your opinion here as well. 08:15:32 <yasufum-o> Fist of all, we don't have critical issues so much on the launch pad, right? 08:16:00 <manpreetk> Yes 08:17:29 <yasufum-o> I understand one of the main issue on your suggestion is to discard old issues labeled as "New". 08:17:43 <yasufum-o> Is that correct? 08:18:00 <manpreetk> Yes, correct. 08:19:12 <yasufum-o> OK, thanks. 08:20:58 <yasufum-o> I agree with your proposal to treat future bugs will be registered as described on your etherpad. 08:23:27 <yasufum-o> For the existing bugs, espcecially too old ones, I think we don't take care so much. 08:24:20 <yasufum-o> s/don't/shouldn't/ 08:24:36 <yasufum-o> manpreetk: what do you think? 08:24:50 <manpreetk> Agree 08:25:43 <yasufum-o> And I think it's enough to change the status for now. 08:26:20 <yasufum-o> Do you have any idea which status is the most appropriate for that? 08:27:50 <manpreetk> IMO, "Wont fix" looks fine to me, though we need to explain reason in comment. 08:30:10 <yasufum-o> Any other comment, team? I think "Incomplete" or "Opinion" might be also fine. 08:32:50 <yasufum-o> nothing? 08:33:28 <yasufum-o> OK 08:34:35 <yasufum-o> manpreetk: let's fix it to change to "Won't Fix" for now. 08:35:13 <manpreetk> Ok, meanwhile I ll check with other projects their practise for such scenario. 08:35:42 <yasufum-o> sounds good 08:38:23 <manpreetk> Could you please share your valuable opinion for keeping this activity Volunteer basis and schedule (weekly/ bi-weekly/monthly) and how to share triage results? 08:39:41 <yasufum-o> I'm expecting the number of bugs is not so much for our team, bi-weekly is enough for me. 08:39:50 <manpreetk> Ok 08:41:35 <yasufum-o> For the old bugs, should we wait for your update of how other projects treating such a bugs? 08:42:00 <manpreetk> Yes i ll update the etherpad with findings. 08:42:09 <yasufum-o> good 08:42:35 <manpreetk> We can initiate activity from our next IRC meeting. What do you think? 08:42:51 <yasufum-o> agree 08:43:17 <manpreetk> Thank you so much. 08:43:47 <yasufum-o> Thanks for your contribution! 08:44:19 <yasufum-o> move on to the next topic? 08:46:12 <yasufum-o> hiromu: can we skip your item because it was discussed last week? 08:47:48 <yasufum-o> Hmm, he might be off today. 08:48:06 <yasufum-o> ma-ooyama: Are you here? 08:48:17 <ma-ooyama> Yes. 08:48:43 <yasufum-o> Thanks. It's your turn. 08:48:46 <yasufum-o> #topic Introducing issues we want to work on at Antelope 08:48:54 <ma-ooyama> Sure. Thanks. 08:49:08 <ma-ooyama> After the last Operator Hour at PTG, we understood tacker has some issues to continuously discuss. 08:49:27 <ma-ooyama> I know it is better to extract general issues about tacker as soon as possible, but at this time, I'll introduce some specific issues that I want to improve in Antelope. 08:49:49 <ma-ooyama> I'm sorry that I couldn't introduce the issues at last PTG, but I would appreciate it if you allow me to explain the issues. 08:50:32 <ma-ooyama> First issue is about using object storage. 08:50:50 <ma-ooyama> As discussed in operator hour, how to store VNF packages is one of specific points to be discussed. 08:51:18 <ma-ooyama> The better way to store vnf packages should be discussed in community, but at least, functionality of adapting object storage can be one of options for users. 08:51:43 <ma-ooyama> So we would like to work on adding the functionality in the Antelope. 08:51:58 <ma-ooyama> But we couldn't confirm whether tacker has already been able to use object storage or not. So if tacker could, we want to just add the document about how to use object storage. 08:52:49 <ma-ooyama> What do you think about this first proposal? 08:53:54 <yasufum-o> Thanks for your updates for the topic. 08:55:01 <yasufum-o> I don't know about current impl of object storages actually. 08:56:30 <yasufum-o> ueha: Do you have any suggestion for the proposal? 08:57:35 <ueha> Sorry, I don't know about current impl too. 08:57:57 <yasufum-o> ok, thx 08:58:29 <ueha> How difficult does it take to check if block storage can be used? 08:58:53 <ueha> sorry, s/block/object 08:59:17 <ma-ooyama> I think it is not so difficult. 08:59:31 <ma-ooyama> So at least, we must confirm whether tacker could use object storage or not as soon as possible. 09:00:47 <yasufum-o> ma-ooyama: I'm not opposit to your proposal. 09:01:41 <ma-ooyama> Thanks. So we will first confirm current impl. 09:02:14 <ma-ooyama> Then to implement the function or write document. 09:02:25 <ma-ooyama> Is it OK? 09:02:47 <yasufum-o> I'd like to ask you to propose a spec for the feature. 09:04:08 <ma-ooyama> Sure. We will make a spec before implementation. 09:04:45 <yasufum-o> thanks 09:06:02 <ma-ooyama> Thank you for your comments. 09:06:05 <yasufum-o> can we move on to the next topic, improving mgmt driver log? 09:06:11 <ma-ooyama> Sure. 09:06:43 <ma-ooyama> Sorry. Are there any other comments? 09:07:50 <ma-ooyama> So let me explain second topic. 09:08:11 <ma-ooyama> As discussed in operator hour, there were a opinion that the mgmt driver log can be improved. 09:08:26 <ma-ooyama> For example, when vnf configuration using ansible playbook fails, we couldn't know where or how the playbook fails from the messge displayed by vnflcm op show command. 09:08:53 <ma-ooyama> So we want to implement the interface that pass such as ansible's error message to tacker and enable tacker to show the details of error. 09:10:39 <ma-ooyama> What do you think about this? 09:10:59 <yasufum-o> Is it not enough to change output to other than stdout? 09:11:15 <yasufum-o> output to a file, for instance. 09:13:11 <ma-ooyama> I think it is useful if users can see the details by executing command. 09:13:28 <yasufum-o> I've just looking here 09:13:30 <yasufum-o> #link https://docs.ansible.com/ansible/2.9/reference_appendices/logging.html 09:15:10 <yasufum-o> It might be feasuble to change the configuration, although not sure if it doable in tacker. 09:17:02 <ma-ooyama> You think it doesn't need to pass the ansible output to tacker because user can store the log to some files, right? 09:18:25 <yasufum-o> might be yes 09:18:49 <yasufum-o> although I don't udnerstand your exact requirement for the issue. 09:20:00 <yasufum-o> If you want to jsut get whole logs on stdout, I think it's enought to change the output. 09:20:14 <yasufum-o> what do you think? 09:24:49 <ma-ooyama> Do you mean the logs will displayed in stdout after executing lcm command like instatiation? 09:26:44 <yasufum-o> I don't understand the behavior of logging in ansible so much. So we need to have some more survey. 09:27:11 <yasufum-o> I don't have any answer for your question, sorry. 09:27:51 <ma-ooyama> Sorry, our proposal is too abstract. 09:28:48 <ma-ooyama> So is it OK to discuss this based on spec. 09:29:44 <yasufum-o> You don't need to give us a spec if no new feature will be proposed. 09:30:08 <yasufum-o> Please continue us to discuss on the etherpad and chat. 09:31:00 <ma-ooyama> Sure. Thanks. 09:31:41 <ma-ooyama> So we'll add more concrete proposal to ehterpad. 09:31:47 <yasufum-o> thanks 09:32:03 <yasufum-o> It must be so helpful for us. 09:33:10 <yasufum-o> So, lets close this meeting because it's 30 mins over the end of the meeting. 09:33:15 <yasufum-o> If no more comments. 09:33:38 <takahashi-tsc> Nothing from my side. 09:34:22 <yasufum-o> thanks 09:34:47 <yasufum-o> See you next week, bye! 09:34:54 <takahashi-tsc> bye 09:34:57 <ma-ooyama> Thanks, bye. 09:34:58 <manpreetk> Thanks for discussion. Bye! 09:35:00 <ueha> Thanks, bye 09:35:07 <yasufum-o> #endmeeting