14:00:25 #startmeeting smaug 14:00:26 Meeting started Tue Apr 19 14:00:25 2016 UTC and is due to finish in 60 minutes. The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:30 The meeting name has been set to 'smaug' 14:00:34 Hi everyone 14:00:37 hi 14:00:40 hi 14:00:43 hi 14:00:48 hey 14:01:08 hi 14:01:15 hi 14:01:19 gampel is away on holiday. He's collection energy for the summit 14:01:30 *collecting 14:01:36 cool 14:01:55 :) 14:02:13 how much has he collected for now?:) 14:02:13 Is everyone here? 14:03:06 yes 14:03:09 good 14:03:23 #topic OpenStack Summit 14:03:29 Summit is next week 14:04:01 I'm working on a presentation for the vbrownbag. We get 15 minutes. 14:04:16 I'll send everyone a copy of it later today so you can comment. 14:04:25 good 14:04:34 have a good trip! great! 14:04:38 sure 14:04:43 Ok 14:04:44 It's supposed to just introduce Smaug and point out our main advantages 14:05:01 Mainly our pluggable design. And the whole project attitude. 14:05:08 These are the things that set us apart 14:05:34 saggi: eran told us you need a video 14:05:44 We would also like to have some sort of a demo video. xiangxinyong456, did gampel speak with you about it? 14:05:47 yes, I used to be asked what's the difference with project freeze 14:06:06 yeah 14:06:30 yinweimac: I'm also trying to get a hold of the freezer guys to see how we can work together instead of compete. 14:06:38 xiangxinyong456: How is that going? 14:06:52 firstly i will send the video to mailinglist 14:07:44 i plan to record the video tomorrow 14:08:10 but i have no idea about the operation logs 14:08:49 xiangxinyong456: What do you mean? 14:09:48 because the operation logs have something undecided 14:10:23 xiangxinyong456: Well talk about it offline. In either case we might just skip showing it in the video. It's just a short demonstration anyway. 14:10:45 ok. 14:10:57 Now the operation log do not cover the scene portecting immediately without scheduler. 14:10:58 is there another topic about that? 14:11:22 zhonghua-lee: About what? 14:11:33 operation logs 14:11:46 i add it into wiki 14:11:56 saggi: operation logs 14:12:13 no but I'll add one 14:12:14 :) 14:12:32 chenying_: and do you think they should? 14:12:32 Any other comments about summit? 14:13:09 saggi, i will send a video to you tommorrow night 14:13:24 xiangxinyong, great! 14:13:31 by email? 14:13:39 yes 14:13:43 if it fits 14:13:47 ok 14:14:06 or i can upload it to a website 14:14:29 I wish I could attend the summit.:( 14:14:32 yuval: IMO, we should see the progress and status of all operation type from the operation log API . 14:14:52 xiangxinyong, I wouldn't like WIP versions of the video public. So if you upload it anywhere make it private. 14:14:59 chenying_: i agree with you. 14:15:06 #topic operation logs 14:15:06 chenying_: I totally agree. Problem is, there might not be an operation engine running, only a protection service 14:15:15 saggi: ok 14:15:41 checkpoint 14:16:08 The problem with having operation logs without an operation is that the information will have to go in the bank if it's checkpoint related. 14:16:11 all protect action will call create_checkpoint 14:16:23 create_checkpoint rest API 14:16:50 This is problematic as it breaks the CRUD nature of REST 14:17:08 As it is now, information about checkpoint progress is inside the checkpoint. 14:17:20 We can add more information to the checkpoint, like logs. 14:17:31 But this will have different endpoints. 14:18:02 so we can get the progress and status of all operation from checkpoint information? 14:18:26 The point is we can't mix those up. 14:18:42 We want to support the user case of a user never scheduling operations 14:18:56 having it's own management logic somewhere and only using the simple operations. 14:19:04 saggi: but we can not distinguish the direct protect and schedule protect from the checkpoints 14:19:10 This means that the information needs to be part of the entity being created. 14:19:35 It Shouldn't matter how the checkpoint was created for the restore side 14:20:27 The main issue is whether having logs for the checkpoint is really necessary. 14:20:35 We currently provide information about current progress. 14:20:40 saggi: we should see the checkpoint info from the checkpoint page 14:20:45 So there are no logs. 14:21:13 Meaning there is no infiltration about *when* things changed. Just what the status is now. 14:21:30 I want to know if knowing when things changed really makes sense in the context of a checkpoint. 14:21:47 How does cinder\nova do per instance logs 14:21:50 do they even? 14:22:21 sagg: do you mean we only need the restore to show in the operation logs page? 14:22:30 From xinyong's opinion, He want a or several API that can show the progress and status of a operation(protect delete restore) in smaug ui. 14:22:51 We have progress status from the checkpoint already 14:23:19 How does cinder\nova do per instance logs They will not got to a new page, just show the status of the resoure like volume. 14:23:26 When you ask for information about a checkpoint you should get progress information (if it makes sense). 14:23:32 resource 14:24:24 how could we show the delete workflow when we delete a checkpoint? 14:24:59 What do you want to show? 14:25:02 we just show the checkpoint is deleting 14:26:07 so we could change the name "operation logs" to "Restores"? 14:26:09 ? 14:26:10 ? 14:26:14 Un cinder the the progress and status of volume is recorded in the resoure(volume) db table, will not create a new api or db table to record the data log. 14:26:22 In cinder 14:27:06 Operation logs are for the operations. Operation could contain multiple atomic operations. 14:27:15 *atomic actions 14:27:32 So operation logs "link" to object 14:28:09 saggi: i got some confused. 14:28:57 I'll try and do a writeup about how operations relate to other entities and than we'll try and think about how to integrate everything together once we all understand the requirements. 14:28:58 OK? 14:29:18 sure 14:29:48 ok 14:30:01 #topic operation workflow 14:30:15 #topic operation workflow 14:30:30 OK 14:30:37 As you might have seen, I sent a mail to the openstack-dev (tagged smaug) with a suggestion for the restore/protect resource workflow 14:31:49 It basically answer the need for protection plugins to perform work both independently of child resources and other work which depends on child resources 14:33:26 Did everyone read it? 14:33:41 I have seen. I will take some time to read it. 14:33:50 yinweimac? 14:33:55 yes 14:34:08 actually I have a talk with yuval already 14:34:30 I agree to divide sync/paralle tasks 14:35:15 but at the same time, I have a bit concern that it looks complicating to protection plugin developers 14:35:54 Yuval and I were talking about it this morning and identified that the main issue is that TaskFlow doesn't have any support for async tasks. 14:35:55 and I also gave one fs consistency case to yuval, to see how to meet this case in his design 14:36:27 not actually 14:36:32 yinweimac: what is that fs consistency case? 14:36:56 server freeze io before volumes to take snapshot 14:37:48 yinweimac: let me think about it, although that might be an issue with the current workflow patches as well, right? 14:37:57 yes 14:38:14 I think we may need take time to think more about the task flow 14:38:15 ok, so let's take it offline after the meeting 14:38:43 there's a trade off between the complexity and the clear semantics 14:38:44 I suggest that everyone should read the mail and the attached pdf, so we will have more eyes and opinions 14:39:01 #topic open issues 14:39:01 *eyes reading it 14:39:04 but I'm busy with the integration demo 14:39:11 right now 14:39:53 one suggestion is, how about have smaug all services integrated and make them work first? 14:40:15 then we start an enhance iteration? 14:40:32 yinweimac: enhance iteration? 14:40:47 oh 14:40:48 sure 14:41:00 yinweimac: Yes, I understand that the demo is high priority 14:41:06 Open issue: I think that we should share on some tasks site (waffle? trello?) the open tasks that people are working on. I finished working on an issue, only to find out that someone already submitted a patch for the same issue. 14:41:40 We could use trello, dragonflow uses it and they recommend it 14:41:42 i have one patch need to be merged, otherwise the OperationEngine can not run. can everyone take you time to review it. it stays for a long time. thanks. https://review.openstack.org/#/c/282263 14:41:51 hmm, eran used to have epad to assign tasks 14:42:11 Yes,but we found it hard to maintain. 14:42:21 report bug or bp is an explicit way 14:42:46 I agree with yinwei. 14:42:54 I don't mind using bugs. 14:43:10 But that means that everyone needs to open bugs for the tasks they are working on (if no bug exists) 14:43:13 Can record the task using bug or bp. 14:43:21 And tag them as enhancement if they are not actual bugs. 14:43:43 enhancement could be bp? 14:44:18 btw, will the bugs on launch pad be closed automatically if the patch associated with it has been merged? 14:44:19 bp is it's own kind of headache. 14:44:28 yinweimac: They should 14:44:28 yinweimac: I think so 14:44:51 the launchpad bugs/bp system is ok, but I actually think a proper task site is much more convinient 14:45:17 ok, let's have a try with trello 14:45:21 but I don't mind either, as long as we really use it 14:45:49 both will do for me 14:46:16 Do you guys have access to trello from china? 14:46:31 it is ok 14:46:54 we used it in the last year 14:47:35 OK 14:47:46 Any other topics? 14:48:38 Umm 14:48:50 There are some old patches which require some reviews 14:49:13 and some other which are on -1 validation and require work 14:49:41 I have one . When will we start to design and develop the backup and replication plug-in? 14:50:15 We are working on backup now 14:50:17 backup plugin have been developed already 14:50:35 sorry It is snapshot 14:50:39 replication will have to wait after we have regular backup working end-to-end 14:50:46 snapshots as well 14:50:57 I'd very much like to get the simple things done first 14:51:04 Ok 14:51:07 #action (sagg) Prepare document describing logging issue 14:51:25 just so I don't forget 14:51:29 I will open the Trello board and send the link in #openstack-smaug 14:51:30 Thanks saggi. 14:52:04 #action (yuval) open trello board 14:52:23 Any other action items I might have forgot? 14:53:01 Ok, than I think we're done 14:53:01 Thanks everybody 14:53:14 thans 14:53:17 thanks 14:53:17 Thanks 14:53:19 bye 14:53:19 thanks all 14:53:21 thanks, bye 14:53:23 Bye 14:54:04 #endmeeting