15:01:25 <saggi> #startmeeting smaug
15:01:25 <openstack> Meeting started Tue Jul 26 15:01:25 2016 UTC and is due to finish in 60 minutes.  The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:29 <openstack> The meeting name has been set to 'smaug'
15:01:29 <xiangxinyong456> i am on my mobile
15:01:32 <saggi> Hi everyone
15:01:37 <zhonghua-lee> hi
15:01:57 <xiangxinyong456> hello
15:01:58 <saggi> Anyone else here?
15:02:03 <xyang1> hi
15:02:29 <saggi> OK
15:02:36 <saggi> Are we waiting for anyone?
15:03:10 <xyang1> saggi: can I bring up something quickly?
15:03:13 <saggi> Sure
15:03:26 <saggi> Though there is an open discussion portion at the end
15:03:39 <xyang1> saggi: I can wait to the end
15:03:43 <saggi> cool
15:03:47 <saggi> #topic Add pause and resume interface for scheduled operations
15:04:17 <saggi> IIRC We already have this
15:05:06 <zhonghua-lee> already have?
15:05:19 <chenzeng> saggi:yes, does everybody take a look at this suggestion
15:06:03 <chenzeng> saggi:maybe we have not suppot these two apis
15:06:20 <saggi> Why not just change the status?
15:06:48 <saggi> If status is disabled\paused we don't trigger
15:06:56 <saggi> no need to unregister in the API
15:06:59 <chenzeng> because we have registered the opertion to the trigger in the memory
15:07:20 <saggi> chenzeng: In memory we can unregister. But no in the DB.
15:07:44 <chenzeng> saggi:yes, so we have two steps
15:08:26 <saggi> So if the user modifies the scheduler operation to have status="paused". We will unregister internally.
15:08:33 <saggi> No need for new API paths
15:09:30 <chenzeng> saggi:as i know, we don't have the logic as you said
15:10:30 <saggi> chenzeng: We can add it. I think it's preferable to having new API paths for pause\resume
15:11:49 <chenzeng> saggi:i agree
15:12:02 <saggi> Good!
15:12:08 <saggi> Anything else on this topic?
15:12:29 <chenzeng> saggi:no
15:12:33 <saggi> #topic Where to show the status of restoration?
15:12:39 <saggi> This is an interesting question.
15:12:45 <xiangxinyong> yeah
15:12:46 <xiangxinyong> https://etherpad.openstack.org/p/restorestate
15:12:50 <zhonghua-lee> :)
15:13:05 <saggi> Don't we get this from HEAT?
15:13:21 <saggi> What does it use?
15:13:32 <xiangxinyong> saggi: yeah. we can get it from heat.
15:13:47 <saggi> It could be added to the restore model.
15:14:02 <saggi> we get the information from heat and retrieve it there.
15:14:13 <saggi> Similar to how we do it for checkpoint.
15:14:42 <xiangxinyong> saggi: it seems we are talking about another question
15:14:52 <xiangxinyong> When the end user restore a checkpoint
15:15:16 <saggi> This is what I'm talking about. This creates a restore object.
15:15:18 <xiangxinyong> we will add a record into the restore table
15:15:57 <xiangxinyong> could i think the restore object is put into restores table?
15:16:27 <saggi> Could you rephrase that. I don't understand.
15:16:39 <xiangxinyong> yeah
15:17:24 <xiangxinyong> We have a db table named "Restores" to store the records when we restore from a checkpoint.
15:17:51 <saggi> ok
15:18:24 <saggi> It should relate the the corresponding Heat operation
15:18:25 <xiangxinyong> and the DB table "Restores" has a field named "Status"
15:19:02 <xiangxinyong> and also we have a "Status" on the checkpoint
15:19:20 <zhonghua-lee> where to restore the status?
15:19:29 <xiangxinyong> the status of checkpoint include "Protecting" "Available"
15:19:48 <saggi> xiangxinyong: "protecting"?
15:19:54 <saggi> restoring maybe
15:19:59 <xiangxinyong> yeah
15:20:35 <xiangxinyong> saggi: about this question: Where to show the status of restoration?
15:20:58 <xiangxinyong> do you think we need to show "Restoring" on the checkpoint?
15:21:35 <xiangxinyong> or just onlu show "Restoring" on the DB table "Restores"
15:21:44 <xiangxinyong> or both?
15:21:53 <saggi> I think just in restores
15:22:00 <saggi> Since it's not a status for the checkpoint
15:22:17 <saggi> The restore should point the the checkpoint
15:22:22 <saggi> not the other way around
15:23:10 <xiangxinyong> so you think the status of checkpoint just only include the protecting and available?
15:23:21 <saggi> Yes
15:23:52 <zhonghua-lee> saggi: so smaug will update the record in Restore table after restoration. am I right?
15:23:57 <saggi> yes
15:24:05 <zhonghua-lee> looks good
15:24:22 <chenzeng> saggi:agree
15:25:14 <xiangxinyong> OK. understood.
15:25:24 <saggi> #topic add policy for checkpoints management
15:25:46 <zhonghua-lee> ok
15:26:09 <zhonghua-lee> this proposal just want to add a policy for checkpoint management
15:27:01 <saggi> This is what Schedule Operations are for. You can have one that limits the amount of checkpoints every night to 10.
15:27:11 <zhonghua-lee> e.g. the end user want to keep three checkpoints for one plan.
15:27:26 <zhonghua-lee> saggi: yes
15:28:00 <zhonghua-lee> but how about add this function in checkpoint management moudule?
15:28:15 <saggi> I don't understand the suggestion
15:28:47 <yuvalbr> Hey, sorry for being late
15:28:54 <zhonghua-lee> I mean we can add a moudule to manage the checkpoints
15:29:40 <saggi> These kind of operation are by design relegated to the Operation Engine or some external Policy mechanism
15:30:29 <zhonghua-lee> what means for external Policy mechanism?
15:31:09 <saggi> Tricircle
15:31:10 <zhonghua-lee> smaug provide a Rest API to delete checkpoint? query checkpoints by plan?
15:31:31 <zhonghua-lee> the other module do this operation?
15:32:01 <saggi> Something can use the Rest API to query and delete.
15:32:03 <zhonghua-lee> I perfer to  Smaug.
15:32:06 <saggi> It will need to handle the transaction
15:32:29 <saggi> The problem with implementing it in Smaug is that we find that many users want to use their own policy mechanisms
15:32:57 <zhonghua-lee> saggi: yes
15:33:16 <zhonghua-lee> if we add this function into Operation Engine
15:33:28 <saggi> This is it's purpose.
15:33:41 <zhonghua-lee> that will make the policy very complex
15:33:49 <saggi> Why?
15:34:03 <zhonghua-lee> not only for backup policy
15:34:16 <zhonghua-lee> but also for checkpoints policy
15:34:53 <saggi> I'm sorry, but I don't understand the problem. Could you please be more specific?
15:35:06 <xiangxinyong> saggi: zhonghua means that if some users want to keep only 3 checkpoints every plan in the bank
15:35:24 <chenzeng> saggi: what's your opinion about question 'just keep 3 checkpoint for a scheduled protection operation which will generate 1 checkpoint every day'
15:36:07 <zhonghua-lee> yeah , chenzegn give the example
15:36:10 <saggi> You can have an advance operation that creates and deletes. The operation engine is built for these kind of transaction.
15:37:24 <zhonghua-lee> operation extension sounds the best choice
15:37:28 <chenzeng> saggi:so you want to add a new operation?
15:38:17 <zhonghua-lee> but how the operation know the new checkpoint created successfully?
15:38:50 <chenzeng> this operation will invoke the api to create the checkpoint, and then check the number of checkpoint, if ecceed the 3, delete the oldest
15:39:04 <saggi> chenzeng: Exactly
15:40:17 <xiangxinyong> but if the user only use the method "protect now"?
15:41:07 <saggi> It will delete when the scheduled operation runs.
15:41:21 <saggi> Since this is the point it will check for the number of checkpoints.
15:41:29 <zhonghua-lee> xiangxinyong: you mean user create checkpoint manully?
15:41:34 <saggi> We could add checkpoint MD to make sure they don't get counted.
15:41:42 <xiangxinyong> zhonghua-lee: yeah
15:41:43 <chenzeng> zhonghua-lee:the 'create checkpoint' api will return a id of checkpoint if it success
15:42:30 <zhonghua-lee> saggi: who will check when ceeating manully?
15:42:39 <zhonghua-lee> the caller?
15:43:18 <saggi> create checkpoint returns an ID from the start. Not only for success.
15:43:29 <saggi> zhonghua-lee: yes
15:43:36 <zhonghua-lee> chenzeng: yeah, but it not really success until the status changed
15:43:37 <saggi> Whoever calls is responsible for tracking
15:43:47 <zhonghua-lee> s/it/it is
15:44:01 <saggi> zhonghua-lee: Even if it fails the scheduled op needs to log it.
15:45:00 <zhonghua-lee> saggi:but the number is not correct
15:45:25 <chenzeng> zhonghua-lee:we can ignore the checkpoint which is created this time, just make sure the success checkpoint will not exceed 3.
15:45:25 <zhonghua-lee> checkpoint number
15:45:51 <saggi> of course
15:46:14 <xiangxinyong> so it seems like whoever it invokes "createcheckpoint" will check the checkpoint amount?
15:46:17 <zhonghua-lee> chenzeng: you mean we only care about the chenckpoints model numbers
15:47:00 <zhonghua-lee> ok, I agree
15:47:49 <saggi> I'm not sure that manual checkpoints should count. But this is a matter of policy.
15:48:20 <saggi> In any case, it has to be done in the operation engine. And the details are policy dependent :).
15:48:37 <zhonghua-lee> let me think it over
15:48:41 <zhonghua-lee> saggi: thanks
15:49:07 <saggi> #topic Mark the source of checkpoint data
15:49:45 <saggi> This puts us back with the suggestion of having user defined MD on the checkpoints.
15:50:01 <saggi> It's fine by me as long as it can only be set on checkpoint creation and can't be modified.
15:50:29 <xiangxinyong> chenying sumbit this topic.
15:50:42 <zhonghua-lee> I think it's just for record
15:50:56 <saggi> This means that scheduled operations can just add an MD key ("CHECKPOINT_SOURCE": "SCHEDULED_OPERATION-123")
15:51:21 <xiangxinyong> saggi: like that.
15:51:21 <saggi> If it doesn't have this we can assume it was manual or some other source that doesn't wish to identify.
15:51:52 <saggi> similar to custom volume MD in cinder
15:52:10 <xiangxinyong> add a parameter in the createcheckpoint interface
15:52:29 <xiangxinyong> CHECKPOINT_SOURCE: Scheduled/Now
15:52:36 <saggi> no
15:52:41 <xiangxinyong> ?
15:52:50 <saggi> we just add the ability to add any user metadata.
15:53:08 <saggi> and use the convention for 'smaug-checkpoint-source' to mark the source
15:53:24 <saggi> if it's missing we assume manual since the scheduled operation will add it
15:53:40 <saggi> and we would recommend other tools to add their own name in the entry
15:53:52 <saggi> we need a proper blueprint for this though
15:54:09 <saggi> I'll write one tomorrow.
15:54:13 <zhonghua-lee> saggi: +1
15:54:15 <saggi> We could comment on that.
15:54:44 <xiangxinyong> ok. we could add the checkpoint source into metadata
15:54:50 <xiangxinyong> :)
15:54:51 <saggi> yes
15:55:02 <saggi> We'll continue this on the blueprint when I put it up.
15:55:13 <chenzeng> saggi:great
15:55:28 <xiangxinyong> saggi: thanks
15:55:31 <saggi> #topic open discussion
15:55:48 <saggi> xyang1: You had something you wanted to discuss
15:55:54 <xyang1> saggi: yes
15:56:14 <xyang1> saggi: about the discussions on cinder replication spec
15:56:35 <xyang1> saggi: We talked about it at our mid cycle last week
15:56:42 <saggi> Yes
15:57:04 <xyang1> so the suggestion is fir smaug team to submit another spec about this requirement
15:57:20 <saggi> xyang1: Instead of the current one?
15:57:23 <xyang1> also we like to have an irc meeting to discuss
15:58:14 <saggi> xyang1: Sure, do you want to do it on the Cinder weekly spot or should we do it out of band?
15:58:17 <xyang1> saggi: the one I am working on is cinder replication group, you should submit another spec on hide namespace
15:58:33 <saggi> xyang1: Sure
15:58:45 <xyang1> saggi: we could probably add an item to cinder meeting
15:59:10 <xyang1> saggi: if it runs over, we can schedule a separate one to follow up
15:59:24 <saggi> I could try and have something ready for tomorrow's IRC
15:59:29 <saggi> It's not complicated
15:59:34 <xyang1> sure
16:00:07 <xyang1> can you add an item to the meeting, I can add it too
16:01:02 <chenying> hi
16:01:12 <xyang1> saggi: ?
16:01:20 <zhonghua-lee> time out.
16:01:24 <chenying> I have a problom with my network.
16:01:37 * saggi is looking for the meeting wiki
16:02:18 <saggi> Found it
16:02:42 <saggi> xyang1: I'll add it now and update tomorrow with an etherpad link for the first bp draft
16:02:48 <xyang1> great
16:03:19 <saggi> xyang1: So we'll pick it up tomorrow
16:03:26 <xyang1> sure
16:04:10 <xiangxinyong> good night
16:04:17 <saggi> Goof meeting
16:04:22 <saggi> Thanks everybody
16:04:26 <saggi> #endmeeting