16:00:10 <schwicke> #startmeeting hierarchical_multitenancy
16:00:11 <openstack> Meeting started Fri Jul  4 16:00:10 2014 UTC and is due to finish in 60 minutes.  The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:14 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
16:00:33 <schwicke> here we go
16:00:39 <sajeesh> ok
16:00:50 <schwicke> #info welcome to nirbhay
16:01:15 <schwicke> there are a couple of things to be discussed I think
16:01:19 <nirbhay> thanks schwicke
16:01:23 <raildo> #info welcome to rodrigods
16:01:33 <rodrigods> hi all
16:01:35 <raildo> he work with me
16:01:38 <sajeesh> In raildo's blueprint it has been written that,domain_id will renamed to parent_project_id. Whether domains will be dropped ?
16:01:59 <schwicke> #info welcome to rodrigods !
16:01:59 <sajeesh> hi rodrigods..welcome
16:02:30 <schwicke> let's start with the design document I suggest
16:02:35 <rodrigods> thanks, please continue
16:02:40 <sajeesh> ok fine
16:02:52 <schwicke> #topic discussion of the design document circulated by Sajeesh
16:03:12 <raildo> The concept domain is not removed, it is the root of the hierarchy.
16:03:53 <schwicke> I understand though that there are no specific quotas for domains to be implemented, right ?
16:03:57 <raildo> what is being proposed is using only use the domain_id column as parent_project_id.
16:03:59 <sajeesh> ok
16:04:42 <raildo> I think the problem is that the other services do not know domain
16:04:53 <sajeesh> ok
16:05:51 <rodrigods> schwicke, right, AFAIK
16:06:06 <schwicke> I think so
16:06:51 <schwicke> for the initial implementation I'd be tempted to ignore the domain from the quota perspective.
16:07:07 <sajeesh> +1
16:07:17 <raildo> +1
16:07:28 <rodrigods> ++
16:07:28 <schwicke> ok, so lets do that
16:08:02 <raildo> in future, we can think in use this BPs https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api , https://blueprints.launchpad.net/nova/+spec/domain-quota-driver
16:08:05 <schwicke> #AGREED no special treatment of domains is implemened for nova. We'll just ignore them for now
16:08:20 <schwicke> #link https://blueprints.launchpad.net/nova/+spec/domain-quota-driver-api , https://blueprints.launchpad.net/nova/+spec/domain-quota-driver
16:08:24 <schwicke> ok
16:08:31 <schwicke> let's move on
16:08:34 <raildo> ok
16:08:45 <sajeesh> schwicke shall we discuss about getting the parent projects
16:08:54 <schwicke> there was a discussion about how far up we need to go in the tree
16:09:00 <schwicke> sajeesh: yes
16:09:14 <schwicke> #topic getting the parent projects
16:09:33 <sajeesh> schwicke,that depends on the role of person who is acting on the child project
16:09:57 <schwicke> so let's say we have a user of project E with rights in C, D by inheritance
16:10:27 <schwicke> The question is if he needs to know about A and B or not. And that depends on which kind of quota we are storing
16:10:44 <schwicke> did I get it right ?
16:10:50 <raildo> yes
16:10:51 <sajeesh> yes
16:11:16 <rodrigods> if it doesn't know about A and B, if it creates a new instance in E, there is an inconsistence problem over there
16:11:25 <sajeesh> evenif he knows about A and B,he cannot do anything on it.
16:11:25 <raildo> +1
16:11:26 <schwicke> I think if we store the used quota at the project level then we have to go up to the root
16:11:33 <raildo> rodrigods: +1
16:12:16 <sajeesh> shwicke, can you please eloborate that point
16:12:25 <schwicke> rodirgods: can you give an example ?
16:13:11 <schwicke> I think the used quota can be obtained on the fly by summing the usage of the current project plus all its children, right ?
16:13:21 <schwicke> So there is no need to store that
16:13:30 <rodrigods> schwicke, ++
16:13:52 <schwicke> We need to store the limit at each project level
16:14:15 <raildo> schwicke: i agree
16:14:16 <rodrigods> if A has 100 of free quota, C has quota 10. An user with a role in C and D requests a new instance in C with quota 10. Shoudn't the free quota from A be updated to 90?
16:14:27 <schwicke> but if John changes the quota in C, D or E that does not affect the total quota in A or B, right ?
16:15:02 <raildo> if C, D, E are childrens of B and A, should be changed.
16:15:19 <schwicke> The free quota is the limit minus the used quota, isn't it ?
16:15:31 <schwicke> so no need to store that either so noting to update in A
16:15:38 <sajeesh> rodrigods,a user having a role in A  should update it
16:15:40 <schwicke> correct me if I'm wrong guys!
16:16:08 <rodrigods> sajeesh, manually?
16:16:16 <schwicke> I think that the only quota that we need to store is the limit
16:16:19 <sajeesh> yes
16:16:35 <sajeesh> rodrigods,yes
16:17:01 <schwicke> What we have to check though if John updates C is that the usage of B is not exceeded.
16:17:22 <rodrigods> schwicke, ++
16:17:27 <schwicke> So it should be enough to know the children and the immediate parent
16:17:29 <schwicke> right ?
16:17:34 <sajeesh> rodigods,scope of a user is limited upto the project he has role.Beyond that automatic updation cannot happen
16:17:47 <rodrigods> schwicke, right
16:18:15 <raildo> IMO, the problem here is independent of the role. The problem is to maintain the consistency of data.
16:18:16 <sajeesh> shwicke,children should know about immediate parent only
16:19:08 <raildo> If you do not update A and B, apparent that C, D, E are not part of the hierarchy, which is not true.
16:19:47 <schwicke> we agree that A is the root of the tree in this example, right >?
16:19:47 <sajeesh> raildo,a user having no role in A and B cannot update it
16:20:21 <schwicke> raildo: can you give an example where this can go wrong ?
16:20:45 <rodrigods> sajeesh, the update is not made by the user, IMO. Once a user request some quota from below the hierarchy, this change should be reflected through its parents
16:21:03 <raildo> Imagine if we'd quota domain and projetc. This would be like to create an instance, I would update the quota project and not update the quota field. That would be wrong.
16:22:33 <raildo> sajeesh: Why not? Even though he did not rule on that project, he is a child (or grandchild, or whatever) it.
16:23:50 <sajeesh> raildo, shwicke shall we discuss this matter through detailed email
16:24:11 <raildo> sajeesh: ok, no problem
16:24:13 <schwicke> I think we should try to sort that out.
16:24:19 <schwicke> It's pretty important
16:24:21 <sajeesh> ok fine...thanks
16:24:29 <sajeesh> it is very very important
16:24:37 <rodrigods> let's elaborate a simple example
16:24:44 <schwicke> Yes.
16:24:50 <rodrigods> an hierarchy like? A -> B -> C
16:24:54 <schwicke> fine
16:24:57 <sajeesh> ok
16:24:58 <schwicke> restart from scratch
16:25:00 <rodrigods> user1 has role member in B and C
16:25:03 <schwicke> So A is the root
16:25:12 <rodrigods> and user2 has role member in A, B and C
16:25:36 <schwicke> define "member"
16:25:54 <rodrigods> schwicke, a role that has permissions to create instances, for example
16:26:01 <schwicke> ok
16:26:02 <sajeesh> ok
16:26:11 <nirbhay> ok
16:26:12 <schwicke> that does not give you the right yet to create a sub-project, does it ?
16:26:30 <rodrigods> schwicke, let's say no
16:26:38 <schwicke> OK
16:26:48 <rodrigods> quotas: A=100, B=50, C=25
16:27:15 <schwicke> Quota of A can only be changed by the cloud admin
16:27:37 <rodrigods> schwicke, yeah
16:27:45 <schwicke> Let's distinguish 2 roles:
16:28:00 <schwicke> A member can only create VMs within the projects to which he belongs
16:28:13 <schwicke> A project admin can create sub-projects and set their quotas
16:28:14 <schwicke> OK ?
16:28:17 <rodrigods> ok
16:28:20 <sajeesh> ok
16:28:52 <rodrigods> let's say user1 with role member, creates an instance in C that uses 15 of quota
16:29:02 <sajeesh> ok
16:29:03 <schwicke> ok
16:29:08 <rodrigods> what happens with the free quota from the role tree?
16:29:20 <rodrigods> whole tree*
16:29:40 <raildo> A= 85, b=35, c=10?
16:29:41 <schwicke> nothing
16:30:00 <schwicke> The quota values are the ceilings. They stay as they are
16:30:18 <schwicke> Let's say the quota is in number of VMS
16:30:24 <sajeesh> it depends on how much free quota C is having
16:30:44 <rodrigods> free quota, I meant
16:30:54 <schwicke> so anybody belonging to C can still create instances consuming 10 quota
16:31:06 <raildo> in the case od rodrigods, that would be the free quota of each project.
16:31:13 <nirbhay> ok
16:31:36 <sajeesh> ok....it C is having free quota of 25,then if it uses 15 ,then there will no change in the tree
16:31:39 <schwicke> yes, we need to decide on what we want to store here.
16:32:43 <sajeesh> free quota of C will get reduced to 10
16:32:51 <schwicke> yes
16:32:53 <raildo> schwicke: Currently in Nova, there are three tables for quotas: Quotas, quota usage, reservations. You do not intend to follow the same pattern?
16:33:44 <schwicke> hmm
16:33:55 <schwicke> we probably have to
16:34:18 <sajeesh> I want to add allocation...but that need to be decided
16:34:47 <schwicke> sajeesh: I think raildo is right. If we already have the quota usage at each level then we need the full tree ...
16:35:20 <rodrigods> schwicke, ++
16:35:41 <raildo> schwicke: I believe that you understood what I wanted to say.
16:35:42 <schwicke> I'd prefer if we could retrieve the usage on the fly instead
16:36:04 <rodrigods> schwicke, yeah, that approach ltgm
16:36:14 <schwicke> thinking loud ... that would be a major change which we should avoid
16:36:22 <sajeesh> schwicke ,raildo  as I said I require a detailed discussion before we freeze the design
16:37:02 <sajeesh> through mail....shall we freeze the design in our next meeting
16:37:10 <schwicke> what I don't like very much is that I see the risk that the used quota gets out of date
16:37:31 <schwicke> we can have a summary on this by e-mail.
16:37:39 <raildo> schwicke: ok
16:37:43 <sajeesh> ok
16:38:03 <sajeesh> I will write a more detailed documentation
16:38:04 <schwicke> sajeesh: the point is that if we have to store the used quota that value will always change even at the root of the tree
16:38:15 <sajeesh> ok
16:38:30 <schwicke> ok, let's summaries the disucssion via e-mail
16:38:37 <sajeesh> ok
16:38:54 <rodrigods> please add me as CC: rodrigods@lsd.ufcg.edu.br
16:38:55 * schwicke summarize the used quota issue via e-mail
16:39:14 <sajeesh> rodrigods,sure
16:39:20 <schwicke> #ACTION: summarize the used quota issue via e-mail
16:39:24 <schwicke> (sorry)
16:39:42 <schwicke> is there any other issue which is blocking finalizing the design ?
16:39:55 <sajeesh> no
16:40:31 <sajeesh> we will be able to freeze the design in our next meeting
16:40:41 <schwicke> I'd be tempted to say that we have to go for a full tree access and update the used quota each time a new instance is created, and later on see if that can be improved by getting this info on the fly
16:41:02 <schwicke> So let's move on
16:41:06 <raildo> rodrigods is implementing the delete project in the hierarchy, as we discussed. I believe that he can speak a little of how it's going.
16:41:12 <sajeesh> shwicke,I will think about it
16:41:20 <sajeesh> ok
16:41:44 <raildo> #topic delete project
16:42:09 <schwicke> I think the idea was to restrict ourselves in the first iteration to have only the option to delete the leaves, right ?
16:42:25 <sajeesh> yes
16:42:47 <rodrigods> yeah
16:43:41 <rodrigods> we only have to check whether the target "project_id" is parent_project_id from another project
16:43:58 <schwicke> correct
16:44:02 <sajeesh> right
16:44:04 <rodrigods> that's almost complete, but has the dependency of the changes in the project table
16:44:12 <sajeesh> ok
16:44:13 <rodrigods> if a new column parent_project_id will be added
16:44:36 <rodrigods> or if domain_id will be renamed and the data from domains table migrated
16:45:00 <schwicke> rodrigods: this is in keystone,right ?
16:45:07 <raildo> schwicke: yes
16:45:11 <schwicke> ok
16:45:45 <schwicke> I wonder if we should touch the domain stuff
16:46:31 <sajeesh> for the time being,I think we should not touch
16:47:14 <raildo> +1
16:47:18 <rodrigods> ok
16:47:21 <rodrigods> makes sense to me
16:47:29 <rodrigods> add a new column, then
16:47:52 <schwicke> by feeling would be taht renaming the domain_id is calling for trouble
16:47:59 <schwicke> s/taht/that/
16:48:01 <schwicke> :)
16:48:17 <sajeesh> yes
16:48:39 <schwicke> so shall we go for that ?
16:49:04 <raildo> I had thought of this solution first, but ayoung, dolphm, asked me to make this change. But I'm more relaxed creating a new column.
16:49:45 <rodrigods> if keystone folks step the foot in renaming, we can do that, but let's not touch in it for now
16:49:50 <rodrigods> makes sense?
16:49:52 <schwicke> hope then they will accept this
16:49:58 <sajeesh> +1
16:50:02 <raildo> yes
16:50:10 <schwicke> +1
16:50:14 <schwicke> #AGREED don't touch the domain stuff in keystone but rather add a new column for the parent project
16:50:22 <schwicke> 10min left
16:50:24 <raildo> I'll update the spec
16:50:27 <schwicke> ok
16:51:06 <raildo> we have something else to discuss?
16:51:18 <schwicke> I think we still need to clarify about using keystone API V3
16:51:32 <schwicke> #topic keystone API version to be used
16:51:35 <sajeesh> yes
16:51:51 <schwicke> my understanding is that we don't have much of a choice here, do we ?
16:52:11 <rodrigods> ++
16:52:14 <sajeesh> I am afraid,no
16:52:23 <raildo> to use Inherited roles  is necessary using keystone API v3
16:52:30 <sajeesh> ok
16:52:33 <schwicke> +1
16:52:37 <raildo> there is no other option.
16:52:44 <sajeesh> ok
16:52:47 <schwicke> #AGREED: we have to use keystone API V3
16:52:51 <sajeesh> +1
16:52:57 <raildo> +1
16:53:04 <schwicke> for the next meeting I think we need to think a bout about roles
16:53:10 <schwicke> can prepare this via e-mail
16:53:23 <sajeesh> yes I will send a detailed document
16:53:28 <schwicke> that's coming back to our inital discussion
16:54:10 <schwicke> sajeesh: we could be a bit more explicit on that in your design document eventually.
16:54:25 <sajeesh> schwicke,sure
16:54:30 <schwicke> Anything else for today ?
16:54:44 <sajeesh> nothing
16:54:52 <schwicke> I have something
16:54:54 <raildo> let's go watch the world cup!
16:54:57 <raildo> =]
16:54:59 <schwicke> #TOPIC meeting time
16:55:19 <schwicke> is everybody comfortable with the time of the meeting ?
16:55:28 <sajeesh> I am ok
16:55:44 <schwicke> for me it clashes a bit with dinner. Not a big issue though
16:55:47 <raildo> no :(  Here in Brazil this time is not very comfortable.
16:56:00 <rodrigods> schwicke, lunch time here
16:56:09 <schwicke> shall we have it one hour earlier ?
16:56:20 <schwicke> think about it. We'll see next week
16:56:29 <sajeesh> ok
16:56:34 <raildo> maybe, 2 hours?
16:56:47 <raildo> would be perfect for us.
16:56:49 <schwicke> that would be 4pm in Geneva
16:56:53 <schwicke> would be good for us
16:57:00 <sajeesh> 2 hours will be difficult for me ..one and a half hours ?
16:57:01 <rodrigods> and 11am in Brazil
16:57:16 <schwicke> right, we have to think about India as well :)
16:57:25 <raildo> yes
16:57:30 <schwicke> let's discuss offline
16:57:36 <raildo> yeah
16:57:42 <rodrigods> yeah
16:57:43 <sajeesh> yes
16:57:46 <schwicke> #agreed : discuss better timing offline
16:57:50 <schwicke> #endmeeting