09:01:33 <chenying> #startmeeting karbor
09:01:34 <openstack> Meeting started Tue Sep 26 09:01:33 2017 UTC and is due to finish in 60 minutes.  The chair is chenying. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:01:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:01:38 <openstack> The meeting name has been set to 'karbor'
09:01:39 <chenying> hi
09:02:04 <yuval> hey :)
09:02:15 <chenying> hi
09:02:18 <chenying> ping jiaopengju
09:02:30 <jiaopengju> hi chenying
09:03:04 <chenying> will gengchangcai attend this meeting?
09:03:36 <jiaopengju> It seems he is not online
09:04:19 <chenying> #topic •Adding more protection parameters retention period
09:04:36 <jiaopengju> I added this topic
09:05:39 <jiaopengju> I have some different thoughts about retain_duration and max_backups
09:06:45 <jiaopengju> chenying, yuval: Can you see the comments on that patch?
09:06:50 <yuval> jiaopengju: yes
09:07:23 <yuval> jiaopengju: max_duration can not be enforced if set on the 'protect' operation
09:08:11 <jiaopengju> yuval: yes
09:08:34 <yuval> my suggestion: create a 'retention_enforce' operation that deletes old checkpoints, based on time and maximum amount. Run it periodically
09:09:24 <jiaopengju> chenying: I see your comments
09:09:36 <yuval> we can also create a composite operation, called which is essentially a composite 'protect + retention_enforce' and call it when creating a checkpoint. That way if we surpass the maximum amount, old checkpoints will be deleted
09:09:46 <chenying> add a new type operation with these parameters?
09:09:54 <yuval> chenying: yes
09:10:44 <chenying> It seem a good way. I will not affect the current the 'protect' operation.
09:10:54 <yuval> it is important to note that currently in Karbor, 'delete' operation immediately triggers an actual delete. Originally, we spoke about marking the checkpoint as 'about to be deleted' and let garbage collection do the work later, as other sites might be accessing the checkpoint resources
09:12:27 <jiaopengju> yuval chenying: I agree with ‘create a 'retention_enforce' operation that deletes old checkpoints, based on time and maximum amount. Run it periodically’
09:13:04 <chenying> yuval You mean that his new type operation with parameters is a mixed operation, it can call delete or protect operation ?
09:14:02 <yuval> chenying: I mean, that if it is important to you to delete old checkpoints immediately if 'max_backups' is violated, you can call 'protect + retention_enforce' composite operation
09:14:11 <yuval> chenying: imo most people won't care
09:15:48 <chenying> Yes user may don't care. I agree that introducing a 'protect + retention_enforce' composite operation.
09:16:56 <chenying> We don't need add some handler in current protion pertion about the  parameters about 'max_backups'.
09:19:22 <chenying> so what's your oppion? jiaopengju
09:20:11 <jiaopengju> chenying yuval : composite operation may be easy to add. But may be a little strange. IMO, retention should be set to some specify resources.
09:20:42 <jiaopengju> specify resources —> checkpoint
09:21:39 <jiaopengju> As I wrote in the comments. For example, I create a checkpoint c1 and I want it can be deleted 5 days later.  What should I do?
09:22:38 <chenying> 'protect + retention_enforce' composite operation: protect opertion is creating new checkpoint periodically, retention_enforce handle the parameters.
09:23:33 <jiaopengju> chengying: I know what you mean
09:24:12 <chenying> now we only consider add the policy parameters like max_backups and retention_duration for the  time scheduled operation.
09:24:40 <jiaopengju> chenying: Maybe what I concerned about is not the same use case with the specs
09:25:16 <chenying> You want to set some policy parameters like max_backups and retention_duration  for the single creating checkpoint API?
09:26:15 <jiaopengju> yes.
09:27:00 <jiaopengju> like swift object expiration
09:27:01 <chenying> In karbor, we will not consider set some policy for single checkpoint API only. All these parameters need be considered in  scheduled operation API.
09:28:02 <jiaopengju> If so, composite operation may be suitable
09:29:13 <chenying> IMO, the parameters like max_backups and retention_duration are the addition policy for time scheduled operation.
09:30:18 <jiaopengju> chenying: agree
09:30:59 <chenying> so  composite operation for this usecase.
09:32:05 <chenying> #topic Open Discussion
09:32:21 <chenying> yuval jiaopengju do you have anything want to discuss?
09:32:29 <yuval> yes
09:33:15 <yuval> First I would like to congratulate jiaopengju for the Karbor core role
09:33:33 <jiaopengju> thank you yuval :)
09:33:47 <chenying> congratulations.
09:34:29 <jiaopengju> chenying yuval: it’s my honour to work with you guys
09:34:52 <yuval> Second, I'll be leaving my current company in the beginning of November, and probably won't have time to continue contributing much to Karbor
09:35:36 <jiaopengju> sad to hear that
09:36:07 <jiaopengju> yuval: but congratulations to your new job
09:36:24 <yuval> I'm convinced that chenying can lead this project flawlessly
09:36:31 <chenying> It's a pleasure working with you, yuval/
09:36:38 <yuval> chenying: jiaopengju: thank you :)
09:37:04 <yuval> chenying: jiaopengju: pleasure working with you too
09:37:20 <yuval> that's it
09:37:26 <jiaopengju> yuval: :)
09:39:56 <chenying> yuval congratulations on your new job. welcome to china for traveling.
09:40:09 <yuval> chenying: thank you =D
09:40:55 <chenying> so do we have anything else to discuss? If not  I wll end this meeting.
09:41:38 <chenying> #endmeeting