09:00:31 <saggi> #startmeeting karbor
09:00:32 <openstack> Meeting started Tue Jan 17 09:00:31 2017 UTC and is due to finish in 60 minutes.  The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:35 <openstack> The meeting name has been set to 'karbor'
09:00:44 <saggi> Hi everyone
09:00:48 <yuval> Hello!
09:01:15 <chenying_> hi
09:01:18 <zhonghua> hi
09:01:24 <edisonxiang> hello
09:01:52 <zengchen> hi everyone.
09:01:57 <zhangshuai> hi
09:01:58 <wujiajun> hi
09:02:07 <saggi> #topic The status of plan
09:02:15 <saggi> Who suggested this?
09:02:22 <chenying_> A new guy wujiajun join our team. :D
09:02:36 <chenying_> topic The status of plan  It is mine.
09:02:43 <zhangshuai> welcome
09:02:58 <yuval> Welcome!
09:03:09 <saggi> welcome, wujiajun!
09:03:23 <zhonghua> welcome
09:03:45 <saggi> chenying_, the thing I don't understand about this topic is that it talks about protecting as being part of the plan status. A plan shouldn't be in a protecting state.
09:03:48 <chenying_> ◦Now a plan with several volumes is being protected. The user still could create a checkpoint with this plan to protect the resources. Then the protection about volumes may fail. Because the status of volume is "backup" already.
09:03:48 <chenying_> ◦Can we consider that setting the status of plan "protecting", so the plan can not be protected again when it is being protected. After the protection of the plan have been done, the status of plan is set to "available".
09:03:52 <wujiajun> thanks , all
09:04:09 <saggi> This kind of issues is solved by having the checkpoint track that state.
09:04:17 <yuval> chenying_: 1) the same resource can be part of the more than two plans, so this will not solve the case of two plans protecting the same resource in the same time
09:04:27 <yuval> chenying_: 2) the cinder backup protection plugin should handle that
09:04:44 <yuval> *of more than two
09:05:53 <chenying_> saggi : the cinder backup protection plugin should handle that ---Do we need check the status of resource whether it is "available" in the workflow.
09:06:23 <saggi> The plugin should handle this.
09:06:27 <chenying_> saggi: Or as you said, the status of resource need be handed by plugins.
09:06:33 <saggi> either wait or reuse the result
09:06:46 <saggi> depending on the protection plugin's semantics
09:07:07 <chenying_> saggi: dinfene new interface of plugins to check the resource's status?
09:07:51 <chenying_> s/dinfene/define
09:08:16 <saggi> chenying_, I don't think so.
09:08:26 <saggi> It should be done through the backend's API
09:08:39 <saggi> because it might not even be Karbor that is using the resource
09:08:47 <saggi> We need to check at the source
09:11:01 <chenying_> saggi My question is that the handleing of checkint status of resoures only be considered by plugins. Or karbor call the check method of plugins to do in the services?
09:11:43 <saggi> I think it should be done under the hood. The plugin would just wait until the device is free or fail the operation (whatever is appropriate).
09:12:06 <saggi> There is no advantage to have a check phase since making it atomic is impossible.
09:13:25 <chenying_> saggi  Ok I see. The plugin should handle the status.
09:13:47 <saggi> chenying_, unless you can think of a use case where those outcomes (waiting or failing) or not optimal.
09:15:46 <chenying_> saggi Now the resources can be add to more than one plan, the plan is also can be protected repeatedly at the same time. So some protection flow may fail.
09:16:51 <yuval> chenying_: fail, or wait until the resource is available
09:17:34 <saggi> having 2 protections run at the same time is something that should either be queued of fail anyway
09:17:50 <chenying_> saggi  fail, or wait until the resource is available----You mean that it depend on the implementment of plguins.
09:19:02 <saggi> yes, on what makes sense.
09:19:24 <saggi> Things should only be locked for a short time anyway
09:19:35 <saggi> hopefully
09:21:04 <chenying_> IMO, It may be unfriendly for the enduser. He don't know that the resource in another plan is being protected.
09:21:40 <saggi> It could be relfected in the status of the resource in the checkpoint. Something like 'waiting for resource'.
09:22:55 <chenying_> saggi What is the reason that resources can be add to more than one plan? Do we have this use case?
09:23:44 <saggi> Images mostly
09:23:55 <saggi> I don't see why VMs and volumes should be used in multiple plans
09:24:28 <yuval> we do not prevent that, however
09:25:16 <saggi> We can't possibly check for that
09:28:09 <saggi> anything else?
09:28:15 <saggi> chenying_
09:28:46 <chenying_> The use case of Images, if we only consider the snapshot image of server itself, do no't care about the original id. It may do not need add it to multiple plans.
09:29:08 <chenying_> do not care about the original image.
09:29:34 <saggi> chenying_, Sometimes images are reused between applications.
09:29:52 <saggi> In any case, since images are read only. There is no reason for them to be locked.
09:31:03 <chenying_> saggi you mean the snapshot image of server also can be reused?
09:32:00 <saggi> possibly
09:33:49 <chenying_> Ok I don't have any question. But we real consider the use case that VMs and volumes should be usedi n multiple plans.
09:34:12 <chenying_> But we real need consider the use case.
09:35:28 <saggi> #topic bug status
09:35:43 <saggi> Where are we on this front. AFAIK we should be in good shape.
09:36:29 <yuval> we have very few left
09:36:33 <yuval> we have MS3 next monday
09:37:03 <saggi> Anything unassigned?
09:37:36 <yuval> one or two
09:37:37 <chenying_> yuval and I will finish the refactor plugins work ASAP.
09:38:17 <saggi> Good
09:38:18 <chenying_> yuval: The glance plugins has been updated. I will update the nova plugins patch later.
09:40:21 <saggi> #topic PTG
09:40:51 <saggi> It coming closer and closer.
09:41:36 <saggi> Again, If you have anything you think that should be discussed by us or with other teams please write it in etherpad form.
09:41:50 <chenying_> I think we could add some detail info or description about the topics.
09:43:05 <chenying_> saggi I have a question, Do we have a plan to integrate with cinder volume snapshot?
09:43:21 <saggi> Also, we all need to look at other team's etherpads and check if they are talking about something that might interest us.
09:43:32 <saggi> chenying_, integrate in what way?
09:44:24 <chenying_> saggi develop a volume snapshot plugin.
09:44:56 <saggi> it seems odd to backup a snapshot. It's not part of the application it's a result of it.
09:45:05 <yuval> chenying_: do you mean: volume -> snapshot -> backup -> delete snapshot?
09:46:45 <chenying_> I mean that create a snapshot is a protection action. a restre action is roll-back the snapshot.
09:47:42 <chenying_> not the use case backuping the snapshot of volume.
09:48:29 <saggi> restore would be based on the snapshot. The actual use-case for in-place rollback is still not there.
09:49:11 <chenying_> In some public cloud like AWS and aliyun, the snapshot feature is the only pretction way.
09:49:43 <chenying_> restore would be based on the snapshot----Yes
09:52:03 <saggi> We should support this. It's part of the cinder implementation and dependent on configuration and backend.
09:52:14 <saggi> cinder protection plugin implementation
09:52:49 <saggi> The only issue is that it might make the snapshot less portable (depending on the backing storage) but we already plan on having providers for single site use cases.
09:54:24 <chenying_> but we already plan on having providers for single site use cases. ---- the database bank plguins is alos for the single site use cases.
09:55:22 <saggi> chenying_, yes. As I said, this should be no problem.
09:56:19 <chenying_> saggi Ok I don't have any question.
09:56:38 <saggi> We are almost out of time
09:56:43 <saggi> Thanks everybody!
09:56:53 <saggi> #endmeeting