18:02:07 <morganfainberg> #startmeeting Keystone
18:02:07 <openstack> Meeting started Tue Nov 18 18:02:07 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:10 <openstack> The meeting name has been set to 'keystone'
18:02:12 <bknudson> hi
18:02:17 <lbragstad> I was guilty of that last year...
18:02:26 <ayoung> poor jamielennox probably will get an alarm clock wake up in 1 hour
18:02:27 <morganfainberg> Welcome back! Hope people had a good summit and a nice week since the summit
18:02:28 <lbragstad> I feel accomplished that I remember
18:02:49 <marekd> dolphm reminded of that yesterday
18:03:01 <morganfainberg> #topic Stable Maintenance Liaison
18:03:07 <morganfainberg> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch
18:03:23 <bknudson> I'd be willing to sign up for this since we kind of need it
18:03:27 <morganfainberg> While I can do this, I would prefer to have someone else to also rely on.
18:03:58 <ayoung> #startvote Nominate bknudson
18:03:58 <openstack> Only the meeting chair may start a vote.
18:03:59 <dolphm> i'm on board as well
18:04:05 <lbragstad> bknudson: is the liaison of liaisons
18:04:13 <bknudson> dolphm's got 2 already
18:04:20 <morganfainberg> haha
18:04:23 <dolphm> #winning
18:04:32 <morganfainberg> i'll let you guys figure out which one will do it.
18:04:38 * ayoung winning by not having to be stable liason
18:04:58 <morganfainberg> #action dolphm or bknudson as stable liason. They'll battle it out - mad max style to see who gets it.
18:05:35 <dolphm> bknudson: fisticuffs in #openstack-keystone later?
18:05:51 <ayoung> "Two man enter, one man get  extra work!"
18:05:53 <morganfainberg> just update the wiki and let me know who it ends up being.
18:06:02 <dolphm> morganfainberg: ++
18:06:07 <bknudson> dolphm: you can take it. I'm busy enough.
18:06:18 <dolphm> bknudson: lol alrighty
18:06:18 <bknudson> I'll try to do more reviews in stable
18:06:21 <morganfainberg> #topic Mapping engine - do we need some enhancements?
18:06:26 <morganfainberg> marekd o/
18:06:32 <marekd> hello
18:06:42 <bknudson> plus I can never figure out the test failures.
18:06:49 <ayoung> morganfainberg, I think we need, at least the ability to split the REMOTE_USER value into userid and domain
18:06:53 <dolphm> bknudson: that's the hard part
18:06:58 * morganfainberg needs to also do more stable reviews.
18:07:04 <ayoung> jamielennox, good morning!
18:07:06 <marekd> sorry
18:07:12 <marekd> emergency
18:07:15 <morganfainberg> no worries
18:07:19 <jamielennox> ayoung: mmm
18:07:27 <stevemar> i think marekd is running away?
18:07:31 <morganfainberg> i can answer the question - we do need enhancements.
18:07:32 <marekd> so, during the summit i heard some plans and opinions about
18:07:34 <marekd> mapping engine
18:07:47 <marekd> stevemar: i am not running away
18:07:53 <bknudson> here comes that singularity
18:08:01 <marekd> e.g. https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting there was a thread here
18:08:18 <marekd> i remember nkinder was mentioning something about dynamic group creation
18:08:35 <rodrigods> marekd, ++
18:08:40 <marekd> i see everybody have some plans and opinions and i'd like to gather them and try to work something out.
18:08:48 <morganfainberg> marekd, more specifically group-passthrough, so it was possible to just pass group info across not need a keystone group every time
18:08:53 <bknudson> etherpad?
18:08:55 <ayoung> ++
18:08:57 <ayoung> that too
18:09:01 <morganfainberg> etherpad would be good.
18:09:32 <marekd> <wip>
18:09:40 <marekd> https://etherpad.openstack.org/p/mapping-engine-enhancements
18:09:53 <morganfainberg> #link https://etherpad.openstack.org/p/mapping-engine-enhancements
18:10:00 <marekd> morganfainberg: thanks.
18:10:27 <rodrigods> we want to help with that as well
18:10:32 <dstanek> I just worry about going too far here. like the dev thread suggested
18:10:33 <rodrigods> cc vsilva_
18:10:44 <marekd> rodrigods: fine, thanks, but we still don't have a clear roadmap :-)
18:11:01 <rodrigods> marekd, we can also help with the roadmap =p
18:11:02 <morganfainberg> #action please contribute information to the etherpad, we can distill out the requirements and what is really needed and what would be too much.
18:11:08 <ayoung> #link https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Keystone
18:11:19 <topol> concrete use cases would be nice
18:11:39 <marekd> topol: ++
18:11:43 <morganfainberg> marekd, i have some use-cases for enhancements that "make sense" afaict, but they should be easy sells compared to some of the other things.
18:11:51 <ayoung> topol, See the complexit y from gyee's X509 spec he pulled:  bascially, the subject of a cert
18:11:54 <morganfainberg> but yes, include the use-case in the etherpad
18:12:01 <marekd> morganfainberg: ok, thanks.
18:12:11 <ayoung> topol, also, REMOTE_USER as set by mod_auth_kerb
18:12:16 <ayoung> and the REMOTE_UISER value from SAML
18:12:32 <morganfainberg> ayoung, I vote we make the variable REMOTE_UISER in all cases now
18:12:32 <stevemar> ayoung that should work now.. with https://review.openstack.org/#/c/133037/ merged
18:12:44 <ayoung> morganfainberg, can't
18:12:51 <morganfainberg> ayoung, darn
18:12:52 <morganfainberg> anyway
18:12:54 <marekd> morganfainberg: and to be honest i don't know much about nkinder's proposition
18:12:57 <ayoung> for example, REMOTE_USER might not be the right value from mod_ssl
18:12:57 <marekd> regarding groups
18:13:08 <morganfainberg> marekd, we'll get details outlined in the etherpad
18:13:11 <marekd> i was hoping he would explain it here pro publico bono :-)
18:13:16 <ayoung> #link http://www.freeipa.org/page/Environment_Variables
18:13:21 <marekd> morganfainberg: allrighty.
18:13:27 <ayoung> And SAML is pretty much An LDAP query
18:13:34 <marekd> does it all deserve a spec for the kilo release?
18:13:35 <morganfainberg> marekd, it should be straight forward once it's laid out like that.
18:13:50 <morganfainberg> marekd, likely we will want a spec to encompass the changes.
18:14:02 <morganfainberg> but lets see what comes from the ehterpad first
18:14:08 <stevemar> yeah, especially if it's new functionality/feature
18:14:09 <morganfainberg> might be that we say "nope not going to happen"
18:14:12 <stevemar> and not just a bug fix
18:14:20 <morganfainberg> for $REASONS$
18:14:22 <ayoung> probably the most common case is split an env var into two pieces, one is username or userid, the other is domain info
18:14:26 <marekd> engine is not broken as is...
18:14:32 <marekd> it simply may lack some features
18:14:53 <marekd> ayoung: i'd still concatenate it
18:14:55 <morganfainberg> marekd, correct. thats why i think we need to see the details and then write a spec to encompass the enhancements - clearly detailing the SoW/scope
18:15:05 <marekd> morganfainberg: great
18:15:15 <marekd> i can take care of the specs if we need it.
18:15:19 <ayoung> #link https://jdennis.fedorapeople.org/doc/mapping.pdf  John Dennis' proposal
18:15:22 <morganfainberg> it will help us prevent things sneaking in that are "bad ideas"™
18:15:48 <marekd> ayoung: they made more powerful engine
18:16:07 <marekd> ok, if anybody else has some usecases please add it to the etherpad
18:16:19 <ayoung> marekd, "They?"  he's on my team.  He did this all by himself.  jdennis kindof been through this once or twice before
18:16:29 <morganfainberg> I am going to say right now we will for this cycle at least *not* be making the mapping engine configurable - we will maintain 1 mapping engine, even if it means swapping out what we have whole-sale. I don't want to fight with pluggable mapping engines at this point. too many ways for things to be exposed in bad ways
18:16:53 <topol> morganfainberg +++
18:16:59 <marekd> ayoung: ok, great, jdennis, *himself*, from ayoung's team has made a much powerful engine.
18:17:02 <ayoung> I think that is fine
18:17:09 <dstanek> morganfainberg: ++ seems dangerous if done wrong
18:17:33 <ayoung> he was doing it for opendaylight.  So one benefit to his approach is it would work with another open source project
18:17:37 <lbragstad> I'm on board with that
18:17:51 <marekd> ayoung: i know. I really appreciated his e-mails
18:18:04 <marekd> and it was *really* meritorical stuff.
18:18:15 <bknudson> seems like if there's an existing mapping tool we should use it rather than try to develop our own
18:18:19 <marekd> that's why i want to  drag your attention
18:18:22 <ayoung> I would say, though, that he lacks the APIs we need for management.  Those are really part of the Federation spec today, and assume the existing mapping language
18:18:34 <morganfainberg> ayoung, and it might make sense to be compatible - my only hard line is i don't want pluggable engines for many many reasons, mostly around security and making the features solid before we open it up to massive headaches.
18:18:40 <ayoung> bknudson, technically, ours existed first
18:18:41 <marekd> and answer the questions: do we need something new? some small fixups, or maybe we should take John's engine?
18:18:56 <morganfainberg> also, his iirc is java and would need to be ported to python if we used it.
18:19:02 <ayoung> he wrote his this year as part of his work on Open Daylight.
18:19:13 <morganfainberg> marekd, ++ those are exactly the questions we should answer.
18:19:17 <jamielennox> if nothing else that doc is awesome
18:19:18 <topol> java ugghh
18:19:28 <ayoung> git clone git://fedorapeople.org/~jdennis/federated-mapping.git
18:19:34 <morganfainberg> and would john's engine "fix" the other needs or would we need to expand it as well.
18:19:47 <morganfainberg> s/"fix"/"meet"
18:19:49 <ayoung> looking to see if he did the python yet
18:19:57 <bknudson> maybe we can make the python version an openstack project
18:20:13 <morganfainberg> bknudson, I'd support that.
18:20:15 <marekd> bknudson: really?
18:20:22 <morganfainberg> if we go down that path
18:20:22 <stevemar> we're just dealing with arrays and dicts, it shouldn't be hard to port it over
18:20:28 <marekd> bknudson: morganfainberg  like a standalone project?
18:20:32 <rodrigods> marekd, makes sense, since it's goiing to be pluggable
18:20:33 <bknudson> it's pretty common... I think this was done with some other python projs that openstack uses.
18:20:45 <morganfainberg> marekd, it would be a lib like policy
18:20:49 <bknudson> sqlalchemy-migrate for example
18:20:51 <marekd> morganfainberg: ok
18:21:00 <marekd> i could probably give a helping hand with that.
18:21:02 <morganfainberg> marekd, not a "stand alone service"
18:21:07 <dstanek> let's just start simple on the etherpad with requirements and gaps - then this discussion will be more valuable
18:21:15 <joesavak> +1 dstanek
18:21:15 <marekd> dstanek: ++
18:21:16 <morganfainberg> but yes, lets get requirements in the etherpad
18:21:18 <ayoung> there is python code there
18:21:30 <joesavak> or a spec to detail why this approach is needed and what problems it solves
18:21:55 <morganfainberg> ayoung, if you could poke john to look at the etherpad as well and comment re his mapping engine once we have the use-cases
18:22:05 <ayoung> will do
18:22:07 <morganfainberg> see where we land.
18:22:38 <morganfainberg> #action ayoung to talk to john dennis about mapping engine and use-cases from etherpad: https://etherpad.openstack.org/p/mapping-engine-enhancements once populated with requested enhancements
18:23:00 <rodrigods> morganfainberg, me and vsilva_ will be on top of that as well
18:23:03 <morganfainberg> joesavak, thats the point of the etherpad.
18:23:10 <joesavak> woot
18:23:14 <morganfainberg> joesavak, post meeting need to bug you fyi.
18:23:18 <morganfainberg> ok moving on.
18:23:23 <morganfainberg> #topic K2K federation - status
18:23:27 <morganfainberg> marekd, all you again! :)
18:23:35 <marekd> allrighty, was hoping to see gyee here
18:23:40 <gyee> here
18:23:46 <marekd> gyee: oh, sorry!
18:23:47 <gyee> sorry I got stuck in traffic
18:23:48 <joesavak> magic.
18:23:57 * morganfainberg waves hands "magic"
18:24:12 <marekd> so, K2K
18:24:25 <joesavak> hoping to see megan fox here
18:24:30 <morganfainberg> joesavak, shh
18:24:30 <marekd> here!
18:24:39 <gyee> ++ :)
18:25:19 <marekd> so, K2K I wanted to ask if any of you had some experience or tried it out. It was marked as experimental in Juno and I feel there should be some fixes.
18:25:29 <marekd> i know rodrigods make a setup without security
18:25:34 <gyee> marekd, we did and it works!
18:25:36 <morganfainberg> marekd, i am planning on setting up a multi-way federated cloud test env this week.
18:25:42 <marekd> i know gyee and Sam were playing with that
18:25:49 <marekd> gyee: did you turn off crypto?
18:25:50 <morganfainberg> so i expect i'll also have feedback on it.
18:25:55 <bknudson> Is K2K still marked as experimental?
18:25:59 <gyee> no
18:26:02 <morganfainberg> bknudson, yes.
18:26:09 <rodrigods> gyee, marekd, AFAIK, Sam disabled security as well
18:26:12 <morganfainberg> bknudson, i hope it will move to "stable" this cycle.
18:26:20 <rodrigods> at least was the last update he sent to me
18:26:23 <marekd> gyee: so it worked with a proper assertion signature validation?
18:26:23 <gyee> I do have a question on federation though, with the way it works, we have to use different URL for different providers
18:26:27 <morganfainberg> bknudson, but we're just starting to get drive-time on it now.
18:26:38 <marekd> rodrigods: that's what he told me .
18:26:39 <bknudson> we need tempest tests!
18:26:42 <gyee> yes
18:26:49 <morganfainberg> bknudson, ++ that is part of why i'm setting up the test env
18:26:49 <leonchio_> rodrigods, marekd, yes, that's right, I have the signature validation disabled
18:26:56 <marekd> leonchio_: :/
18:27:00 <rodrigods> =(
18:27:07 <gyee> because of the way redirect works
18:27:08 <lbragstad> morganfainberg: which test env specifically?
18:27:23 <rodrigods> leeantho, did you try using the same issuer for both IdP and SP?
18:27:24 <marekd> also
18:27:34 <morganfainberg> lbragstad, i'm going to be standing up a multi-node / cloud env with k2k + other federation. specifically so we can outline how we're testing it
18:27:37 <rodrigods> leonchio_, *
18:27:40 <gyee> oh, it was disabled?
18:27:44 <marekd> AFAIR there were some plans of different regions list depending on who is having a local token
18:27:47 <lbragstad> morganfainberg: ah, that's right...
18:27:49 <marekd> stevemar: recall anything like that?
18:27:54 <morganfainberg> lbragstad, infra can do multi-node environments now. (but it might be expirimental still)
18:27:58 <rodrigods> we are missing the region in the catalog as well
18:28:07 <marekd> rodrigods: hmmmmm, are we?
18:28:10 <rodrigods> yep
18:28:14 <marekd> last time i tried it I think i had it
18:28:30 <rodrigods> not for me, here
18:28:41 <marekd> joesavak: we don't want *any user* to see all the clouds that one can burst into, do we?
18:28:44 <marekd> stevemar: ^^
18:28:56 <marekd> this should also be fixed, right?
18:29:05 <morganfainberg> marekd, i think that can be fixed with the filtering?
18:29:19 <morganfainberg> leverage endpoint filtering and expand it to region filtering?
18:29:25 <joesavak> marekd - they should be able to pull a list of trusted service providers so they know which provider to reference when getting the saml assertion from the local cloud to pass to other (service provider) clouds
18:29:28 <stevemar> marekd, i don't think we put any regions in the catalog right now
18:29:45 <rodrigods> stevemar, ++
18:30:13 <marekd> joesavak: but all the SPs ?
18:30:15 <gyee> but we can group endpoints based on regions
18:30:18 <jamielennox> stevemar: i thought we do
18:30:36 <marekd> stevemar: rodrigods i will check it, maybe i messed sth up.
18:30:36 <gyee> its an attribute of endpoint isn't it?
18:30:48 <joesavak> marekd - perhaps rbac, or relating which domains can access which SPs is needed...
18:31:02 <stevemar> oh i didn't think about filtering at all
18:31:08 <joesavak> i can see that some restriction would be good - but I think it's supposed to be a list-all right now
18:31:14 <jamielennox> also regarding having SPs still feel that it's a bad idea to put anything in the catalog that can't be accessed with the current token
18:31:17 <marekd> stevemar: morganfainberg but isn't filtering a client-initiated action?
18:31:26 <morganfainberg> marekd, no endpoint filtering is server side
18:31:36 <gyee> https://github.com/openstack/keystone/blob/master/keystone/catalog/schema.py#L73
18:31:38 <marekd> morganfainberg: on what basis?
18:31:39 <morganfainberg> it doesn't prevent use of a target
18:31:49 <marekd> joesavak: aha, ok
18:31:55 <marekd> joesavak: i thought you would be concerned.
18:31:58 <morganfainberg> marekd, but it's a cloud provider can filter endpoints per project etc
18:32:08 <morganfainberg> for now i think filtering out targets is an enhancement
18:32:16 <morganfainberg> not a design of the current system
18:32:20 <morganfainberg> aha, joesavak ++
18:32:40 <marekd> one last thing.
18:32:51 <marekd> currently we add only one url to a region
18:33:05 <marekd> which is a SP URL where the assertion should be send.
18:33:07 <joesavak> a little concerned - but should be manageable - via RBAC or even endpoint assignment to identity
18:33:41 <gyee> joesavak, security is a manageable condition :D
18:33:48 <morganfainberg> gyee, hah
18:33:54 <joesavak> implementors choice. ; )
18:34:00 <marekd> but this means, a client needs to know another URL apriori, an endpoint where he should go once authenticated.
18:34:08 <rodrigods> marekd, ++
18:34:17 <marekd> and it put a lot of concern on people.
18:34:21 <rodrigods> yeah, that's a tricky point
18:34:25 <marekd> yes
18:34:40 <marekd> so I suggest we add two url to the bursting regions
18:34:40 <rodrigods> since we do not have a real relay_state =P
18:34:51 <morganfainberg> marekd, fallback url?
18:35:01 <marekd> you mean?
18:35:12 <joesavak> one being the foreign keystone URL and the other being what?
18:35:23 <rodrigods> joesavak, the auth URL
18:35:29 <marekd> joesavak: let's say the protected url is sp-keystone.com/secure
18:35:38 <morganfainberg> rodrigods, but that should be discoverable?
18:35:48 <marekd> joesavak: but the assertion is gonna be sent to sp-keystone.com/shibboleth.sso/ecp
18:36:03 <rodrigods> morganfainberg, I need to know how the SP called my IdP
18:36:13 <rodrigods> which should be a out-of-band operation
18:36:14 <marekd> and today we configure the latter only
18:36:14 <rodrigods> I think
18:36:43 <joesavak> response from assertion call is a scoped token, right? So can I get the auth URL from that scope?
18:36:56 <joesavak> GET v3/endpoints -H X-Auth-Token: $scopedToken
18:37:17 <joesavak> or unscoped even
18:37:17 <rodrigods> joesavak, that's exactly the URL we need to go to get the scoped token
18:37:34 <marekd> joesavak: is this GET to IdP or SP ?
18:37:42 <joesavak> GET to SP
18:37:48 <rodrigods> v3/identity_providers/<idp_id>/protocols/<protocol>/auth
18:37:54 <marekd> how do you know this url
18:38:12 <marekd> no, wait.
18:38:18 <morganfainberg> marekd, isn't that the URL in the region?
18:38:39 <rodrigods> morganfainberg, the one in the region is the SP url
18:38:43 <marekd> morganfainberg: no, the one in the region is for POST /Shibboleth.sso/ADFS (e.g) where you send your assertion
18:38:44 <rodrigods> like Shibboleth.sso/ECP
18:39:24 <rodrigods> so marekd wants another field to store v3/identity_providers/<idp_id>/protocols/<protocol>/auth
18:39:26 <rodrigods> right?
18:39:28 <marekd> and then, usually SP responds with HTTP 302 and location set to keystone.example.com instead of keystone.example.com/v3/OS-FEDERATION/identity_providers/<idp>protoc/.../auth
18:39:33 <marekd> rodrigods: yes
18:39:51 <marekd> it's all because the workflow is so called IdP initiated authentication
18:39:55 <joesavak> Gotcha - because we made the protocols extensible - the URL may differ outside of the known keysotne contract for assertion processing - so 2 URLs are needed
18:40:00 <morganfainberg> ah
18:40:05 <marekd> joesavak: exacly!
18:40:07 <rodrigods> joesavak, ++
18:40:09 <ayoung> 20 minutes left
18:40:10 <gyee> jamielennox, how's that going to work with keystoneclient?
18:40:12 <morganfainberg> that seems reasonable
18:40:23 <morganfainberg> but it will need client side work i think
18:40:24 <gyee> I don't think that auth url is discoverable
18:40:25 <joesavak> Ok , I'm ok with that - federationURL and keystoneURL (optional)
18:40:54 <marekd> joesavak: yeah.
18:41:01 <rodrigods> joesavak, would easy a lot to automate the clients
18:41:13 <ayoung> is this for the Horizon use case?
18:41:36 <jamielennox> gyee: i think it's specific to the federation auth plugin
18:42:05 <joesavak> rod - didn't understand your comment
18:42:06 <gyee> jamielennox, I mean it doesn't seem to follow the usual client workflow
18:42:21 <jamielennox> gyee: having all of this stuck in a region doesn't follow the regular workflow
18:42:27 <marekd> joesavak: he meant that clients would need to figure out one extra utl
18:42:28 <bknudson> we could put the auth urls in the json-home document somehow
18:42:30 <marekd> url
18:42:34 <joesavak> yup
18:42:36 <marekd> joesavak: they could work fully automated.
18:42:37 <rodrigods> marekd, joearnold exactly
18:42:44 <jamielennox> i tried to break the region == SP think prior to kilo but didn't get there in time
18:42:45 <rodrigods> joesavak, *
18:43:13 <morganfainberg> jamielennox, why is it wrong to assume a region == SP ?
18:43:21 <morganfainberg> in this case?
18:44:07 <jamielennox> 1. makes it confusing with how people currently use regions 2. breaks the concept that everything in the service catalog can be accessed with the current token
18:44:29 <jamielennox> (from memory #2 still applies - maybe changed since then)
18:44:36 <gyee> morganfainberg, the client discovery code won't work as is
18:44:38 <morganfainberg> except the region *only* has a url.
18:44:45 <morganfainberg> not endpoints in this case.
18:44:56 <marekd> morganfainberg: joesavak one thing, just remembered.
18:45:09 <marekd> shouldn't we also add some *another* parameterer to the region?
18:45:17 <marekd> like the federated protocol?
18:45:18 <morganfainberg> ok this needs more discussion - we can enhance/change this but we have other topics to get to in this meeting.
18:45:21 <jamielennox> morganfainberg: which seems like we shoehorned something into a current resource with edge cases rather than just make a new resource
18:45:42 <morganfainberg> we can make this better since k2k is expirimental if it's really warranted
18:45:43 <marekd> today we have only saml2, but tommorow regions/SP A,B,C will be saml2 only, but M,N OIDC
18:45:47 <morganfainberg> this is the point of experimental
18:45:53 <jamielennox> morganfainberg: we could have made an SP resource and put that into the catalog
18:45:53 <morganfainberg> but the case needs to be really strong.
18:45:54 <marekd> how am i going to be able to distinguish?
18:46:33 <morganfainberg> marekd, so i think we should evaluate shifting to an SP resource or similar
18:46:39 <marekd> jamielennox: that would be not a bad idea
18:46:40 <jamielennox> marekd: at this point you're taking over the region concept and i would vote to making a new SP resource in which all of this makes sense
18:46:41 <marekd> morganfainberg: ++
18:46:42 <gyee> marekd, if SP is a resource in SC, we could filter it
18:46:44 <morganfainberg> or at least a clear way to identify a "Region" is a resource
18:46:50 <joesavak> yeah - we should have the protocol the SP uses to be discoverable.
18:46:50 <morganfainberg> or whatever
18:46:54 <morganfainberg> but yes.
18:47:06 <morganfainberg> lets evaluating making that shift before we stabilize k2k
18:47:13 <marekd> morganfainberg: so, whole new api for adding service providers, just like we have IdP now?
18:47:21 <marekd> stevemar: joesavak ^^ ?
18:47:24 <morganfainberg> #action Evaluate Service Provider as part of the Catalog
18:47:27 <joesavak> +1
18:47:35 <ayoung> Heh...that was inthe origianl Kent proposal
18:47:46 <morganfainberg> ayoung, funny how things come full circle
18:47:51 <morganfainberg> ok #topic HM releases planning
18:47:53 <morganfainberg> erm
18:47:56 <morganfainberg> #topic HM releases planning
18:48:00 <raildo> \o
18:48:03 <morganfainberg> raildo, rodrigods o/
18:48:06 <rodrigods> o/
18:48:12 <raildo> So, this is our planning for HM in Kilo:
18:48:13 <ayoung> release early release often
18:48:23 <raildo> Kilo-1 the base implementation about HM merged and the new specs about HM improvements https://review.openstack.org/#/c/135309/ and the Reseller Use case (I'm writing it) merged too.
18:48:29 <gyee> ayoung ++
18:48:43 <morganfainberg> raildo, thats a good target
18:48:49 <raildo> Kilo-2 the entire code about HM and Reseller use case committed.
18:48:56 <ayoung> ++
18:48:58 <rodrigods> so, for Kilo-1
18:49:04 <rodrigods> please review https://review.openstack.org/#/c/117786/ and the following patches
18:49:05 <rodrigods> =)
18:49:12 <raildo> rodrigods, ++
18:49:13 <morganfainberg> raildo, once the base code is merged we will need to resolve the rebase against master to topic branch
18:49:22 <morganfainberg> then we do a simple topic branch -> master merge
18:49:42 <raildo> morganfainberg, yes, i believe that we can do that in kilo-1 too
18:49:44 <morganfainberg> should be straight forward.
18:49:45 <morganfainberg> yes
18:49:51 <rodrigods> really wanted it to land before henrynash refactoring
18:49:51 <rodrigods> hehe
18:49:59 <henrynash> rodigods: eek
18:50:01 <morganfainberg> rodrigods, race to rebase.
18:50:07 <raildo> hah
18:50:21 <raildo> and for  Kilo-3 just reviews and resolve some bugs related to HM (if it appears :) )
18:50:38 <morganfainberg> makes sense
18:50:43 <raildo> So, We have this Wiki about HM Meeting:
18:50:47 <henrynash> rodigods: we should just talk about which way makes the most sense
18:50:47 <raildo> #link https://wiki.openstack.org/wiki/Meetings/HierarchicalMultitenancyMeeting
18:50:56 <raildo> (just follow the Keystone pattern)
18:51:00 <rodrigods> the idea is that Kilo-2 code won't be a feature branch anymore
18:51:08 <morganfainberg> rodrigods, that is my hope
18:51:20 <raildo> the HM meetings on Friday at 16:00 UTC here in #openstack-meeting I invite everyone to participate
18:51:26 <raildo> :)
18:51:43 <ayoung> raildo, do what we do at the start of this meeting:
18:51:47 <henrynash> rodigods: my go
18:52:03 <ayoung> paste in the names of the keystone contributors that you want there
18:52:08 <morganfainberg> ok so we can quickly get to the last couple topics we have.
18:52:09 <rodrigods> ayoung, ++
18:52:11 <morganfainberg> we need to keep moving.
18:52:12 <raildo> ayoung, sure
18:52:25 <raildo> morganfainberg, ok
18:52:27 <morganfainberg> #topic Oslo-Incubator Policy Graduation to Keystone Program
18:52:36 <morganfainberg> We are adopting the policy lib
18:52:44 <gyee> w00t!
18:52:48 <ayoung> w00t
18:52:55 <morganfainberg> it'll be run like pycadf (separate core team), if you're not interested as keystoen-core you wont need to be on core
18:52:59 <ayoung> and we are waiting on fileutils to move to oslo.utils,
18:53:01 <morganfainberg> though i hope everyone will want to be core on it
18:53:07 <morganfainberg> ayoung, we decided to wait?
18:53:15 <morganfainberg> anyway rodrigods is writing the spec
18:53:15 <rodrigods> ayoung, morganfainberg not that I'm aware of
18:53:18 <rodrigods> yep
18:53:23 <morganfainberg> the proposed name is pycpre
18:53:28 <ayoung> morganfainberg, ah...we can go ahead without that?  Good!
18:53:30 <morganfainberg> since it can't be in the oslo namespace
18:53:32 <morganfainberg> ayoung, we can.
18:53:35 <rodrigods> hmm missed the name choice part
18:53:46 <ayoung> pycpre  was a joke
18:53:50 <morganfainberg> ayoung, lol ;)
18:53:52 <ayoung> but someone took it seriously
18:53:54 <morganfainberg> sorry skipped the :)
18:54:01 <ayoung> cloud policy rules engine
18:54:05 <gyee> :|
18:54:18 * topol The Keystone empire grows.....
18:54:24 <ayoung> srsly we need a name
18:54:24 <dolphm> rodrigods: is that spec already published somewhere?
18:54:26 <morganfainberg> in all seriousness i want a name that isn't "keystone" namespaced
18:54:31 <rodrigods> would be nice a name to pronounce without being an acronym
18:54:33 <dolphm> topol: AAA
18:54:35 <ayoung> python-policy might be too over-reaching
18:54:39 <rodrigods> dolphm, not yet, will publish in keystone-specs
18:54:44 <topol> dolphm, indeed
18:54:46 <morganfainberg> and it can't be oslo namespaced
18:54:57 <gyee> congress?
18:55:00 <morganfainberg> topol, i swear dolph and I didn't discuss this
18:55:00 <gyee> just kidding!
18:55:01 <ayoung> cyprus?
18:55:04 <morganfainberg> anyway
18:55:05 <morganfainberg> think of names
18:55:13 <morganfainberg> discuss w/ rodrigods  and in the spec
18:55:14 <topol> gyee..... really???
18:55:26 <gyee> hey now
18:55:32 <morganfainberg> we'll continue this convo elsewhere
18:55:38 <morganfainberg> #topic Policy Specifications
18:55:42 <morganfainberg> ayoung, o/
18:55:44 <ayoung> Yay!
18:55:44 <morganfainberg> 5 mins
18:55:44 <pballand> gyee: good one ;)
18:55:45 <topol> I for one welcome my new Keystone overlords :-)
18:55:56 <ayoung> OK...so henrynash and I have been hashin a few things out
18:56:04 <henrynash> ayoung: :-)
18:56:05 <dolphm> pypolice
18:56:12 <morganfainberg> dolphm, hehe
18:56:29 <dolphm> pylice?
18:56:33 <rodrigods> pypo
18:56:36 <ayoung> probably the most contentious thing was the distinction between hierarchical roles (not the role assignments) and role groups
18:56:38 <rodrigods> haha
18:56:39 <topol> yuck
18:56:41 <joesavak> keystone cops and the pylice
18:56:41 <dolphm> rodrigods: ++
18:56:42 <joesavak> lol
18:56:45 <dstanek> call it customs; they are strict and almost didn't let me back into the US
18:56:53 <dstanek> customs.policy
18:56:57 <henrynash> ayoung: are we on to a lost casue here?
18:57:03 <morganfainberg> hey
18:57:13 <morganfainberg> we need to cover this
18:57:15 <morganfainberg> it's important
18:57:16 <ayoung> nah, we are, aI thinkm, talking about two aspects of related but different things
18:57:19 <topol> they demanded dstanek shave his beard or stop rotting for the browns
18:57:22 <morganfainberg> jokes can go #openstack-keystone
18:57:27 <morganfainberg> post meeting.
18:57:29 <morganfainberg> ayoung, please continue
18:57:32 <dolphm> ayoung: can you reset the conversation back to the problem being solved? it's hard to follow along as the discussion seems to jump straight into the solutions and the steps required to implement those solutions
18:57:33 <ayoung> so we need a shorthand for identifying that one role (or someting)  means multiple roles
18:57:46 <ayoung> ok...problems to be solved:
18:58:26 <ayoung> well, henrynash 's solving the problem of "domain specific roles"
18:58:26 <dstanek> topol: rotting is probably correct
18:58:45 <morganfainberg> they are closely related
18:58:55 <morganfainberg> and can/should co-exist
18:58:57 <henrynash> #link https://review.openstack.org/#/c/133855/
18:59:06 <dolphm> ayoung: that's already a solution, not a use case
18:59:11 <samuelms> morganfainberg, ++
18:59:46 <ayoung> dolphm, take that up with henry, not my problem to solve.  I was starting with "how do we unify delegations into one mechanism"
18:59:51 <morganfainberg> dolphm, the #1 usecase is for a domain admin to be able to redelegate groupings of permissions to users on projects under the domain
19:00:02 <henrynash> dolphm: Problem 2: Different domains want to be able to create their own "roles" which are more meaningful to their users...but our "roles" are global and are directly linked to the rules in the policy file - something only a cloud operator is going to want to own.
19:00:13 <morganfainberg> henrynash, ++
19:00:13 <henrynash> dolphm: Solution: Have some kind of domain-scoped role-group (or meta-role) that a domain owner can define, that maps to a set of underlying roles that a policy file understands. [As has been pointed out, what we are really doing with this is finally doing real RBAC, where what we call roles today are really capabilities and role-groups are really roles]
19:00:19 <ayoung> and delegate something more fine-grained than just the role I've been assigned
19:00:31 <dolphm> perfect, thanks
19:00:33 <morganfainberg> ayoung, thats the next piece you're advocating.
19:00:50 <ayoung> morganfainberg, it grew out of the constraints discussion
19:00:54 <morganfainberg> ayoung, we decided at the summit that first pass was coarse groupings to ensure we could solve the immidiate need
19:00:57 <morganfainberg> anyway
19:00:58 <morganfainberg> that is time
19:01:05 <morganfainberg> continue the topic in #openstack-keystone
19:01:07 <ayoung> I want to be able to say "this token can only do operation O"
19:01:09 <morganfainberg> and jokes.
19:01:13 <morganfainberg> #endmeeting