13:59:28 #startmeeting Smaug Biweekly 13:59:29 Meeting started Tue Jan 12 13:59:28 2016 UTC and is due to finish in 60 minutes. The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:59:33 The meeting name has been set to 'smaug_biweekly' 14:00:06 #topic roll call 14:00:16 Hi 14:00:16 Hi everyone 14:00:20 hi 14:00:26 o 14:00:54 gampel is mid-flight so he will be missing this meeting 14:01:04 are we waiting for anyone? 14:01:10 Yinwei? 14:01:19 Let's begin? 14:01:33 is there any topic related yinwei? 14:01:54 Protection Service tasks 14:02:22 Talk other topics first 14:02:25 o/ 14:02:26 sure 14:02:28 the first one? 14:02:38 #topic API, Last call for comments 14:02:52 So I want to finalize the API soon 14:03:17 There are some put methods to add. 14:03:18 is it the last version now? 14:03:35 Please see Eran's comment. 14:03:47 No, I have some minor comments from gampel. 14:04:27 But I hope it's the last iteration 14:05:03 smcginnis, I don't know if you are here but I would appreciate you giving it a second look. 14:05:16 saggi: I will try to do that later today. 14:05:21 thanks 14:05:41 saggi: No problem. I'm travelling, so I might not get to it right away. 14:05:48 But it's on my list now. :) 14:05:50 smcginnis: Thanks. 14:06:17 So if people have any questions or comments please post them. Even if you don't understand something. It's very important as changing APIs is hard. 14:06:32 sure 14:06:44 saggi: Very true! 14:07:02 I see 14:07:32 Next topic? 14:07:48 API service 14:07:53 Api resource controller design is in progress. 14:08:02 #topic API Service 14:08:10 I plan to do api service design and resource controller development. 14:08:43 chenying_: wo can work together 14:08:52 chenying_: please coordinate with yinwei about serializers and other integration between the API and the protection service. 14:09:07 Ok 14:09:58 I see some stuff that appear to be duplicate effort between you two 14:10:33 saggi: you mean chenying_ and yinwei? 14:10:39 yes 14:10:54 Stuff that could be moved to common code between the services 14:11:04 chenying_: All in all you are doing a good job 14:11:16 chenying_: Is there anything you need from anyone else? 14:11:38 She has explained that serializers in manager is for bankplugin. 14:12:53 I understand. Than we might need something that will also work for the plugins. I will think about it. 14:13:18 I will coordinate with yinwei about it. 14:13:41 Good, you will need to coordinate the schema transfer and other information from the checkpoint. 14:14:05 Should we move to Pluggable Proection Provider Q/A 14:14:22 yes 14:14:44 #topic Pluggable Proection Provider Questions and Answers 14:15:00 I posted the design doc about the pluggable protection provider. 14:15:22 This will be the reference implementation and recommended way to extend Smaug. 14:15:47 For cases where you need small modifications to the existing backup. 14:15:59 Are there any questions about the design? 14:16:10 Continue the discussion this afternoon. create_checkpoint needs to add a checkpoint info parameter? 14:16:26 right? 14:16:55 create_checkpoints get's a checkpoint info 14:17:04 In the post request 14:17:30 But there gotta be a way to pass this info. 14:17:44 zengyingzhe: I don't understand the question. 14:17:44 to create_checkpoint() 14:18:38 Let 14:18:49 zengyingzhe: Oh 14:18:57 Let's talk this latter 14:18:57 Now I understand what you are talking about 14:19:17 saggi, yes? 14:19:23 zengyingzhe: You are correct I need to change this in the diagram. 14:19:38 zengyingzhe: I kept thinking you are talking about the API diagram. 14:19:47 Completely my mistake. 14:19:52 I'm very sorry 14:19:57 I will fix it 14:20:36 :) Don't be sorry. I explained it unclearly 14:21:09 So please everyone, make sure you understand it. It's going to be the heart of Smaug so your comments are very important. 14:21:52 Yinwei, and zengyingzhe are already doing a good job finding my mistakes :) 14:22:17 And another one. I see create_checkpoint() is for protect operation, does there need other interfaces for restore or enable? 14:22:49 zengyingzhe: Yes, it's missing. I thought I already did that but I guess I didn't. 14:23:12 saggi, thanks. 14:23:22 Should we move to protection Service tasks 14:23:48 ? 14:23:59 yinwei 14:25:18 We'll start without her 14:25:34 #topic Protection Service tasks 14:25:34 it seems she is not here 14:25:55 I've added tasks to the etherpad https://etherpad.openstack.org/p/smaug-bootsrap 14:26:23 what's this topic about? 14:26:28 This are things that we are more or less closed on how we want to do them 14:26:58 So if you have time to do some coding. You should pick something from the list. 14:27:36 can we move to operationengine? 14:27:39 The Protectables are low handing fruit as you can make a small tool and just make sure you can query openstack etc 14:28:03 #topic Operation Engine design status\ 14:28:09 #topic Operation Engine design status 14:28:22 today, I have finished the coding and simple tests of TimeTrigger. I will submit it this week. next, I will modify the design of OperationEngine, and finish the remaining coding. 14:28:32 one question. according to the discussing with saggi, OperationEngine need to track the operation. does it mean some operations like delete operation need finish its logic when executing it. 14:29:34 Delete is simple as it just means to mark the checkpoint as deleted. Another pass will actually free all the resources asynchronously. 14:29:56 This is because we want to assume atomic deletes. 14:30:04 s/assume/assure 14:30:32 yes, i aggree. 14:31:16 so, we need to encapsulate the logic into the operation class, right? 14:31:35 What logic? 14:32:12 The actual deletion pass, or GC (Garbage Collection) pass is done in Smaug independently from the operation. 14:32:21 the operation 14:33:13 So the operation just needs to make sure it maked all the required checkpoints as deleted. This should be in the operation. For example if we need to mark 10 checkpoints and we crashed after the 5th we need to continue once we restart. 14:33:59 ok, understand. 14:34:30 When creating multiple checkpoints. We also need to track those. 14:34:50 So OperationEngine needs to record the progress of one operation to DB? 14:35:36 Yes. It needs to make sure it handles crashes in the middle of operations or cases where the trigger was missed. 14:36:12 what is the meaning of " trigger was missed" 14:36:42 You have a trigger at 00:00 and the host was down between 23:59 and 00:01. 14:36:55 In that case you will miss that daily backup 14:37:23 i think operation class need to make sure the logic be finished correctly. 14:37:37 Yes, and make sure it actually started 14:38:23 And if you were down until 14:00 than you might not want to backup since it will stress the system during high load. So timed triggers should have a window of operation. 14:38:31 user defined window of operation 14:39:33 saggi I have a question about Operation action. 14:39:50 In pluggable_protection_provider.pu this file. I note that enum Operation ony have protect, enable,disable,restore these action , but do not have 'delete'. Why? 14:40:21 As a user he have a requirement deleting the backup data of a volume resource. 14:40:26 chenying_: I think I missed it 14:40:49 OK I see 14:41:06 chenying_: Good catch! 14:41:34 #topic open discussion 14:41:35 saggi: can we use the crontab format for the timetrigger ? 14:41:44 I will do some review about the protection_provider later. 14:42:27 i don't understand the rfc2445 14:43:28 http://www.kanzaki.com/docs/ical/rrule.html 14:44:21 saggi:thanks 14:44:36 chenzeng: But you are right, crontab is simpler. 14:45:14 I say we will start with crontab and see if users ask for the more complex features of ical\rrule 14:45:15 saggi:will we use crontab, or support both 14:45:22 rfc2445 is complex indeed. 14:46:03 chenzeng: OK, I agree with you. crontab for now. 14:46:20 saggi: Speaking from experience from working on a data protection product in the past, user protection rules usually end up being more complex than cron can represent. 14:46:21 saggi:ok 14:46:34 smcginnis: hmmm 14:46:43 But that said, I think it's probably simpler to start with cron and make it more complex later if that's what's needed. 14:46:59 Probably better not to go for the more complex scheme right away. ;) 14:47:22 chenzeng, smcginnis: We'll add a format specifier in the trigger. crontab only for v1 14:47:29 saggi: +1 14:47:48 saggi:ok 14:48:11 #action add format specifier for timed triggers 14:48:48 Anything else? We have 10 more minutes! 14:49:04 saggi:in order to make sure the consistance of operation, do you have any good ideas? 14:50:15 Always persist before doing anything. Make sub operations that are either idempotent or sub operations you can always verify if they occurred or not. 14:50:47 chenzeng: We could talk in #openstack-smaug about specific operations if you like 14:51:07 OK, that I think we are done. 14:51:09 saggi:ok 14:51:26 Thanks everyone 14:51:31 Thanks! 14:51:35 Thanks 14:51:42 thanks 14:51:51 Bye 14:51:55 I hope that next time yinwei will join us. 14:52:07 #endmeeting