21:00:54 <vishy> #startmeeting Hierarchical Multitenancy
21:00:55 <openstack> Meeting started Fri Jan 31 21:00:54 2014 UTC and is due to finish in 60 minutes.  The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:58 <openstack> The meeting name has been set to 'hierarchical_multitenancy'
21:01:15 <vishy> #link https://wiki.openstack.org/wiki/HierarchicalMultitenancy
21:01:26 <vishy> #topic Role Call
21:01:32 <vishy> who is here for the meeting?
21:01:39 <gabrielhurley> \o
21:01:42 <vishy> o/
21:01:44 <florentflament> hi
21:01:46 <VINOD_> hi
21:01:55 <dolphm> o/
21:01:56 <schwicke> hi
21:02:34 <vishy> did everyone get a chance to read the wiki?
21:02:36 <vishy> https://wiki.openstack.org/wiki/HierarchicalMultitenancy
21:02:42 <VINOD_> yes
21:03:10 <florentflament> yes, had a look
21:03:12 <bknudson> hi
21:03:13 <vishy> i think the use case there gives us a good starting point
21:03:17 <schwicke> had a look
21:03:24 <vishy> #info Martha, the owner of ProductionIT provides it services to multiple Enterprise clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and Development teams with many users. Joe needs the ability create users projects, and quotas, to list and delete resources across WidgetMaster. Martha needs to be able to set
21:03:25 <vishy> quotas for WidgetMaster and SuperDevShop, manage users, projects, and objects across the entire system, and set quotas for the client companies as a whole. She also needs to ensure that Joe can't see or mess with anything owned by Sam.
21:04:12 <vishy> i think that clearly states the use case that I am trying to enable
21:04:56 <ayoung> and what part of that doesn't work now
21:05:24 <vishy> the biggest problem in what exists today regarding roles and domains is that there is no way to enable the "domain admins" to control resources from their domain
21:05:31 <florentflament> If I understand well, the idea behind the US, would be to have some kind of recursive domain ?
21:05:38 <vishy> they would have to manually join and login to each project
21:05:49 <dolphm> florentflament: recursive tenants/projects
21:05:51 <vishy> in order to control them
21:05:52 <ayoung> we have the inherit extension now
21:06:00 <florentflament> dolphm, agree
21:06:20 <vishy> ayoung: so inheritance allows for some basic functionality
21:06:29 <vishy> i.e. the domain admin could have a role in every project
21:06:49 <tiamar> vishy: yes
21:06:49 <gyee> is there a use case for more than 2 levels deep?
21:06:54 <vishy> but the only way of listing all instances in a domain would be to get a list of all projects from keystone and list all of them individually and aggregate
21:07:04 <vishy> gyee: i think there is but I'm leaving that aside for the moment
21:07:10 <bknudson> are these hierarchical roles?
21:07:11 <ayoung> al iinstances of a vm?
21:07:27 <vishy> yes all virtual machines
21:07:41 <vishy> so under Potential Solutions I have this listed
21:07:49 <vishy> "Remove Cross-Project Functionality"
21:08:05 <vishy> we could just say, sorry you always have to authenticate per project for resources
21:08:16 <schwicke> gyee: yes, we do have such use cases
21:08:17 <vishy> which I think is horrible user experience but it roughly works today
21:08:24 <dolphm> bknudson: no
21:08:44 <vishy> so I personally believe that multiple levels is what we really want
21:08:55 <vishy> but I want to prove that this can work before we have that discussion
21:08:57 <tiamar> vishy: we could bring domain scoped token to openstack, that improves the user experience
21:09:24 <vishy> tiamar: I think that is the wrong approach personally, but let me expand on my proposal for now
21:09:36 <gabrielhurley> fwiw, I'm with vishy that multiple levels is the meets-all-needs solution, but that getting there is a lot harder and some intermediate steps might be helpful
21:10:08 <vishy> so one of the issues is figuring out how a hierarchical structure would work inside of the projects
21:10:17 <vishy> regardless of whether this is domain.project
21:10:24 <vishy> or project.project.project etc.
21:10:39 <vishy> i.e assuming I have a broader grouping of objects than a project
21:10:44 <gyee> vishy, then there's really no distinction between domain and project then
21:10:44 <vishy> how do I support that in code
21:10:50 <vishy> gyee: correct
21:11:05 <vishy> gyee: which is why i think hierarchical projects removes the need for domains
21:11:09 <dolphm> vishy: ++
21:11:15 <vishy> but that is something that is orthogonal to this proposal
21:11:20 <bknudson> domains are the namespaces not really grouping
21:11:20 <dolphm> a "domain" basically becomes a project with no parent project
21:11:24 <gyee> vishy, I suppose there's always a root project, which is formerly known as domain?
21:11:27 <dolphm> a "root project"
21:11:36 <gyee> dolphm, ha
21:11:44 <vishy> gyee: we would have a root project for sure
21:11:46 <bknudson> are you going to allow users with the same name in different projects?
21:11:50 <vishy> but again not important to decide now
21:12:13 <vishy> i don't want to digress into domains vs. projects because it is unimportant for this discussion
21:12:21 <dolphm> bknudson: identity domains and authorization domains are really two separate issues -- i'm hoping we can ignore identity domains for the sake of this conversation
21:12:26 <vishy> i want to prove that multiple levels of ownership works in the projects
21:12:38 <vishy> currently we have a single "owner" field in nova
21:12:51 <vishy> it is called project_id in most places
21:12:52 <gabrielhurley> gyee: "domain" has never been anything more than an arbitrary different name for a 2-level hierarchy, instead of moving to an N-level hierarchy
21:13:19 <gyee> gabrielhurley, I am not critical on names :)
21:13:24 <gabrielhurley> +1
21:13:28 <vishy> gabrielhurley: it has a few unique qualities as well, shuch as namespacing unique users
21:13:36 <gyee> call it whatever, as long as it functions consistently
21:13:37 <gabrielhurley> fair
21:13:46 <dolphm> the obvious but inelegant solution is to expose a call in keystone to ask "is this resource's owner a subset of this authorization scope?" (letting keystone track the hierarchy)
21:13:46 <vishy> ok so here is the basic plan i have
21:14:05 <dolphm> that would get hammered a lot, but it could be a cacheable HEAD request
21:14:06 <VINOD_> I think, its look ok to scrap domain and have a hierachical structure of projects...but I guess moving to this is quite difficult than having domains and having maximum of 3 levels of hierachy i.e domains -> Tenants -> Users at this moment
21:14:06 <vishy> dolphm: yeah I think that is a nasty performance choice
21:14:23 <vishy> dolphm: let me cover my proposal
21:14:34 <dolphm> vishy: go for it, i just wanted to get that out of the way :)
21:14:38 <vishy> so i want to make a branch of devstack/nova
21:14:49 <vishy> that can test this without actually modifying keystone
21:15:06 <vishy> i will create some feaux heirarchies using . as a separator
21:15:19 <vishy> so I will have a project called companya.foo
21:15:27 <vishy> another one called companyb.foo
21:15:37 <vishy> companya.bar
21:15:41 <vishy> companya
21:15:44 <vishy> companyb
21:15:52 <vishy> and corresponding users
21:16:04 <vishy> so this doesn't deal with role inheritance or anything like this
21:16:31 <vishy> but i want to prove that a user who authenticates to companya can list/delete in companya.bar and companya.foo
21:16:34 <gyee> vishy, that would make . forbidden in any names
21:16:35 <vishy> but nothing in companyb
21:16:37 <vishy> etc.
21:16:44 <vishy> gyee: I am aware of that
21:16:50 <vishy> but this is just a prototype
21:17:01 <vishy> keep in mind that the reall enforcer will actually be the id
21:17:12 <vishy> so they will have matching <uuid>.<uuid>
21:17:13 <vishy> ids
21:17:14 <vishy> etc.
21:17:29 <vishy> so the real requirement is that . is not allowed in ids
21:17:31 <VINOD_> But what about delegate some user as admin at companya.bar so that he can further creates sub projects...if you go like this, then hierachy keeps on growing and implementing through policy.json will be difficult
21:17:34 <dolphm> so, tracking and enforcement of the hierarchy remains distributed
21:17:52 <vishy> dolphm: correct
21:17:56 <gyee> uuid have usability cost, but sure since this is a prototype
21:18:12 <vishy> so there are two things that need to be done in the service to make this work
21:18:37 <vishy> first of all the enforcement of project_id = object.project_id needs to be expanded to a substring/regex match
21:19:00 <vishy> and secondly (the harder one) is to change the enforcement of list operations to actually pass filters into the db
21:19:20 <vishy> so perhaps there is a new type of enforcer in policy similar to rule:
21:19:35 <vishy> that might be regex: or substring: or something
21:19:46 <vishy> so the admin_or_owner check would actually use
21:19:55 <vishy> a partial match on project_id instead of an exact match
21:20:14 <vishy> then to optimize the list case this needs to be preconverted into some kind of sql filter
21:20:17 <bknudson> you're saying they try to list all instances and they only get some instances?
21:20:25 <vishy> bknudson: correct
21:20:33 <vishy> if you outhenticate to companya
21:20:45 <vishy> you get all instances from companya companya.foo companya.bar
21:20:51 <vishy> but none from company.b
21:21:06 <gyee> bknudson, that's how authorization is usually implement, via resource filtering
21:21:10 <vishy> currently the --all-tenants flag just says are you an admin? ok then send everything
21:21:15 <dolphm> vishy: so, how do you *really* list all instances?
21:21:21 <vishy> there is no scoping
21:21:32 <vishy> nova list --all-tenants
21:22:00 <vishy> dolphm: we could leave the "superadmin" role in for filtering but if we convert everything to this model
21:22:06 <vishy> * for no filtering
21:22:06 <VINOD_> then what about somebody authenticating with scope of companya.bar wants to list  instances only under this (not at parent project companya)
21:22:17 <gabrielhurley> the key distinction here is that a user expects list operations to default to "show me everything I have access to unless instructed otherwise" (e.g. the highest scope) and that create operations should default to "create this just for me unless instrcuted otherwise" (e.g. the lowest scope.
21:22:20 <vishy> then it makes sense for the superadmin to actually be the root of the tree
21:22:23 <vishy> i.e.
21:22:28 <gabrielhurley> you can always specify more specific list or create scopes
21:22:29 <vishy> openstack.companya.foo
21:22:32 <gabrielhurley> but the defaults are crucial
21:22:37 <vishy> where openstack is the root
21:22:51 <dolphm> gabrielhurley: ++
21:22:57 <vishy> but that would be a later change. For now we can just leave the superadmin role in place that does no filtering
21:23:02 <gabrielhurley> vishy: +1 on "openstack" being the root
21:23:30 <vishy> gabrielhurley: having a read vs write scope is interesting but initially i think forcing someone to auth at a certain level isn't too horrible
21:23:51 <vishy> gabrielhurley: so short term i would just take that approach
21:24:04 <gabrielhurley> whether the scope is set by explicit auth or API param I don't really care
21:24:07 <vishy> i.e. i can authenticate in project foo
21:24:16 <vishy> or i can go authenticate in openstack and list everything
21:24:36 <gabrielhurley> I'm just telling you what a naive user expects
21:24:44 <dolphm> stray thought: this makes default tenancy in keystone suddenly attractive again, as it's likely that all my projects share a single parent
21:24:46 <vishy> gabrielhurley: i can see people getting confused by seeing stuff from other projects in a list
21:24:55 <gabrielhurley> quite the opposite
21:25:07 <gabrielhurley> people are confused by openstack's rigid scoping and all the context switching
21:25:16 <gabrielhurley> makes it hard find things
21:25:23 <vishy> gabrielhurley: i guess that is true
21:25:26 <gabrielhurley> forces users to keep track of all their scopes in their head
21:25:30 <gabrielhurley> higher mental load/ burden
21:25:32 <vishy> gabrielhurley: you could have something similar to a cwd though
21:25:37 <vishy> representing your scope
21:25:50 <vishy> anyway side point for the future
21:25:54 <lbragstad> ++, that's a cool idea
21:26:09 <vishy> the good news about this approach is that it will work in the projects with fairly minimal changes
21:26:09 <gabrielhurley> users are people, people are self-centered foremost, group-centered secondmost
21:26:14 <gabrielhurley> but this is not cirtical
21:26:18 * morganfainberg is here now
21:26:24 <vishy> and it doesn't force keystone to implement new features before we are sure they are actually valuable
21:26:28 <gabrielhurley> yep
21:26:43 <bknudson> so I create an instance and set its project to openstack.companyA.groupC
21:26:45 <gyee> vishy, ++ on backward compat
21:26:47 <dolphm> vishy: except for maybe user-defined project ID's? and authorization around doing so?
21:27:03 <morganfainberg> vishy, i do like backwards compat
21:27:11 <vishy> now there are a bunch of other issues that will come up as we try and implement and we will know what we need to fix
21:27:26 <vishy> there are unsolved problems like quotas
21:27:28 <leandrorosa> vishy: and about domains? Will it supersede them?
21:27:37 <vishy> dolphm: the prototype version i'm going to just hack the id manually in the db
21:27:49 <vishy> leandrorosa: that is a decision we can make in atlanta
21:28:06 <vishy> the output of this experiment would be a summit discussion and a clear proposal
21:28:32 <morganfainberg> leandrorosa, it might supersede some aspects of domains but likely not all, we will need to evaluate the prototype to see what ends up
21:28:41 <vishy> dolphm: if the experiment is successful than i see keystone walking the hierarchy and sending a parameter called scope
21:28:46 <leandrorosa> vishy: +1
21:28:54 <tiamar> vishy: CERN wishes to implement quota delegation - I think it comes handy now
21:28:56 <vishy> which would include the dot.separated.hierarchy
21:28:59 <dolphm> vishy: sending where / when ?
21:29:00 <bknudson> I thought the token already had the scope.
21:29:09 <vishy> dolphm: along with project_id
21:29:16 <vishy> maybe it needs a different name
21:29:27 <schwicke> tiamar: correct
21:29:27 <vishy> basically the entire hierarchy of the project
21:29:33 <vishy> which could be domain.project today
21:29:42 <vishy> or it could be project.project.project
21:29:48 <morganfainberg> vishy, scope is heavly used already. so a different name would be good, or we supplant the current "scope" concept
21:29:56 <vishy> openstack.company.business_unit.project
21:29:57 <gabrielhurley> ++ to all this scope stuff
21:30:02 <dolphm> vishy: would that not just be the project_id = grandparentproject.parentproject.project ?
21:30:05 <gabrielhurley> name notwithstanding
21:30:09 <vishy> fair enough call it hierarchical_context
21:30:15 <vishy> dolphm: that is exactly what it is
21:30:33 <vishy> my point is that the project in the database doesn't need the . in that case
21:30:46 <dolphm> ah
21:30:50 <vishy> it is constructed by keystone and sent along with roles / etc.
21:31:03 <vishy> so user-defined project ids isn't necessary
21:31:23 <bknudson> so what are you thinking the auth request looks like?
21:31:37 <ayoung> domain is a top level container that can contain projects and users.  Projects can be hierarchical without removing the usefulness of domains.
21:31:41 <vishy> bknudson: which auth request? communication with keystone?
21:31:49 <morganfainberg> ayoung, ++
21:31:50 <bknudson> vishy: yes, to keystone to get the token.
21:31:52 <gyee> dolphm, any idea what does it look like potentially, for service-scope?
21:32:00 <vishy> ayoung: that is fine by me, as I said beyond the scope of this experiment
21:32:09 <ayoung> I think we would still keep the idea that VMs etc must be in a projectr, not just a domain
21:32:28 <vishy> ayoung: sure that is ok if you want distinction there
21:32:39 <ayoung> then we just scope this down to "hierarchical projects"
21:32:55 <dolphm> gyee: i don't think this impacts service-scoped tokens, if that's what you're referring to
21:33:07 <morganfainberg> gyee, i think that it wont change anything we're talking about on that front.  "service scope" is not exactly related to what nova is doing here.  remember service-scope was non-project related
21:33:08 <vishy> ayoung: fine by me
21:33:22 <ayoung> service scoped tokens could benefit from this as well. Put services inside a project....
21:33:34 <ayoung> everything that needs to be managed goes in a projects
21:33:34 <schwicke> ayoung: is there any use case that cannot be covered with purely hierarchical projects ?
21:33:42 <vishy> ayoung: i think to make this valuable the projects need to inherit some of the functionality that you stuck in domains though
21:33:59 <vishy> i.e. i think the right answer is that every user needs to have a maximum hierarchical scope
21:34:00 <ayoung> schwicke, it solves all things for all users everywhere using all languages on all platforms
21:34:13 <vishy> but it shouldn't be a separate concept
21:34:16 <dolphm> vishy: no delegation outside that scope?
21:34:21 <vishy> ayoung: my rationale is the following
21:34:30 <vishy> you use domains to control adding users to projects yes?
21:34:41 <vishy> you need to use the heirarchy for that
21:34:53 <ayoung> "assigning user sroels in projects"
21:34:58 <vishy> yes
21:35:22 <ayoung> so you want to be able to delegate the ability to delegate
21:35:22 <vishy> but anyway we could rathole on that particular point forever
21:35:36 <vishy> ayoung: right the ability to delegate should be a role in the hierarchy
21:35:43 <ayoung> in my could, you can create a project, and assign admin rights in the project to dolphm
21:35:48 <vishy> for example assign_role should be a role that you get somewhere in the tree
21:36:03 <vishy> and you have that role for anything below that location in the tree
21:36:27 <vishy> and if you go that far, i "think" the only thing that domain gives you is namespacing of users
21:36:28 <schwicke> +1
21:36:36 <gyee> vishy, you mean project-specific role definition?
21:36:47 <vishy> and you could do namespacing of users via something like the highest point in the tree where they have a role
21:36:55 <vishy> or even an explicit role called namespace or some such
21:36:58 <dolphm> vishy: thus you can assign/delegate that role to any other user for any subset of the project hierarchy?
21:37:06 <ayoung> domain is a top level namespace.  We could have implemented domains as nested projects.  I think someone even suggested that.
21:37:35 <gabrielhurley> that was me that duggested that
21:37:39 <gabrielhurley> *suggested
21:37:42 <dolphm> ayoung: we both did :)
21:37:54 <dolphm> both supported* it lol
21:37:56 <vishy> ayoung: i think the best approach would be a) see if this nested idea works in the non-keystone services b) implement nested projects if it works c) consider replacing domains if they are no longer necessary
21:38:09 <gabrielhurley> +1
21:38:14 <vishy> or else we risk pissing people off :)
21:38:17 <ayoung> vishy, domains will stay.  We have other reasons now for the,m
21:38:19 <ayoung> them
21:38:20 <gabrielhurley> the property of namespacing users and such is an interesting case
21:38:32 <jgriffith> vishy: timeline on your devstack prototype?
21:38:32 <vishy> fair enough
21:38:34 <gabrielhurley> there may be other properties like that
21:38:36 <dolphm> ayoung: i'm not sure we do
21:38:36 <ayoung> for example:
21:38:46 <vishy> jgriffith: I will "start" it this weekend
21:38:50 <vishy> and post on github
21:38:56 <ayoung> oh yes we do....but do you want me to explain now, or save it for the summit?  Its long
21:39:04 <vishy> i hope to have the absolute minimum done my monday
21:39:25 <dolphm> ayoung: identity providers have the opportunity to supersede domains on the authentication side, and hierarchical multitenancy has the opportunity to supersede domains on the authorization side
21:39:29 <vishy> I would appreciate help from others trying it out, refining it, discovering all the random bugs we will fine
21:40:07 <schwicke> vishy: I think we can help there, Vinod to confirm
21:40:09 <jgriffith> vishy: sounds like the best next steps.. thanks
21:40:15 <VINOD_> yes
21:40:24 <vishy> any other comments or concerns?
21:40:24 <schwicke> keen on it actually
21:40:25 <jgriffith> and yeah, I'll try and help where I can
21:40:26 <ayoung> vishy, so the big thing to watch out for is the logic in querying nested things.  Databases don't do that well
21:40:35 <vishy> #action vishy to prototype devstack/nova this weekend
21:40:42 <vishy> ayoung: yeah i have some concerns about that
21:40:45 <VINOD_> But i do agree with ayoung, that domains are necessary
21:40:45 <ayoung> and applying things based on hierarchy can be nasty....there are a lot of details to get right
21:41:05 <vishy> i'm going to try something simple and see what breaks
21:41:09 <gyee> ayoung, you mean like performance? :)
21:41:11 <ayoung> Hey, lets rename projects to domains and mess everyone up
21:41:16 <vishy> i'm hoping to make minimul changes to the policy checks in nova
21:41:24 <vishy> but i think i will have to invert some of them
21:41:24 <dolphm> vishy: can you provide a link in the original -dev thread?
21:41:29 <vishy> ayoung: +1
21:41:35 <vishy> a link to the github?
21:41:38 <dolphm> ys
21:41:39 <dolphm> yes
21:41:40 <vishy> absolutely
21:41:59 <schwicke> yes
21:42:01 <ayoung> vishy, so long as project are referred to by ID and not by name, there should be no change
21:42:21 <ayoung> the calculation of roles for a user on a project will be more expensive at token creation time
21:42:40 <vishy> ayoung: for usability in this version I'm going to use the "hack" of showing the heirarchy in the project name
21:42:52 <VINOD_> vishy..do you mean that you will implement this and post it on github and do testing from our side
21:42:58 <ayoung> vishy, that is fine, but policy enforcement is done on projectId not name
21:43:10 <vishy> ayoung: right, but login is done via name
21:43:18 <vishy> so i need to modify both for the prototype
21:43:24 <morganfainberg> vishy, can be done by either iirc
21:43:33 <ayoung> vishy, leave users in domains out of it, and let people log in using their existing mechanisms
21:43:48 <ayoung> authorization and authentication are two separate things and should be managed separately
21:44:00 <gabrielhurley> +1
21:44:08 <schwicke> +1
21:44:16 <gabrielhurley> the authentication problem spent too much of its history being painful already
21:44:16 <VINOD_> +1
21:44:18 <ayoung> IR.  let the user create an account (self registration) and then add that account to the project via a role
21:45:25 <ayoung> vishy, you with me?  See the distinction?
21:45:46 <VINOD_> But then authentication should check only user is valid or not and give some token or something with his roles etc information. The services do validate this token and then apply RBAC rules to check the authorization and also to decide the scope
21:45:48 <gabrielhurley> vishy: is momentarily distracted in the office here
21:45:54 <schwicke> ayoung: so a new user would by default not be able to do anything until he gets a role assigned, right ?
21:45:55 <gabrielhurley> he'll be back in 60 seconds
21:45:57 <ayoung> that is one advantage of cross domain assignments.
21:46:25 <VINOD_> schwicke....yes..
21:46:29 <ayoung> schwicke, yes, although you can actually pre-assign the role before the user is created.  In the federation case, that will be the norm
21:46:41 <schwicke> makes sense
21:46:44 <schwicke> +1
21:46:45 <gabrielhurley> in a self-service world a user should have a default "just them" project and role... in a more controlled world they'd have nothing. depends on the deployment
21:46:46 <VINOD_> but ideally speaking he has atleast role of a member and we should atleast allow to query his own things
21:46:57 <vishy> sorry boss walked by :)
21:47:21 <ayoung> I'm working on a proposal to allow the domain backends to control one portion of the userid and the other portion will be the domain id.  That way, two IdPs can both assign a userid without them potentially conflicting
21:47:41 <vishy> ayoung: if domains are a per authn thing that is fine
21:48:03 <ayoung> so  if you know your domain ID,  and you know the ayoung user is coming, you could create a role assign for ayoung**<domid>  for your project
21:48:34 <ayoung> vishy, they can also be the top level container for projects without breaking anything, so long as we have the delegation you are recommending.  I like this approach
21:49:04 <vishy> ayoung: yes that is true but it sounds like it might be better to just keep them as a grouping for users and leave projects out of it
21:49:04 <ayoung> If you have role r on project p you also have role x on all sub projects of p
21:49:16 <ayoung> vishy, only if we hate out users
21:49:21 <ayoung> lets no make them relearn
21:49:37 <vishy> the only exception is a domain might have a maximum scope in the hierarchy
21:49:50 <vishy> i don't like them at the top and here is why
21:49:53 <ayoung> domain is a project with no parent.  Its ok to give it a different name
21:49:58 <vishy> say i'm a service provider
21:50:03 <ayoung> its really no different than the difference between hostname and URL
21:50:11 <vishy> i provide services to two companies each with their own idm
21:50:27 <vishy> as the service provider i need to be able list/delete in both companies
21:50:32 <vishy> so i need a root above the domain
21:50:43 <vishy> but they should be limited to their side of the tree
21:51:06 <schwicke> I agree with vishy
21:51:10 <vishy> ayoung I think there should be a root to the tree
21:51:21 <gabrielhurley> vishy: ++
21:51:22 <dolphm> works for me
21:51:24 <gabrielhurley> I've been saying that for ages
21:51:28 <vishy> domains at the top means you have more than one root
21:51:29 <VINOD_> No you can either be a super user/admin or have a role as Domain Admin in both companies
21:51:44 <vishy> VINOD_: you could do it that way but why
21:51:51 <vishy> when you can stick it all under one tree
21:51:59 <gabrielhurley> VINOD_: where does the super-admin role get assigned? currently roles are tied to projects/domains
21:52:03 <vishy> and then it functions the same way at all levels
21:52:13 <vishy> gabrielhurley: makes a good point there ^^
21:52:15 <gabrielhurley> no role shoud grant you premissions above/outside the thing it is granted on
21:52:22 <dolphm> gabrielhurley: +++++++++++++++++++++++++
21:52:44 <ayoung> you could do that with a single domain
21:52:48 <VINOD_> currently the user with role "admin" is super user
21:52:56 <ayoung> one domain, and sub project for each customer
21:53:09 <ayoung> VINOD_, we are fixing that
21:53:13 <VINOD_> currently even if a user has been assigned a role of "admin" in a tenant, he actually becomes the super admin
21:53:16 <dolphm> ayoung: then each customer is limited to a single project
21:53:18 <gabrielhurley> ayoung: but that kills all the reasons you'd want to ahve multiple domains
21:53:19 <vishy> VINOD_: currently the role admin exists on a project which means we have this annoying habit of creating a special admin project
21:53:20 <ayoung> VINOD_, lets leave that out, that is a policy thing
21:53:22 <VINOD_> ayoung ok
21:53:23 <dolphm> ayoung: they can't have their own multitenancy isolation
21:53:24 <vishy> which is so gross
21:53:30 <ayoung> dolphm, not with hierarchical projects
21:53:43 <dolphm> the "admin domain" and "admin tenant" are terrible hacks that need to die a brutal death
21:53:53 <morganfainberg> dolphm, with hierarchical projects... ayoung said it
21:54:11 <vishy> ok good so my intention here isn't to get keystone to start working on hierarchical projects right away, but its nice to know you guys aren't opposed to the idea.
21:54:12 <morganfainberg> dolphm, agreed. if we have a single root-domain though we've just implmented the same thing
21:54:14 <ayoung> dolphm, if the service provider is going to manage the scope for the customer, whether we call it a domain or a project is irrelevant
21:54:20 <gabrielhurley> dolphm: ++
21:54:23 <ayoung> root is the domain.
21:54:38 <bknudson> would it be easier to implement hierarchical projects in keystone?
21:54:45 <ayoung> if you want a single root, have a single domain.  The hierarchy stuff works fine
21:54:47 <bknudson> than to fake up something else?
21:54:55 <ayoung> bknudson, they need to be in Keystone
21:54:58 <vishy> ayoung: sure but i thought you wanted separate idms
21:55:02 <vishy> for each customer
21:55:05 <dolphm> bknudson: the distributed authorization enforcement is the harder problem that needs to be tackled first
21:55:05 <vishy> with namespaced users
21:55:09 <ayoung> vishy, assignment backend is split from Identity
21:55:25 <vishy> ayoung: ok were fine then
21:55:41 <ayoung> yes we are...thanks for driving this forward
21:55:46 <vishy> cool
21:55:54 <vishy> will email everyone when i have a basic prototype
21:56:02 <vishy> it will likely only support one or two calls
21:56:03 <morganfainberg> vishy, cool.
21:56:06 <vishy> and will do ugly db hacks
21:56:09 <schwicke> great!
21:56:14 <ayoung> vishy, lets talk
21:56:15 <vishy> and modify openstack.common in place
21:56:19 <gabrielhurley> yay db hacks!
21:56:23 <ayoung> we can, I think, do better than that
21:56:29 <vishy> you have been warned!
21:56:41 <vishy> ayoung: you mean on the db hacks?
21:56:46 <ayoung> Both LDAP and SQL have different ways of supporting hierarchy, but both drivers can be made to work
21:56:48 <ayoung> yeah
21:57:00 <ayoung> as could KVS...
21:57:08 <vishy> ayoung: Ok, this will be 10 minutes of the prototype work so no need to do that now
21:57:11 <ayoung> all these changes should be restricted to the assignments backend
21:57:16 <dolphm> ayoung: this doesn't impact ldap
21:57:19 <ayoung> vishy, that is what scares me
21:57:23 <ayoung> dolphm, tell that to CERN
21:57:30 <dolphm> ayoung: CERN agrees
21:57:33 <ayoung> LDAP does this bettr than SQL
21:57:34 <dolphm> ayoung: rememember?
21:57:37 <schwicke> ayoung: we are here :)
21:57:40 <vishy> but if you have a good keystone modification to actually do it that is awesome
21:57:50 <dolphm> schwicke: =D
21:58:04 <vishy> anyway I must jump into another meeting
21:58:06 <morganfainberg> ayoung, if the prototype shows this doesn't work for nova at all, i think the point is not to devote keystone resources
21:58:10 <vishy> thanks everyone!
21:58:11 <ayoung> vishy, let me look.  It comes down to changing the create project API and the create role for user.
21:58:11 <dolphm> vishy: /salute - thanks!
21:58:18 <morganfainberg> ayoung, hence 10 minutes of the initial prototype
21:58:19 <ayoung> actually, not create role,
21:58:24 <morganfainberg> vishy, cheers!
21:58:28 <vishy> #endmeeting