15:03:47 <saggi> #startmeeting karbor
15:03:48 <openstack> Meeting started Tue Nov 15 15:03:47 2016 UTC and is due to finish in 60 minutes.  The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:51 <openstack> The meeting name has been set to 'karbor'
15:03:53 <saggi> Hello everyone
15:03:56 <yuval> hey
15:04:02 <leon_wang> hi
15:04:02 <edisonxiang> hey
15:04:19 <chenying> hey
15:05:23 <saggi> #topic Multi-tenant Isolation in Managing the Checkpoints(leon_wang)
15:05:58 <leon_wang> I updated the patch today.
15:06:16 <chenying> I note that saggi said that we should consider cross-site solutions about checkpoints.
15:06:42 <leon_wang> chenying:yes,and i've updated it.
15:06:51 <saggi> We also need to remember that we do want multiple projects to see the same checkpoints since restoring to a new project is a possibility.
15:07:39 <leon_wang> saggi: what do you mean that multiple projects to see the same checkpoints?
15:07:51 <saggi> tenant==project
15:07:59 <leon_wang> yes
15:08:33 <leon_wang> have you checked the latest patch?
15:08:48 <leon_wang> https://review.openstack.org/#/c/372846/11/doc/source/specs/checkpoint-tenant-isolation.rst
15:08:49 <chenying> It means that different tenant would restore a new site form the same checkpoints data.
15:09:05 <saggi> A major issue with your proposal is that the format needs to change if you are doing single or multi-site.
15:10:02 <saggi> The use might want to start with a single site and then change to a cross-site setup
15:11:10 <leon_wang> saggi: I don't think it's a problem because the solution between single and multi are seprate.
15:11:20 <saggi> That is the problem
15:12:07 <yuval> leon_wang: the same checkpoint should be used for both single and cross site
15:12:15 <leon_wang> What I mean is that no matter user start with a single or multi site, the solution I proposed will be ok.
15:13:21 <leon_wang> yuval: You mean the project_id can not be modified?
15:13:37 <yuval> leon_wang: not sure I understand what you mean
15:14:46 <chenying> I thought that cross-site means different site with one keystone, just is several sites with different AZ.
15:15:02 <leon_wang> yuval: You can consider it when we use iphone, after the cellphone reboot,it would forcely need user to input the password.
15:15:18 <chenying> But as saggi said, these tenant maybe is from different keystone.
15:15:40 <yuval> chenying: in Ocata design summit we thought about limiting to a federated keystone
15:16:07 <leon_wang> So the cross-site is about Karbor or OpenStack?
15:17:57 <chenying> How to control the access permission about the checkpoint data? Does it means that every tenant can restore the same checkpoint data to a new site?
15:18:03 <leon_wang> yuval: As you showed the demo in the summit, the cross-site means different Keystone or one Keystone?
15:18:30 <yuval> leon_wang: in the summit, two completely different sites were presented. But no isolation was there
15:18:37 <chenying> These tenants come form different openstack(keystone)/
15:18:54 <leon_wang> chenying:every tenant can access the checkpoint by project_pwd.
15:18:55 <yuval> leon_wang: it means that if one site sees the same bank as the other, it can access all checkpoints (which is not desireable)
15:20:56 <yuval> however, we did say that there is the use case of non federated, separate keystone services
15:21:42 <leon_wang> yuval: I think that if user from other Keystone uses Karbor, the checkpoint_pwd will gurantee him to get access to his checkpoints.
15:21:57 <chenying> leon_wang: site a is down. I don't think another tenant can acess the bank with  project_pwd of site A.
15:23:30 <leon_wang> chenying:I mean if the site is down,then the identity about project_id will not work, then user can use project_pwd.
15:24:01 <saggi> leon_wang: Try and find me on IRC tomorrow and we'll talk about the requirements and your spec so that we can finish it quickly. OK?
15:24:01 <chenying> what is project_pwd?
15:24:02 <leon_wang> the project_pwd is created when a user creates a checkpoint.
15:24:29 <saggi> leon_wang: I'll bring you up to speed with all the requirements and constraints.
15:24:50 <leon_wang> chenying:when user A uses the system the first time, the system will generate a uuid corresponding with every project_id and then return it to user. You can consider it as a kind of password(can be modified by users?) with project_id.
15:25:08 <leon_wang> saggi: ok, thanks.
15:25:19 <saggi> #topic Protection Plugin API: https://review.openstack.org/397156 and https://review.openstack.org/348163 (yuval?)
15:25:44 <yuval> yes, I'm updating the spec as well as implementation of the protection plugin api
15:26:39 <yuval> it is important for Ocata, please dedicate some time to review it so we can get it in before the end of Ocata
15:26:42 <leon_wang> yuval: It seems the link doesn't work.
15:26:57 <chenying> yuval: I will review these patches tomorrow.
15:27:04 <yuval> leon_wang: both links work for me
15:27:12 <saggi> [ https://review.openstack.org/397156 ] and [ https://review.openstack.org/348163 ]
15:27:37 <leon_wang> Got it
15:28:28 <saggi> yuval: Anything more you want to say about it?
15:28:43 <yuval> that's it for now
15:28:59 <saggi> #topic The road to stability
15:29:20 <saggi> I don't see people opening or closing bugs.
15:29:49 <leon_wang> yuval:can you simply describe what you will do, please?
15:31:02 <yuval> leon_wang: in the patches above? The intention is to stabilize the Protection Plugin API, and have it enable both simple and extreme use cases
15:31:06 <leon_wang> saggi: Sorry I had to prepare for my exam last two weeks, I will check the bug I reported these days.
15:32:52 <leon_wang> ok.
15:33:40 <saggi> I'm also to blame and I am going to start taking stock and opening bugs for stuff that I find need to be fixed.
15:33:45 <saggi> The small things do count.
15:34:02 <saggi> Please make sure to check the bug list
15:34:25 <saggi> #topic open discussion
15:34:39 <saggi> Anyone has anything they want to talk about?
15:35:09 <leon_wang> Yes, i have a tiny question.
15:35:53 <leon_wang> I just want to know if it's difficult to call REST API of Cinder.
15:36:06 <saggi> In general?
15:36:20 <leon_wang> How to implement it?
15:36:45 <saggi> In Karbor?
15:36:47 <chenying> I don't think so. We can use client of cinder in karbor.
15:37:03 <leon_wang> For example, if I want to create a volume, then how can i call the get() in Cinder?
15:37:42 <leon_wang> chenying: If don't use client?
15:37:59 <smcginnis> leon_wang: There's the API docs.
15:38:06 <leon_wang> chenying: sorry, If don't use Karbor?
15:38:09 <smcginnis> leon_wang: But best to use the cinderclient library.
15:38:36 <smcginnis> leon_wang: But this sound like it's not related to karbor, so if you have questions about cinder, please ask in #openstack-cinder or #openstack-dev.
15:38:46 <chenying> We can use the cinderclient library. don't need use it in karbor.
15:38:53 <saggi> leon_wang: Do you want to call cinder from a protection plugin?
15:38:54 <leon_wang> smcginnis: If I want to create a tiny program, is it difficult?
15:39:59 <smcginnis> leon_wang: Usually no.
15:40:25 <leon_wang> saggi: no
15:41:54 <leon_wang> I don't know if the project out of OpenStack can call REST API in Cinder or Karbor?
15:42:40 <saggi> leon_wang: I don't think it's related to this meeting in any case. I think http://docs.openstack.org/developer/python-cinderclient/ is a place to start
15:43:15 <leon_wang> saggi: ok, thanks
15:43:39 <saggi> Anything else?
15:44:45 <leon_wang> saggi: no
15:44:59 <chenying> saggi  Is there any progress about freezer integration?
15:45:40 <saggi> chenying: Oh, right
15:45:44 <saggi> I was in their meeting
15:46:13 <saggi> The support invoking freezer without setting up a job first. What we call (stateless)
15:46:30 <saggi> It will not put information in the freezer DB etc. This is good since we want to own that informatino.
15:46:39 <saggi> So on that front things are good.
15:47:14 <saggi> About not having to install freezer-scheduler on every node. They are thinking about supporting that but it's still early.
15:47:38 <saggi> This means that for anyone to get guest cooperation they will need to fully deploy freezer.
15:47:46 <saggi> At least for now
15:48:30 <chenying> saggi I see. That mean that only the restfull api of freezer can be called in karbor?
15:48:58 <saggi> That is all we need
15:50:05 <chenying> saggi: Ok we only consider integrate the solution about app protection?
15:50:15 <chenying> in freezer
15:51:12 <saggi> We don't need their storage since we can just put it in the bank and we don't need their full volume feature since we do it anyway.
15:51:16 <saggi> What else is there?
15:52:54 <chenying> Ok we can discuss freezer tomorrow in karbor irc channel.
15:53:05 <saggi> OK
15:53:09 <saggi> Anything else?
15:54:00 <chenying> nope
15:54:33 <saggi> Thanks everybody.
15:54:33 <saggi> #endmeeting