18:05:10 <morganfainberg> #startmeeting keystone
18:05:11 <openstack> Meeting started Tue Nov 25 18:05:10 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:05:13 <bknudson> anything on the agenda?
18:05:15 <openstack> The meeting name has been set to 'keystone'
18:05:34 <morganfainberg> So quick house keeping
18:05:44 <morganfainberg> this is a short week for all the US folks
18:05:50 <morganfainberg> have a good thanks giving!
18:05:51 <dolphm> /turkey
18:05:59 <joesavak> /ham
18:06:16 <morganfainberg> joesavak, dolphm, (turkey, ham, stuffing)
18:06:27 <morganfainberg> #topic HM Discussion: Can we create a domain below a project? or we must keep domains on the top and projects below
18:06:28 <joesavak> pie!
18:06:33 <morganfainberg> raildo, o/
18:06:36 <raildo> \o
18:06:37 <dstanek> turkey day!
18:06:56 <raildo> So... During the Summit we discuss a lot of things about HM, but some discussions remained open, of these questions is:Can we create a domain below a project (just a project, not a project that change to be a domain)? or we must keep domains on the top and projects below?
18:07:21 <raildo> I'm remember that morganfainberg like the first option and ayoung the second...
18:07:22 <joesavak> we are still maintaining a domain is an administrative boundary containing projects & users; and a project is a collection of resources right?
18:07:32 <raildo> joesavak, yes
18:07:35 <ayoung> raildo, sortof
18:07:37 <ayoung> I would say this
18:07:42 <morganfainberg> joesavak, the idea is domains will become projects with special properties
18:07:45 <ayoung> domains should only be able to nest under domains
18:07:56 <morganfainberg> joesavak, but without those special flags, they can't be the administrative
18:08:01 <morganfainberg> boundry
18:08:06 <joesavak> that's cool - then no "domains" under "projects"
18:08:12 <ayoung> having domain->project->project->domain
18:08:14 <ayoung> not good
18:08:18 <samuelms> ayoung, ++
18:08:18 <joesavak> +1 ayoung
18:08:30 <morganfainberg> ayoung, why?
18:08:45 <morganfainberg> how is it "not good"
18:08:49 <morganfainberg> it may be sub-optimal.
18:08:53 <ayoung> we can allow it later if we find there is compelling reason, but I don't see that it is a good fit
18:09:12 <joesavak> confuses authorization at the higher levels, and creates administration headaches for assignments
18:09:15 <samuelms> and then if someone tells me that he wants only to create instances (I sell him a project ) .. otherwise .. if he wants to resell , then I sell him a domain : different contracts
18:09:19 <dolphm> how is that sub optimal? it's almost a simplification
18:09:37 <morganfainberg> dolphm, sub-optimal to have domain -> project -> project -> domain
18:09:41 <morganfainberg> dolphm, was my question
18:09:59 <morganfainberg> not domain -> domain -> domain -> not domains after here cause this is a project
18:10:01 <ayoung> ok...so domains are organizational boundaries.  So If I resell to you, and you resell to her, and she resells to you, there is a clear chain
18:10:12 <ayoung> putting projects in between, though, muddies that
18:10:34 <ayoung> morganfainberg, I'm ok with  domain -> domain -> domain
18:10:41 <henrynash> (sorry for being late)
18:10:50 <ayoung> IN fact, I think we need it explicitly for the reseller case
18:10:56 <raildo> ayoung, in our implementation is not allowed cycle
18:10:59 <samuelms> ayoung, yes .. and buying for resell or buying to create instances are kept with different contract (and prices)
18:11:01 <morganfainberg> i'm inclined to say domains can be anywhere.
18:11:15 <morganfainberg> it's an attribute on a project
18:11:17 <bknudson> I thought a domain was a special type of project?
18:11:20 <henrynash> morganfainberg: I tend to agree
18:11:20 <samuelms> ayoung, you can't say that you want to create instances (less expensive) and then resell
18:11:21 <ayoung> its more than that
18:11:30 <morganfainberg> a deployer (e.g. joesavak) can choose that domains can only be at the top
18:11:33 <ayoung> it is going to be an entry that pulls in an identity source
18:11:40 <dolphm> morganfainberg: we had reasoning to make that property immutable once set though
18:11:50 <morganfainberg> dolphm, did we?
18:11:58 * dolphm is looking through notes
18:12:07 <henrynash> ayoung: is there something other than complexity that you are concerned about (apologies if you already stated this and I missed it)
18:12:08 <morganfainberg> i figured a deployer could tear down the domain attribute at somepoint.
18:12:19 <morganfainberg> henrynash, we just started, you didn't miss much/anything
18:12:23 <raildo> dolphm, you're saying that, if a change a project to be a domain, i can't remove this "flag"?
18:12:34 <dolphm> morganfainberg: i think that's exactly what we wanted to disallow
18:12:41 <joesavak> morganfainberg - that's fine - and flexible - "deployer choice"
18:12:47 <morganfainberg> dolphm, i honestly don't remember that.
18:12:58 <morganfainberg> but if thats the case, then yes, domains can't go under projects.
18:13:07 <ayoung> henrynash, I have to admit, I am having trouble voicing it.  It was one of those things that we discussed at the summit and it became clear that keeping the org tree clear made sense
18:13:10 <morganfainberg> it makes life really unfriendly
18:13:19 <dolphm> morganfainberg: if the deployer can do anything to manipulate a customer's customer's domain, privacy & security are violated
18:13:47 <morganfainberg> dolphm, ah, right the administrative block thing
18:14:05 <bknudson> we need OpenStack as a Service
18:14:16 <bknudson> Cloud as a Service
18:14:25 <morganfainberg> dolphm, ok - that is the addon built on top of it
18:14:32 <samuelms> joesavak, if we go for 'just domains under domains', we can establish different contracts (and then pricing) to people that want to 1) create instances 2) resell
18:14:39 <gabriel-bezerra> what's the major difference between projects and domains? just that domains hold users?
18:14:49 <raildo> great, So I'll put this discussion in the Reseller spec :)
18:14:53 <joesavak> there's a basic level of trust between a deployer and a reseller customer - that the deployer wouldn't touch the reseller customer's customer unless asked to - so authorization may have to allow that in some cases
18:14:53 <morganfainberg> gabriel-bezerra, and (future looking) roles
18:15:06 <ayoung> morganfainberg, I think that the issues is:  what does it mean if the parent of a domain is project that is not a domain.  There was some wierdness there
18:15:14 <henrynash> dolphm: surely that’s a contractual thing in reality…the domain attributes on teh project that is the root of the reseller encapsulates the contractual agreement….teh deployer can’t change it without breaking the contract
18:15:18 <htruta> ayoung: ++
18:15:18 <dolphm> gabriel-bezerra: domains (or private projects) also provide an authorization boundary
18:15:31 <joesavak> domains under domains for resellers make sense
18:15:34 <gabriel-bezerra> can't we have just a project tree and keep domain something that points to a project?
18:15:46 <samuelms> henrynash, ++
18:15:48 <gabriel-bezerra> then domains will keep the roles and users
18:15:50 <henrynash> ayoung: can you articulate said weirdness
18:16:12 <morganfainberg> ayoung, i think the wierdness is the part that isn't clear
18:16:14 <jamielennox> the point was to make domains essentially a project with a flag to indicate some idp stuff, why does it matter if that comes below a project?
18:16:28 <gabriel-bezerra> jamielennox: ++
18:16:32 <henrynash> ayoung: in terms of inheritance from parent domains…the projects are essentially invisible up the tree
18:16:37 <morganfainberg> jamielennox, that was my view.
18:16:39 <dolphm> the domain -> domain -> domain restriction provides a simplification that i'm a fan of - lower risk of security bugs :)
18:16:54 <raildo> dolphm, i agree
18:16:59 <morganfainberg> dolphm, i think the best approach since we decided that domain is not toggle-off-able
18:16:59 <dolphm> it's also a constraint we can relax later
18:17:08 <ayoung> dolphm, that is my feeling, too
18:17:09 <morganfainberg> dolphm, is we make the constraint a check in 1 place
18:17:19 <morganfainberg> so it's super easy to relax if we need to.
18:17:36 <samuelms> dolphm, ++
18:17:43 <joesavak> what's the constraint/restriction - a list of projects?
18:18:04 <morganfainberg> joesavak, that the parent of a domain can only be another domain
18:18:06 <morganfainberg> for now.
18:18:15 <jamielennox> ok, i'd be happy with domain to domain as a starting point and let us figure out issues, then remove the check later
18:18:19 <joesavak> ok
18:18:22 <ayoung> henrynash, I think it comes down to being able to track who delegated to whom at the organizational level.  Having a project between delegations doesn't really make sense to me.  It also limites who can make a new domain
18:18:25 <morganfainberg> so you can't set the "domain flag" if the parent is a project
18:18:31 <samuelms> joesavak, we implement like we allowed domains under projects .. but we block it with a constraint that could be easily removed later
18:18:46 <joesavak> gotcha - thanks
18:18:47 <morganfainberg> but i say this only from the standpoint that "turning off" the domain flag is unlikely to be something we *really* want people to do
18:19:11 <rodrigods> morganfainberg, you mean project becoming a domain and than back to project?
18:19:17 <morganfainberg> rodrigods, correct
18:19:43 <rodrigods> morganfainberg, yeah, wouldn't allow it
18:19:44 <samuelms> morganfainberg, and then we delete that domain's users?
18:19:57 <morganfainberg> rodrigods, so then domains can't be under projects ;)
18:20:04 <morganfainberg> rodrigods to save headaches to start
18:20:10 <morganfainberg> we can loosen the restriction later
18:20:11 <rodrigods> morganfainberg, ++
18:20:13 <samuelms> morganfainberg, ++
18:20:31 <henrynash> fine with that as a starting point
18:20:32 <raildo> great :)
18:20:32 <morganfainberg> rodrigods, but i'd like to keep that limitation very isolated, so we can easily relax it if we want
18:20:47 <rodrigods> morganfainberg, makes sense, we'll keep it in mind
18:21:29 <morganfainberg> dolphm, and my view is very much changed by the "immutable" domain flag.
18:21:35 <morganfainberg> dolphm, thanks ;)
18:22:00 <morganfainberg> ok so... more HM!
18:22:01 <dolphm> morganfainberg: that was probably your idea 6 months ago anyway
18:22:03 <htruta> just a point I was in doubt... will there be any difference from the top level domain (which we have today) and the others?
18:22:11 <bknudson> any action from the discussion?
18:22:18 <morganfainberg> bknudson, not really?
18:22:20 <dolphm> #agreed domains become projects in the backend
18:22:24 <htruta> I mean.. the top domain will also be a "domained" project?
18:22:24 <morganfainberg> dolphm, ++
18:22:27 <dolphm> #agreed but the parent of a domain must be another domain
18:22:29 <raildo> bknudson, I'll put this in the Reseller Spec
18:22:39 <morganfainberg> htruta, the top level domains just have no parent
18:22:47 <morganfainberg> they are the same as any other domain in the system
18:22:48 <dolphm> #agreed once a project is marked as a "domain", that attribute is immutable
18:23:08 <samuelms> morganfainberg, htruta and we return them when querying for v3 domains
18:23:19 <morganfainberg> samuelms: ++
18:23:24 <morganfainberg> ok so.
18:23:27 <morganfainberg> #topic Hierarchical Multitenancy Improvements Spec
18:23:34 <htruta> samuelms, morganfainberg: that's what i Thought. tks
18:23:36 <morganfainberg> #link https://review.openstack.org/#/c/135309/
18:23:41 <morganfainberg> rodrigods, raildo, o/
18:23:45 <samuelms> htruta, np
18:23:52 <raildo> We need do start to review the HM spec for Kilo :)
18:23:56 <raildo> kilo-1*
18:24:08 <morganfainberg> raildo, FYI, the spec deadline is Kilo-2.
18:24:08 <rodrigods> yeah, there are some proposals that might need your input
18:24:18 <morganfainberg> but yes, we should review the specs sooner vs later
18:24:18 <raildo> morganfainberg, ok
18:24:33 <morganfainberg> the earlier the spec lands, the earlier you can work on the code :)
18:24:40 <morganfainberg> and know it's accepted.
18:24:40 <raildo> morganfainberg, ++
18:24:41 <morganfainberg> that is.
18:24:51 <raildo> And will be great if we have the other patches related to the basic implementation about HM merged to kilo-1:
18:24:56 <samuelms> morganfainberg, and have a complete set of reseller features still in kilo
18:24:58 <rodrigods> raildo, ++
18:25:06 <raildo> #link https://review.openstack.org/#/c/117786/
18:25:07 <morganfainberg> samuelms, i would like to see that if possible.
18:25:07 <rodrigods> samuelms, ++
18:25:12 <raildo> #link https://review.openstack.org/#/c/130277/
18:25:18 <raildo> #link https://review.openstack.org/#/c/117787/
18:25:20 <raildo> :d
18:25:22 <raildo> :D
18:25:31 <bknudson> can we get rid of the topic branch?
18:25:44 <morganfainberg> bknudson, as soon as those merge and we resolve master merge
18:25:52 <morganfainberg> bknudson, but yes we will get rid of the topic branch soon
18:25:52 <rodrigods> morganfainberg, ++
18:26:11 <rodrigods> morganfainberg, btw, htruta is working in the LDAP tests
18:26:21 <rodrigods> will commit today/tomorrow
18:26:31 * morganfainberg is going to wedge a quick topic in the middle of the agenda here.
18:26:54 <htruta> morganfainberg, rodrigods: yes... those awkward tests  hehe
18:26:57 <henrynash> samulems, rodigods: did we resolve how we will check permission for resturns a hierarchy of projects?
18:26:58 <henrynash> ?
18:27:08 <bknudson> it seems like more work to keep the branch around
18:27:13 <bknudson> and diverging
18:27:18 <rodrigods> henrynash, using list_projects_for_user
18:27:26 <bknudson> when we could just merge the branch back now as it is and move the reviews over to master.
18:27:27 <rodrigods> when returning the refs
18:27:43 <morganfainberg> bknudson, we're already diverged the current CRUD patch should merge shortly
18:27:44 <raildo> bknudson, ++
18:27:46 <rodrigods> and returning a full hierarchy, when asking only for the ids
18:27:57 <morganfainberg> bknudson, figure at this point we should just merge the 2 open on the topic and resovle the master merge
18:28:05 <morganfainberg> bknudson, then all other work goes onto master
18:28:36 <morganfainberg> bknudson, or at least the most recent one on the topic branch that has a reasonable history.
18:28:50 <samuelms> rodrigods, ++
18:28:55 <rodrigods> henrynash, subtree_as_list returns the full project ref, but we omit the projects the user hasn't access to
18:28:56 <morganfainberg> bknudson, this one: https://review.openstack.org/#/c/117786/
18:29:15 <rodrigods> henrynash, subtree_ids (new spec) will return a dict with the hierarchy and only the ids
18:30:06 <henrynash> morganfainberg: we also need to resolve with the merge against the assognment split…ideally I’d have like the hieracical projects to land post-split - and am happy to help with the merge
18:30:26 <rodrigods> we lost the rebase race :(
18:30:30 <samuelms> henrynash, ++
18:30:33 <morganfainberg> ok so lets do next topic
18:30:39 <morganfainberg> so we can get to assignment split
18:30:42 <morganfainberg> :)
18:30:55 <morganfainberg> #Topic Replace Extensions
18:31:06 <morganfainberg> since we are talking about new functionality (HM+Reseller)
18:31:23 <morganfainberg> #link https://review.openstack.org/#/c/133809/
18:31:37 <morganfainberg> please review the spec to reclassify experimental vs extensions
18:32:01 <morganfainberg> i'd like to see us move away from the extention terminology for new code / features / APIs
18:32:08 <morganfainberg> ok
18:32:19 <morganfainberg> #topic Functional Testing for Federation
18:32:22 <morganfainberg> vsilva, ol
18:32:22 <samuelms> morganfainberg, ++
18:32:23 <henrynash> so apologies I haven’t produced a new version of the spec that takes into account all the new comments - I will do soon
18:32:36 <henrynash> (that was to replace extensions topic)
18:32:39 <morganfainberg> henrynash, no worries.
18:32:50 <vsilva> So, I remember a lot of people talking about improving testing for keystone, and that would be discussed on the summit.
18:33:06 <samuelms> vsilva, o/
18:33:32 <vsilva> I asked around and you don't seem to have decided anything. Shouldn't we start to move in that direction? I know for a fact that one important part of keystone doesn't have real testing (federation)
18:33:33 <dstanek> vsilva: i've started understanding all of the infra pieces for this
18:33:49 <vsilva> marekd, ^
18:34:09 <dstanek> there is a general community direction that i've been following - it's not Keystone specific
18:34:28 <morganfainberg> vsilva, i am working on some local env so i can help with the federation testing
18:34:29 <vsilva> cool, dstanek. I'd love to help
18:34:33 <morganfainberg> dstanek, ++
18:34:35 <dstanek> my goal is to get the right infra things rigged up before turkey day
18:34:35 <samuelms> dstanek, to put functional tests on tempest?
18:34:37 <bknudson> we're supposed to get all of the functional keystone tests out of tempest
18:34:42 <vsilva> morganfainberg, great
18:34:57 <dstanek> vsilva: i'm not actually writing the tests though - at least not yet - just making the place for them to go
18:35:00 <vsilva> yeah samuelms the idea is that QA shouldn't be responsible for all of that
18:35:11 <dstanek> samuelms: out of tempest and into keystone
18:35:11 <dolphm> tempest folks realized that tempest doesn't scale if it houses all the tests for everything ever
18:35:25 <morganfainberg> i talked to mtreinish about this at the summit and since
18:35:44 <morganfainberg> we can move things out of tempest, but there is going to be a delay on getting those tests dropped from tempest
18:35:45 <mtreinish> morganfainberg: what did I do?
18:35:55 <mtreinish> oh functional testing stuff
18:35:59 <morganfainberg> they don't have the metrics yet to apply the policy of "tests haven't failed"
18:36:01 <morganfainberg> mtreinish, yep
18:36:02 <samuelms> mtreinish, yes
18:36:03 <dstanek> vsilva: marekd: missing_stevemar: it would be up to you guys to write the tests :-)
18:36:32 <morganfainberg> so we *should* move the tests, but we will be waiting for them to actually drop from tempest - for $reasons$
18:36:34 <vsilva> dstanek, great. I'm sure marekd will also be happy to help.
18:36:38 <bknudson> dstanek: so do you think there'd be a special config that sets up keystone in federated config?
18:36:50 <bknudson> I assume devstack doesn't support setting up federation
18:36:53 <dstanek> bknudson: yes
18:36:53 <morganfainberg> bknudson, i *hear* we have multi-node gate on the horizon
18:37:14 <lbragstad> dstanek: we have to do it with devstack hooks right?
18:37:15 <morganfainberg> so.. i would assume a special environment that does federation and k2k.
18:37:23 <bknudson> it's going to require a saml provider... what's going to do that?
18:37:31 <dstanek> lbragstad: that's the way i'm doing it now
18:37:57 <morganfainberg> bknudson, either something contrived *or* see if we can coerce IPA [soon to work on ubuntu**] to issue SAML
18:38:10 <dstanek> ideally we'll be able to support an infinite amount of federation setups to test against...maybe not infinite
18:38:17 <morganfainberg> bknudson, i am also looking for someone to help us gate ADFS Saml -> keystone
18:38:21 <morganfainberg> but it's a challenge
18:39:18 <bknudson> this is going to be great
18:39:35 <bknudson> we seem to have dropped the testing section from the spec template
18:39:44 <dolphm> bknudson: you can still add one
18:40:39 <samuelms> morganfainberg, cool .. Where do the roles go?
18:40:42 <samuelms> p
18:40:44 <samuelms> :p
18:40:46 <ayoung> morganfainberg, IPA is not going to issues SAML
18:40:49 <ayoung> Ipisilon is
18:41:01 <rodrigods> ayoung, ++
18:41:03 <ayoung> https://git.fedorahosted.org/git/ipsilon.git
18:41:10 <morganfainberg> ayoung, that-project-you-guys-have-that-i-cant-keep-track-of-yet
18:41:15 <ayoung> https://git.fedorahosted.org/cgit/ipsilon.git/tree/README
18:41:18 <morganfainberg> ;)
18:41:42 <ayoung> morganfainberg, it is baiscally our teams effort to provide a SAML provider on top of exising LDAP services
18:41:49 <morganfainberg> ayoung, sounds good.
18:42:00 <morganfainberg> either case, we will find a way to issue assertions
18:42:30 <morganfainberg> henrynash, you here?
18:42:31 <ayoung> #link https://git.fedorahosted.org/cgit/ipsilon.git/tree/README
18:42:34 <henrynash> yrs
18:42:39 <morganfainberg> henrynash, ready for the fun topic?
18:42:39 <henrynash> yes, even
18:42:45 <morganfainberg> ayoung, thanks!
18:42:50 <henrynash> hit it
18:42:58 <morganfainberg> #topic Splitting the assignment component: Where do the roles go?
18:43:02 <samuelms> o/
18:43:04 <morganfainberg> #link https://review.openstack.org/#/c/130954/
18:43:10 <ayoung> roles go with domains
18:43:16 <henrynash> (sung to the tune of “who let the dogs out)
18:43:48 <rodrigods> ayoung, roles and domains are close friends now :)
18:43:56 <henrynash> so I posted the details of the questions that is up in the air to the dev mailing listr
18:44:07 <henrynash> http://lists.openstack.org/pipermail/openstack-dev/2014-November/051481.html)
18:44:10 <morganfainberg> henrynash, i want to start with saying we should really *not* do per-domain-assignment-mapping-enginers
18:44:32 <morganfainberg> henrynash, that is setting off every single one of the *this is an awful idea* bells when i read it
18:44:32 <henrynash> …and if I’m honest, I don’t really know if anyone would want to :-)
18:44:37 <samuelms> morganfainberg, ++ for this
18:44:38 <morganfainberg> henrynash, so lets leave that off the table.
18:44:49 <morganfainberg> henrynash, we can circle back later if there is a case for it
18:45:01 <ayoung> henrynash, what was the name of the email
18:45:08 <ayoung> disregard
18:45:16 <henrynash> so to catch everyone up, the issue is do role definitions fo in the “resource” or “assignment” piece of the split
18:45:19 <samuelms> henrynash, morganfainberg if we'd go for putting roles out of resource ... that could be a fourth backend called 'conectors' .. where we should put attributes for rbac (for eg)
18:45:27 <raildo> ayoung, [openstack-dev] [Keystone] Splitting up the assignment component
18:45:33 <bknudson> how about have a backend for roles?
18:45:39 <samuelms> bknudson, ^++
18:45:44 <ayoung> henrynash, I think that there are two types
18:45:57 <ayoung> henrynash, one is capabilites, and reusable groups of capabilities
18:46:02 <henrynash> one bit of info that is not in my mail is that today assignment manager does NOT map the role IDs into Names/Refs for token generation
18:46:05 <ayoung> that exists outside the domain abstraction
18:46:14 <ayoung> second is the private roles...those go with domains
18:46:18 <samuelms> bknudson, what I just said .. 'conectors' backend .. things we use to link actors to targets through the engine 'assignment'
18:46:25 <morganfainberg> ayoung, lets leave the "private" role bit to the side here.
18:46:44 <ayoung> morganfainberg, no...lets keep it in the discussion, but deprioritize it for implementation
18:46:45 <henrynash> morganfainberg: so teh assignment manager returns role_ids to the token provdiers and they map this into roel names
18:46:46 <morganfainberg> ayoung, i think that is largely orthogonal in this case.
18:47:08 <ayoung> morganfainberg, I wish that were the case.  I don't really think they are the same thing
18:47:29 <morganfainberg> ayoung, for the sake of this conversation, they are. because they muddy things up a lot to start
18:47:32 <ayoung> so...lets at least ack that they exist, and need to be treated differently than the current set of roles
18:47:34 <morganfainberg> ayoung, lets come back to them
18:48:14 <ayoung> morganfainberg, so, the other side is capabilities
18:48:29 <ayoung> we start at the bottom with the unified policy discussion
18:48:35 <samuelms> what about having a fourth backend to put roles/addition attributes (in the case of abac) ..
18:48:36 <morganfainberg> henrynash, you're still tightly coupled across thes systems.
18:48:38 <ayoung> samuelms, you have a link for your work on that?
18:48:50 <morganfainberg> samuelms, i don't think another backend will actually help here.
18:48:55 <henrynash> morganfainberg: how so?
18:49:07 <morganfainberg> henrynash, the assignment backend still needs to know the role ids.
18:49:07 <ayoung> I think that it might make sense to put them with policy
18:49:21 <rodrigods> ayoung,  really?
18:49:24 <ayoung> yes
18:49:35 <samuelms> ayoung, about the fourth backend ? just thought about this ..
18:49:35 <ayoung> rodrigods, it follows from this:
18:49:52 <ayoung> policy is built up from capabilites.  Roles are the intermediate state
18:50:00 <morganfainberg> ayoung, can we back up
18:50:04 <henrynash> morgainfainberg: as it does project_ids and user_ids
18:50:05 <ayoung> now, our current policy backend treats  policy as a blob
18:50:25 <morganfainberg> ayoung, waaay backup
18:50:36 <ayoung> morganfainberg, if people here have not yet read http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ they should
18:50:46 <morganfainberg> ayoung, and we aren't takling policy here
18:50:54 <morganfainberg> ayoung, so, lets stay a bit more focused
18:50:54 <ayoung> morganfainberg, roles are policy
18:50:57 <morganfainberg> ayoung, no they are not.
18:51:11 <morganfainberg> ayoung, we are talking about what is occuring *before* policy
18:51:30 <henrynash> morgainfainberg: i guess that’s teh crux of my argument….assignments is a mapping between entities that are defined elsewere….and is there a real argument that role is any different than user, group, project or domain?
18:51:53 <morganfainberg> the changes henrynash is advocating should work in both cases current and/or new policy stuff
18:52:04 <henrynash> morganfainberg: agreed
18:52:05 <morganfainberg> ayoung, this is where does that info go.
18:52:14 <rodrigods> morganfainberg, ++
18:52:16 <samuelms> henrynash, roles are the connectors between identity and resources .. I still think we should put that in a fourth backend
18:52:21 <ayoung> without understanding where we are heading it is just busy work
18:52:22 <morganfainberg> ayoung, so lets focus there and we can expand to policy which is next logical step
18:52:58 <stevemar> o/ (sorry, for being crazy late)
18:53:00 <morganfainberg> henrynash, i think roles are a construct of your assignment backend.
18:53:17 <henrynash> samuelms: so let’s concentarting on deciding IF they should be with assignments…if not, then that’s a separate discussion of where they do go
18:53:24 <morganfainberg> henrynash, my concern here is the deisgn is falling into the SQL trap - we use SQL so we design for SQL.
18:53:31 <ayoung> OK,  so let me agree with Henry.  The assignments backend should be pulling in roles from somewhere else.  And that somewhere else should be the policy backend.
18:53:32 <samuelms> henrynash, ++
18:53:43 <gabriel-bezerra> I like ayoung's idea of policy and roles being tightly coupled.
18:53:46 <morganfainberg> if we're ok with that, and we realize we're locking things in
18:53:50 <bknudson> I thought the point was to make it so you don't need SQL for role assignments?
18:54:18 <morganfainberg> i'm trying to see what i'm missing from the where roles go
18:54:31 <morganfainberg> so we're adding another layer of rule XXX maps to role Y
18:54:39 <stevemar> if the role assignments are pluggable, the roles should be too
18:54:46 <morganfainberg> when then gets transformed into role-named-y?
18:54:46 <bknudson> if your role assignment backend doesn't need defined roles then you don't have to create any
18:54:53 <morganfainberg> why should we need the extra step?
18:54:59 <morganfainberg> henrynash, ^ i think that's my question
18:55:02 <ayoung> morganfainberg, we kindof have that layer already, though
18:55:15 <ayoung> is_admin and _admin_or_owner are poorly named versions of that
18:55:17 <morganfainberg> how do you know what the answer from assignment is to the role
18:55:32 <ayoung> morganfainberg, please reask
18:55:35 <morganfainberg> henrynash, are we really creating 2 extra systems here?
18:55:53 <morganfainberg> assigment gives an answer of attributes turn into X
18:56:13 <morganfainberg> then we need to now know that X is really resource / role / actor combo
18:56:19 <samuelms> morganfainberg, henrynash if we have abac ... where should we put attributes?
18:56:29 <morganfainberg> so, all we're doing ehre is making an extra abstraction to process something?
18:57:09 <morganfainberg> i'm not seeing how the role-assignment backend works / adds value if all it's doing is adding an extra layer that we largely do all the same work we're doing now
18:57:09 <ayoung> samuelms, attributes come from multiple sources.   They all end up in the auth ref and get processed by the policy engine
18:57:11 <henrynash> morganfainberg: but are we? teh support for roleID<->RoleRef is just encoding the particualr policy language taht teh otehr servcies expect…..I’m not sure that’s realated to the realtionships between the entities
18:57:21 <ayoung> what Keystone does is RBAC on top of ABAC
18:57:38 <ayoung> ABAC is the mechanism. RBAC is the organizational scheme
18:57:46 <morganfainberg> ayoung, ++
18:57:58 <morganfainberg> henrynash, so how does this work?
18:58:01 <ayoung> morganfainberg, Ok...so let me give you a concrete example
18:58:13 <ayoung> lets say we have a single sign on system that allows us to manage hosts
18:58:22 <ayoung> think something like an IDP, but for machines
18:58:29 <samuelms> ayoung, not sure .. if we think in sets .. abac contains rbac, right?
18:58:32 <ayoung> maybe something that does secure DNS, etc
18:58:43 <ayoung> now,  Keystone is going to map users from an idp to host access
18:58:45 <morganfainberg> (2minutes)
18:58:53 <ayoung> the hosts are inside of groups that we could use as proejcts
18:58:57 <henrynash> morgainfainberg: role-assignment backend IS the relationship bit, the resource bit is the translation into what the other parts of opemstac understand
18:59:20 <ayoung> so we pull in the projects from this system as a domain, but here it is providing the projects, not the users
18:59:26 <samuelms> henrynash, ++
18:59:42 <ayoung> keystone then provides a management layer to map users to those projects...users from multiple IdPs
19:00:02 <ayoung> So keystone needs to keep the definition of Roles separate from the projects themselves
19:00:16 <morganfainberg> ayoung, we're going to need to continue in -keystone
19:00:21 <gabriel-bezerra> 7pm UTC
19:00:22 <ayoung> cus, in this case, the projects might be every bit as immutable as users out of LDAP
19:00:40 <morganfainberg> please continue in #openstack-keystone
19:00:43 <ayoung> I'll take it up there
19:00:49 <morganfainberg> #endmeeting