09:01:04 #startmeeting karbor 09:01:05 Meeting started Tue Dec 6 09:01:04 2016 UTC and is due to finish in 60 minutes. The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:01:08 The meeting name has been set to 'karbor' 09:01:13 Hi everyone 09:01:35 Hello 09:01:38 hi 09:01:42 hi 09:01:51 hi 09:02:26 yuval is on reserve duty 09:03:11 I submit a irc meeting topic rightnow. 09:03:44 #topic About the operation_logs API 09:03:59 who suggested this? 09:04:09 yes I have a question about status in this API. 09:05:17 ◦state in operation_logs have several values (running/finished/failed) 09:05:32 ◦"finished" means protection restAPI is called successfully or the protection action have been done successfully 09:06:02 finished means that everything was done successfully 09:06:26 this includes all protect\restore\delete requests relating to the operation 09:08:01 ok? 09:08:33 It means that when we start vloume backup, the status in operation_logs finished means the checkpoint is available 09:09:26 yes 09:10:06 When protect\restore\delete action is successful, the status of operation_logs must be updated to finished. 09:10:13 OK I see 09:10:40 saggi: do you think whether we can reuse the table "scheduled_operation_logs"? 09:10:45 https://etherpad.openstack.org/p/operationlogs 09:10:58 reuse for what? 09:11:10 no 09:11:20 since the operation might include multiple actions 09:11:21 reuse "scheduled_operation_logs" table to show operation logs 09:11:31 and it's only finished when all the actions are over 09:12:41 So operation logs are none busineess of scheduledoperation and scheduledoperationlogs? 09:13:00 edisonxiang: I don't understand the question 09:13:38 saggi Does it mean that the operation_logs is inserted into database table in operationengine service, and the status of it is updated in portection service? 09:14:16 or creat new tables to finish this feature? 09:15:12 The Operation Engine needs to track the progress of all the actions it starts. 09:15:12 It needs to mark the result for each run of an operation. 09:15:12 The run is successful only if all actions invoked were successful. 09:16:42 So can we reuse scheduledoperationlogs to record operationlogs? 09:17:32 I might be missing something. What is the difference between scheduledoperationlogs and operationlogs. 09:17:42 saggi xinyong's question is that, Do we use scheduledoperationlogs database table to record thess data, or create a new database table for this api? 09:18:32 saggi: I am confused with the difference between scheduledoperationlogs and operationlogs. 09:19:01 saggi: but now scheduedoperationlogs only record the protect workflow 09:19:42 saggi: perhaps we can take a look at this patch.https://review.openstack.org/#/c/298060/ 09:21:19 edisonxiang: This is the log for the scheduled operations. 09:21:48 saggi: got it 09:22:10 saggi I am clear about this operationlogs API. My question is that when to create/ update these operationlogs data? xinyong's question is that where to save the data about operationlogs? 09:23:42 xinyong plan to get the operationlogs data from scheduledoperationlogs database table, but its status only mean the protect api have been called successfully. 09:24:21 saggi: do you have some ideas what to show in the "operation logs" module of dashboard? 09:25:05 show scheduled operation logs or operation logs? 09:26:22 I am a little confused about this question 09:27:32 https://review.openstack.org/#/c/298060/ The operationlogs API in this patch only cover the protect action, it doesn't include restore\delete action. At present only protect action is invoked by operationengine service. 09:29:13 I don't understand why we even have 2 types of logs. 09:29:30 :) 09:30:26 AFAIK there should only be a log for scheduled operations runs. 09:30:26 When we start a scheduled operation we create a log for it that tracks it's progress. 09:30:31 so do I 09:30:34 What is the other log tracking? 09:31:13 saggi the scheduledoperationlogs database table have introduced to karbor with the implementation of operationengine servie. It is internal. It have not been exposed to user. 09:31:58 chenying, what are they for? 09:33:19 saggi It is used for recording the call log of scheduledoperation. but its status now mean the protect api have been called successfully. 09:36:59 saggi: understood. We will show logs which are created by scheduled operations in the Horizon 09:37:04 OK, the original way we planned on doing it was that whenever an scheduled operation is triggered a log is created. That log status is only changed to 'finish' when the whole operation was finished. Everything was done. Each operation can have entries in it. The entries are simple messages. They could notify the user something like: "Protect started on plan", "Protect finished on plan", "Started searching for old checkpoints" 09:37:42 That way the user can see the stage the operation is at during it's run 09:38:04 The log is like a log file and the entries are log lines 09:38:15 The DB schema needs to reflect that. 09:38:45 yeah 09:39:08 It seems we need to make some changes on the present table stucture 09:39:23 👍 09:39:59 saggi Yes I see. 09:40:04 :P 09:40:37 #topic weekly meeting wiki page 09:41:04 I saw that other projects replace the entire page instead of keeping historic records of the agenda throughout time. 09:41:10 what do you guys think about it 09:41:30 I want to only display the next meeting's agenda and delete the old agendas 09:41:49 how to replace? removement? 09:42:04 Just replace, after each meeting clear the page and change the date. 09:43:13 saggi: Agree with you 09:43:14 +1 09:43:21 +1 09:43:28 +1 09:43:38 Than it's agreed. 09:43:59 we can delete the old agendas 09:44:01 I think it's better. Now you need to scroll the page to see the agenda 09:44:05 I'll do it now 09:44:14 Thanks saggi 09:45:09 #topic open discussion 09:45:21 I saw zengchen gave a +1 on https://review.openstack.org/#/c/397156/ 09:45:31 chenying if you give a +2 we can merge the spec 09:45:49 So please see that you agree with it or give comments 09:46:31 saggi I don't have any comments about yuval's plugins specs. I have +1 already. 09:47:16 But there are some more work to be considered about the implementations patch. I give some comments about it. 09:47:17 chenying, sorry it was deleted because of an update 09:47:36 chenying, good. Your feedback is much appreciated 09:47:57 Ok I see. I will review the spec later. 09:48:36 Anything else? 09:48:41 by the way, https://review.openstack.org/#/c/403965/ 09:49:05 about this patch, it seems like yizhihui has some questions 09:49:49 karbor/services/protection/protectable_plugins/eisoo/oracle.py About the eisoo client module, I think it belong to the vendors's code, it a part of vendor plugins implementation. It could be moved to the directory of vendor plugins. What's your opinion about it? 09:50:42 chenying, you mean like `karbor/services/protection/protectable_plugins/vendor/eisoo/oracle.py` ? 09:52:07 My question is about vendor's client implementation. Put it to where? 09:52:47 chenying_, what's your suggestion? 09:53:01 You mean protectable implementation? 09:53:32 The actual client needs to be a dependency not in out codebase like cinder-client 09:53:56 I give a comment about the Directory of vendor's client implementation in this patch. https://review.openstack.org/#/c/403965/ 09:54:27 I think the present code structure is very good. "karbor/services/protection/clients/eisoo.py" 09:55:08 chenying_, do you mean the karbor.services.protection.clents should be move out of framework folder into vendor folder? 09:55:18 The vendor's protectable and protection plugins both need use vendor's client. So my question is that put it to where? 09:55:24 s/move/moved 09:55:34 vendor's client implementation. 09:56:09 ok, the model 09:56:39 chenying, I understand. Why should we put it in a different folder? 09:57:26 /karbor/services/protection/clients/ is OK with me 09:57:37 saggi IMO, the client is part of plugins implementation. 09:58:17 saggi: +1 09:58:29 chenying what do you suggest? 09:58:29 saggi, +1 09:58:29 +1 09:58:34 +1 10:01:40 :) 10:01:47 #endmeeting karbor\