09:01:03 <saggi> #startmeeting karbor
09:01:04 <openstack> Meeting started Tue Sep 13 09:01:03 2016 UTC and is due to finish in 60 minutes.  The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:01:08 <openstack> The meeting name has been set to 'karbor'
09:01:10 <saggi> Hi everyone
09:01:13 <zhonghua> hi
09:01:16 <leon_wang> hi
09:01:20 <chenying_> hi
09:01:23 <yuval> hey
09:01:33 <xiangxinyong> hello
09:01:58 <saggi> Yinwei has a bunch of stuff in the agenda
09:02:07 <saggi> does anyone know if she's coming?
09:02:28 <leon_wang> saggi:she not here？
09:02:54 <zhonghua> she will join in 10 mins
09:03:43 <yuval> meanwhile, if anyone is lurking in #openstack-smaug, please leave that channel
09:03:44 <leon_wang> today we'll have a lot to talk :)
09:03:57 <saggi> #topic Decouple checkpoint API from provider API to become an standalone API(leon_wang)
09:04:33 <leon_wang> Here is the patch: https://review.openstack.org/#/c/369170/
09:05:17 <leon_wang> we can talk about it free
09:05:23 <saggi> leon_wang: I read it. I have to say that I don't agree with it. There is no way for us to decouple it from the provider since this is where the information is.
09:05:34 <zhonghua> as my email said, I am afraid of that there will be many impact points
09:05:39 <leon_wang> saggi:why?
09:05:55 <saggi> It's like accessing a file without knowing the directory
09:06:01 <saggi> This is where the information is
09:06:16 <saggi> querying all the providers can be done from the API or UI
09:06:20 <chenying_> What's your oppions about it. I think if this API is independent. we need think more about how to save checkpoint metadata/data to bank.
09:06:35 <leon_wang> saggi:then we can create a new directory and we should do it.
09:06:49 <saggi> I don't think you understand the analogy.
09:06:58 <saggi> How do I know where to find a checkpoint id
09:07:05 <saggi> I will have to check all the providers
09:07:30 <saggi> We also don't guarantee that a checkpoint ID is unique between providers
09:08:05 <leon_wang> saggi:maybe you have a little misunderstand...
09:08:24 <saggi> maybe
09:08:30 <leon_wang> saggi:i don't mean to decouple all of it ,just api
09:08:32 <zhonghua> leon_wang: what's your proposal?
09:09:15 <yuval> we do have redundancy of parameters in checkpoint rest API
09:09:21 <zhonghua> leon_wang: what's your meaning? change the API file location?
09:09:31 <yuval> when you query checkpoints from a provider, provider_id is both in url and in request body
09:09:45 <yuval> zhonghua: what impact points?
09:10:14 <zhipeng> i think what leon meant is that we have a seperate checkpoint api rather than have it all in the provider api
09:10:19 <zhonghua> yuval: framewrok, model, I don't know
09:10:29 <leon_wang> zhonghua:kinda, we can just add a database table to save the provider_id and some other parameters.
09:10:47 <zhonghua> leon_wang: yes, we have.
09:10:57 <saggi> I understood it's about removeing the paramter from the URI
09:11:12 <saggi> we can remove it from the body but not the URI
09:11:25 <leon_wang> zhonghua:then we don't need to pass provider from client
09:11:36 <chenying_> Now if a tenant want query all the checkpoint which he create. He must know all the provider_id he have slected. If the checkpoint api is independent without provider_id, he can query the checkpoint with different provider at the same time.
09:12:08 <saggi> I don't like being able to query all the banks at once
09:12:12 <zhonghua> saggi: sounds not your understanding if i am correct. he wants to change the URI instend of parameter
09:12:21 <saggi> they query could get stuck because one bank is inaccessible
09:12:27 <saggi> and we could get duplicates
09:12:32 <zhonghua> leon_wang: make sense
09:12:44 <yuval> chenying_: he meant moving the provider id to the body of the request. the provider id is still required
09:13:03 <leon_wang> yuval:yes
09:13:29 <leon_wang> i don't mean to remove provider from checkpoint
09:13:41 <chenying_> oh  just move the place of provider.
09:14:11 <leon_wang> we can just save the provider_id when we create the checkpoint
09:14:16 <saggi> I look at it like how swift users /{container}/{object}
09:15:06 <chenying_> What would be the benefit of moving the provider_id from url to post body?
09:15:30 <saggi> It would just be harder to convery that it's mandatory
09:15:33 <saggi> IMHO
09:16:27 <yinwei_lab> hi
09:16:34 <zhonghua> chenying_: that's the decouple meaning. I think
09:17:15 <leon_wang> chenying_:By definition in WIKI, Protection Provider is a composition of Protection Plugins covering supported resource types, and a Bank Plugin for persisting the data, whereas Checkpoint is the state, data, and metadata of protected resources, in a point of time.
09:18:16 <saggi> checkpoints are contained in a bank. But since a Bank doesn't have an explicit API entry the provider is the closest point
09:18:25 <leon_wang> IMO,the checkpoint operation is some like plan
09:18:34 <saggi> plans are local
09:18:38 <saggi> they don't exist in the bank
09:18:58 <zhipeng> saggi: but users do want to operate on the checkpoints right?
09:19:10 <zhipeng> do all the CRUD operations
09:19:28 <saggi> Similar to objects in swift
09:19:39 <zhipeng> or if they have an orchestrator, it should be able to perform LCM of checkpoints in Karbor
09:19:57 <yinwei_lab> zhipeng, the difference of checkpoints and plans is: checkpoints will be shared among karbors but plans won't
09:20:32 <saggi> When you want to list a checkpoints you are actually listing a provider
09:20:39 <saggi> similar to a container and ojects
09:20:45 <leon_wang> saggi:And checkpoint may provide much more function later,why don't we do it now?
09:21:11 <saggi> leon_wang: It's not a question of functionality. You can have all the functionality under any URI
09:21:15 <saggi> the main issues is that
09:21:28 <saggi> GET /api/v1/checkpoints/ will never work
09:21:45 <saggi> only GET/api/v1/checkpoints/?provider_id=123
09:21:57 <saggi> this means you have a trivial endpoints that doesn't work
09:22:11 <zhipeng> leon_wang meant he will still have the provider_id in the post body right ?
09:22:13 <leon_wang> saggi:we can't remove the provider_id?
09:22:21 <leon_wang> zhipeng:yes
09:22:39 <saggi> You can't query all the providers at once in the same call. It will mean that Karbor has to go list all the banks.
09:22:44 <zhonghua> leon_wang: does that mean your proposal is only to change rest api?
09:22:52 <leon_wang> saggi:we just move the provider_id to the body.
09:23:01 <chenying_> a provider_id mean a constant bank. Here the provider_id in the checkpoint api url mean this checkpoint data belong to this bank of provider. So I think it is reasonable.
09:23:07 <zhipeng> zhonghua yes I think he might mean that
09:23:15 <saggi> leon_wang: It still means that GET /api/v1/checkpoints can't just work
09:23:53 <saggi> It's problematic to have such a simple thing not work. It's the first things people will try and do and it can't work.
09:24:05 <leon_wang> saggi:even after we create a checkpoint API module?
09:24:15 <zhonghua> zhipeng: ok, it makes sense
09:24:35 <saggi> It can't logically work. Since if the user doesn't specify the provider_id we don't have enough information
09:24:45 <saggi> also /api/v1/checkpints/123 is not unique
09:25:11 <saggi> since we don't guarantee that IDs are unique across providers
09:25:18 <saggi> since a bank could have been cloned
09:25:37 <saggi> So simple REST invariants are violated
09:25:47 <saggi> This is why Swift did it
09:25:59 <saggi> *probably
09:26:50 <zhonghua> saggi: the user can provide the provider_id via filling the request body parameter, if I understand correctly. :)
09:27:02 <leon_wang> saggi: Sorry i stiil no get it why checkpoint is related a provider.
09:27:02 <saggi> This is far from trivial or standard
09:27:45 <leon_wang> saggi:why we can't promise it's unique?
09:27:50 <saggi> leon_wang: Since the checkpoint sits in the bank which is part of the provider
09:28:11 <saggi> leon_wang: Since banks are not coordinated
09:28:28 <leon_wang> saggi: but logically they don't belong.
09:28:45 <saggi> leon_wang: What does not belong logically?
09:28:47 <leon_wang> saggi:according to the wiki definition
09:29:06 <saggi> According to the definition it's a group of plugins+bank
09:29:21 <saggi> You can't directly access the bank
09:29:34 <saggi> so the only way to know what bank you are referring to is the provider
09:29:39 <zengchen> saggi:IMO, from the user's perspective, they will query the checkpoints they create. at present, if they do so, they should query each provider one by one, which sounds not very reasonable.
09:29:48 <leon_wang> saggi: we don't have to access the bank
09:30:08 <yuval> zengchen: that is a must
09:30:44 <zengchen> yuval:why? that's too complex.
09:31:10 <saggi> If they don't query one by one Karbor will have to do it. This might be problematic since one bank might be unresponsive and that means that requests will fail when the information the user needs might be there.
09:31:16 <yinwei_lab> our checkpoints name space is divided by provider by design
09:31:18 <zhonghua> zengchen: how to index the checkpoints? by tenant?
09:31:28 <leon_wang> saggi:we can add a table, when user delete a checkpoint first it will go through the table to find provider_id
09:31:45 <saggi> We can't user a database since it will only work for a single site
09:31:52 <saggi> s/user/use
09:31:53 <yuval> leon_wang: checkpoint already includes provider_id in it
09:32:27 <leon_wang> yuval:where? bank?
09:32:36 <yuval> yes, in the checkpoint metadata
09:33:01 <zengchen> zhonghua:would be better by user.
09:34:04 <leon_wang> yuval:i know what you mean, but the database table just save provider_id because API don't contain provider_id
09:34:26 <saggi> The api contains provider id it's part of the URI
09:34:41 <yuval> leon_wang: API contains provider_id. whether it is in the URL by the current API, or in the body as you suggest
09:35:04 <leon_wang> yuval:yeah ,in the body
09:35:51 <leon_wang> saggi: as long as the body contains provider_id, we can solve the problem about url.
09:36:12 <saggi> leon_wang: You can't force the API user to add a body to the request. This is not how REST works.
09:36:23 <saggi> You don't put a body on GET requests
09:36:45 <saggi> s/can't/shouldn't
09:36:53 <leon_wang> saggi:they just need the body when they create
09:36:57 <chenying_> You don't put a body on GET requests  +1
09:37:07 <yuval> chenying_: yes, +1
09:37:28 <leon_wang> saggi:other they don't need anything but checkpoint_id.
09:37:30 <saggi> No, since /api/v1/checkpoints/123 will not work without use knowing in the request what provider id to use
09:37:43 <saggi> We will not look at all the providers
09:38:05 <saggi> And even if we do the ID is not unique
09:38:10 <saggi> across providers
09:38:21 <saggi> So we can't use it as an ID
09:38:24 <leon_wang> saggi:when we create a checkpoint, we can save provider_id to the database besides the bank
09:38:50 <saggi> leon_wang: We can't use a database since it's not synced across sites
09:39:00 <zengchen> leon_wang:if you just want to move the provider id to the requst body, i can not see any benifit.
09:39:08 <leon_wang> then other operations, it will at first get the provider_id.
09:39:43 <leon_wang> zengchen:no,that's not my point
09:40:04 <leon_wang> saggi: what do you mean?
09:40:28 <leon_wang> saggi: synced across sites?
09:40:47 <zengchen> leon_wang:sorry, if i misunderstand you.
09:40:47 <chenying_> leon_wang: checkpoint metadata/data will be used in cross-restoration. So if the checkpoint api depend on the local database, I think it is not a good idea.
09:41:01 <chenying_> cross-site-restoration
09:41:15 <zhonghua> chenying_:+1
09:41:27 <zhonghua> what I am thinking about is the cross-site restoration senario.
09:41:33 <saggi> leon_wang: I think we discussed this enough. I'll put a summary after the meeting on the blueprint and we can continue there.
09:41:45 <saggi> We still have more topics than time
09:41:47 <saggi> OK
09:41:49 <saggi> ?
09:41:50 <leon_wang> saggi: ok,thanks
09:42:18 <saggi> #topic Enable ConsistencyGroup and full vm protection (snapshot/backup) through Karbor (yinwei)
09:42:25 <saggi> yinwei_lab: is there a BP?
09:42:31 <yinwei_lab> not yet
09:43:22 <yinwei_lab> talked this with ying, and I'm thinking we need enable this capability in our sample vm/volume plugins
09:43:36 <yinwei_lab> what do you guys think about?
09:43:58 <yinwei_lab> if it's agreed, I will go to draft the bp
09:44:30 <saggi> yinwei_lab: Maybe for O cycle. We are still struggling with regular VM backup
09:44:36 <saggi> But put the BP up
09:44:44 <yinwei_lab> thanks!
09:44:47 <saggi> We need to start having concrete things before bcn
09:45:01 <saggi> Too bad most of you guys won't make it
09:45:17 <yinwei_lab> we will come for a bp
09:45:18 <zhonghua> yinwei_lab: agree
09:45:28 <yinwei_lab> if the bp is agreed, we will go to implement it
09:45:31 <yuval> yinwei_lab: what do you mean by 'full vm protection'?
09:45:32 <yinwei_lab> :)
09:45:32 <zhonghua> saggi:+1
09:45:45 <saggi> #topic Enable replicate protection plugin(yinwei)
09:45:47 <yuval> yinwei_lab: nvm, let's speak afterwads
09:46:08 <yinwei_lab> same status as above
09:46:09 <saggi> I think this is the same as the previous topic
09:46:12 <saggi> Sure
09:46:22 <yinwei_lab> but there's a problem for replicate
09:46:31 <saggi> #topic Add a dict type parameter for Protectable Instances API (chenying)
09:46:52 <yinwei_lab> how to catch a checkpoint for replication?
09:47:19 <saggi> chenying ...
09:47:19 <chenying_> I have expain it why I need add parameter for this api in the wiki page.
09:47:31 <saggi> For the public API?
09:47:44 <chenying_> yes
09:48:36 <saggi> It seems like a good suggestion but what I'm missing is how it all fits in the user-story
09:48:44 <saggi> Do we use it during plan building?
09:48:49 <chenying_> one scenario is cross-region-query-instance.
09:48:53 <yuval> chenying_: are the only 2 use cases right now are region and vendor auth?
09:48:59 <chenying_> yes
09:49:05 <chenying_> yuval:yes
09:50:26 <chenying_> I will submit a bp about it. What's your oppions about it.
09:50:58 <yuval> chenying_: I belive there is a room for it, but a user will have to know what parameters to pass
09:51:41 <saggi> I also have trouble seeing how dashboard integration would work
09:51:43 <chenying_> cross-region-query-instanc may also consider how to protect the instance in different region.
09:53:26 <chenying_> saggi: we may need define the certain key of the parameter.
09:53:39 <chenying_> saggi: I will discuss this with xinyong.
09:53:43 <saggi> chenying, it's a good idea but we need more specifics. I think a BP is in order and make sure xiangxinyong also signs off on it.
09:53:57 <xiangxinyong> saggi, chenying: ok
09:54:09 <xiangxinyong> we will discuss the bp together
09:54:32 <chenying_> Ok I will submit a bp later.
09:54:49 <saggi> chenying thanks.
09:55:13 <saggi> #topic open discussion
09:55:19 <saggi> We have only 5 minutes
09:55:29 <yuval> well
09:55:29 <saggi> So any last words?
09:55:30 <leon_wang> saggi:sorry ,my bad.
09:55:33 <yinwei_lab> zhonghua, you guys won't go to bcn?
09:55:34 <saggi> leon_wang: np
09:55:45 <zhonghua> yinwei_lab:not sure
09:55:57 <yuval> leon_wang: good to see you on the irc meetings
09:56:07 <zhonghua> yinwei_lab:how about you?
09:56:14 <leon_wang> saggi: I will modify further, we can talk about it later, ok?
09:56:23 <saggi> leon_wang: Sure, np
09:56:38 <yinwei_lab> zhonghua: not sure, I still suffers with my passport
09:56:39 <yuval> I just want to say thanks for zhangshuai and xiangxinyong, they are doing many reviews
09:56:53 <xiangxinyong> thanks yuval
09:56:55 <leon_wang> saggi:i also have a question about restore api
09:57:03 <saggi> leon_wang: shoot
09:57:22 <leon_wang> why it have delete in client but not in api?
09:57:27 <zhangshuai> thanks for yuval
09:57:38 <yuval> and zhangshuai did a great work on docs and api
09:57:55 <saggi> leon_wang: I don't understand the question
09:57:58 <leon_wang> yuval:+1
09:58:06 <chenying_> zhangshuai: good job!
09:58:20 <zhonghua> zhangshuai xiangxinyong: thanks
09:58:24 <leon_wang> saggi: i will submit a patch later.
09:58:30 <zhangshuai> thanks
09:58:49 <saggi> Is that all?
09:58:57 <leon_wang> yup
09:59:42 <saggi> #endmeeting