18:00:02 <lbragstad> #startmeeting keystone
18:00:03 <openstack> Meeting started Tue Mar 28 18:00:02 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:06 <openstack> The meeting name has been set to 'keystone'
18:00:10 <lbragstad> ping agrebennikov, amakarov, annakoppad, antwash, ayoung, bknudson, breton, browne, chrisplo, cmurphy, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lamt, lbragstad, kbaikov, ktychkova, morgan, nishaYadav, nkinder, notmorgan, portdirect, raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, SamYaple, shaleh, spilla, srwilkers,
18:00:11 <lbragstad> StefanPaetowJisc, stevemar, topol, shardy, ricolin
18:00:20 <samueldmq> hi all
18:00:27 <hrybacki> o/
18:00:27 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:32 <lbragstad> o/
18:00:34 <notmorgan> o/
18:00:37 <gagehugo> o/
18:00:43 <cmurphy> o/
18:00:46 <notmorgan> lbragstad: turns out my schedule conflict is starting at 11:30 not 11
18:00:54 <ravelar> o/
18:01:02 <knikolla> o/
18:01:07 <dstanek> ehlo
18:01:20 <spilla> o/
18:01:49 <rodrigods> o/
18:01:52 <lbragstad> notmorgan sweet - so we get you for a half an hour!
18:02:59 <lbragstad> our attendee list is getting a little large, and my client is showing me most of the folks aren't in the room
18:03:09 <lbragstad> figured its time for a roll call
18:03:18 <lbragstad> #topic roll call
18:03:37 <lbragstad> I've already recorded those who've already raised their hands
18:03:57 <antwash> o/
18:04:06 <lbragstad> is anyone else here that wants a pre-meeting ping who hasn't raised their hand yet?
18:04:26 <lbragstad> we'll be doing this next week, too
18:04:41 <lbragstad> i'll aggregate the list together in a couple weeks
18:05:42 <lbragstad> alright - moving on
18:05:50 <lbragstad> #topic Boston Forum Brainstorming
18:05:58 <lbragstad> #link https://etherpad.openstack.org/p/BOS-Keystone-brainstorming
18:06:13 <lbragstad> I've started a list to see who is going to be at the forum for sure
18:06:19 <lbragstad> and who is still tentative
18:06:23 <knikolla> that's a sad attendance list
18:06:32 <rderose> o/
18:06:52 <dstanek> knikolla: ++
18:07:03 <lbragstad> is anyone else planning on being in Boston at this point?
18:07:15 <gagehugo> I will most likely be there*
18:07:15 <rodrigods> i am
18:07:28 <lbragstad> i understand a lot of this is based on corporate approval, i'm trying to get an early feel of who is going to be there
18:07:30 <spilla> also most likely there
18:07:40 <samueldmq> lbragstad: I'll be there
18:08:39 <lbragstad> is there anything we specifically want to request sessions for?
18:09:12 <lbragstad> (the whole concept of the proposal for projects bits is confusing to me, so i'm just kinda going with the flow based on what other projects are doing)
18:10:18 <lbragstad> it sounds like nova is only proposing 3 sessions that are pretty cross-project oriented, which makes me think we should do the same if there is anything cross project wise we need from other folks
18:10:40 <samueldmq> lbragstad: are those sessions like in the PTG ?
18:10:49 <samueldmq> lbragstad: or user/deployer focused ?
18:10:56 <lbragstad> samueldmq i have no idea
18:11:09 <lbragstad> this is the information i have
18:11:10 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114456.html
18:11:56 <rodrigods> we will always have something to discuss
18:12:01 <rodrigods> :)
18:12:05 <samueldmq> lbragstad: looks like more general
18:12:14 <samueldmq> topics to discuss with ops, with users, with the community-at-large
18:12:25 <lbragstad> true - i'm more wondering what we need to know now so that we can propose sessions by April 1st
18:12:55 <samueldmq> lbragstad: cool, so we need to brainstorm there, right ?
18:12:57 <lbragstad> one of the big ones that keeps popping up for me is the policy work
18:13:01 <lbragstad> samueldmq yeah
18:13:14 <dstanek> lbragstad: can we just get a room for some amount of time and decide how to use it later?
18:13:15 <lbragstad> i can follow up with the nova folks to see if they'd be interested in a policy session?
18:13:28 <samueldmq> lbragstad: sounds good to me
18:13:30 <lbragstad> dstanek it doesn't sound like that's is the flow, we have to use proposals
18:14:02 <dstanek> topic1 - 1 hour, topic2 - 1 hour, etc.
18:14:29 <lbragstad> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114399.html
18:14:44 <notmorgan> i will definitely not be at the forum
18:14:48 <lbragstad> #link http://lists.openstack.org/pipermail/user-committee/2017-March/001856.html
18:15:03 <lbragstad> that ^ note specifically requires abstracts
18:15:58 <lbragstad> "We are looking for a good mix of project-specific, cross-project or
18:15:58 <lbragstad> strategic/whole-of-community discussions, and *sessions that emphasize
18:15:59 <lbragstad> collaboration between users and developers are most welcome!*"
18:17:51 <lbragstad> is there anything other than policy that folks think we need a specific session for?
18:18:29 <henrynash> anything keystone-horizon-ish?
18:19:05 <lbragstad> like domain-admin configuration?
18:19:16 <lbragstad> and the support in horizon for it?
18:19:51 <henrynash> yeah, as well as adminness in general (e.g. recognizing is_admin_project)
18:20:24 <lbragstad> henrynash would the intended direction be that developers from horizon and keystone are there describing it to operators?
18:20:41 <lbragstad> henrynash which sounds more informative, or do we want feedback?
18:20:50 <henrynash> horizon as the classic example of how to interprest these things
18:21:00 <henrynash> yes, that’s probably true, howver
18:21:45 <lbragstad> i can follow up with robcresswell to see what his thoughts are on a cross-project proposal
18:22:01 <lbragstad> #action lbragstad to follow up with nova on a cross-project proposal for RBAC/policy
18:22:29 <lbragstad> #action lbragstad to follow up with horizon on a cross-project proposal for Boston
18:22:38 <dstanek> lbragstad: limits maybe?
18:22:44 <lbragstad> dstanek oo
18:23:03 <lbragstad> yeah - that'd be another good cross-project one
18:23:56 <lbragstad> #action lbragstad to follow up on limits session
18:24:11 <samueldmq> nice
18:24:11 <lbragstad> i assume we'll need nova, cinder, neutron, etc... in there too
18:24:26 <dstanek> yeah
18:24:39 <lbragstad> dstanek good suggestion,
18:24:46 <lbragstad> can anything think of anything else?
18:25:02 <lbragstad> rderose and samueldmq are doing talks on PCI, so i feel like that will be pretty well covered
18:25:31 <rderose> just samueldmq as I didn't get approval to go :(
18:25:32 <samueldmq> lbragstad: ++ rderose won't be able to make it though
18:25:38 <samueldmq> ^  :(
18:25:47 <lbragstad> rderose ah! :(
18:25:52 <lbragstad> samueldmq rderose thanks for the update
18:26:04 <dstanek> what about a "beat up keystone" session? or some sort of feedback thing
18:26:25 <lbragstad> dstanek yeah - have that documented in the etherpad, but I don't know if that is something that we need a proposal for?
18:26:34 <lbragstad> i can check with mrhillsman though
18:26:46 <lbragstad> something tells me he'd be the guy to ask
18:27:34 <lbragstad> #action lbragstad to check and see if operator feedback sessions need proposals
18:27:44 <lbragstad> ok - sounds like i have some work to do
18:28:09 <lbragstad> if anyone has additional ideas that fit the criteria, please ping me in -keystone
18:28:12 <dstanek> a PTLs job is never done
18:28:24 <lbragstad> since we'll have to get things proposed this week
18:28:30 <lbragstad> dstanek you're telling me
18:28:34 <samueldmq> dstanek: ++
18:28:45 <lbragstad> alrighty - i think we're good to move on
18:28:51 <lbragstad> #topic pike specs
18:29:08 <lbragstad> #info 2.5 weeks until Spec Proposal Freeze
18:29:17 <lbragstad> #info 10 weeks until Spec Freeze
18:29:31 <lbragstad> we have several specs up for review and several of them are pretty indepth
18:29:58 <lbragstad> #topic pike specs: persistent group membership in federation
18:30:02 <lbragstad> breton o/
18:30:14 <lbragstad> breton you've been wanting to talk about this for a long time
18:30:26 <breton> yep
18:30:34 <lbragstad> #link https://review.openstack.org/#/c/437533/
18:30:44 <breton> so at the PTG we talked about federation
18:30:51 <breton> and that group membership was not persistent
18:31:06 <breton> we decided that we are just going to document it
18:31:11 <lbragstad> yup - iirc the idea was to provide better documentation for operators to handle that case
18:31:27 <breton> but then at the next session i suggested to add an ability to make group membership persistent
18:31:38 <breton> by adding an option to a mapping
18:31:43 <breton> and we didn't really discuss it
18:31:48 <breton> so i wanted to get some feedback on the spec
18:32:09 <lbragstad> breton does the latest version of the spec include the details about using mapping?
18:32:17 <lbragstad> about using the mapping?*
18:32:38 <lbragstad> looks like the last upload was Feb 23
18:32:42 <breton> lbragstad: not sure what you mean
18:32:47 <breton> persistent_membership is what i suggest there
18:33:20 <dstanek> breton: was there already a patch submitted for the doc update?
18:33:37 <breton> dstanek: no
18:33:51 <dstanek> although i thought i was relatively clear on the nature of groups when i overhauled that doc
18:34:16 <lbragstad> this is the relevant bug report
18:34:18 * lbragstad #link https://bugs.launchpad.net/keystone/+bug/1589993
18:34:18 <openstack> Launchpad bug 1589993 in OpenStack Identity (keystone) "cannot use trusts with federated users" [High,In progress] - Assigned to Boris Bobrov (bbobrov)
18:34:22 <breton> i really want to have persistent membership because role assignments from https://docs.openstack.org/developer/keystone/federation/mapping_combinations.html#auto-provisioning _are persistent_
18:35:36 <knikolla> i thought they were not persistent, just the project was created. :/
18:35:54 <lbragstad> knikolla it depends on the mapping
18:36:11 <lbragstad> if the mapping specifies a project *in* the mapping, the project reference must contain a role
18:36:29 <lbragstad> which is then assigned directly from the shadow user to the project
18:38:00 <lbragstad> breton in your approach - would the mapping change in order for keystone to make memberships persistent?
18:38:18 <breton> lbragstad: yes
18:39:08 <lbragstad> it wouldn't be the default behavior?
18:39:14 <dstanek> ++ it has too for backward compatibility
18:39:34 <breton> it wouldn't be the default behavior
18:39:41 <dstanek> i'm 'o' happy, it seems
18:40:05 <knikolla> lbragstad: did a quick check in the code. you are right about the role assignment.
18:40:33 <dstanek> lbragstad: if you changed the default behavior then you break the expectations of existing mappings
18:40:39 <lbragstad> knikolla if i wasn't right about it i would be worried since i wrote it ;)
18:40:54 <lbragstad> dstanek right - that's one of my main concerns
18:40:59 <dstanek> #action dstanek to check the mapping documentation to make sure the ephemeral nature of the groups is clear
18:41:26 <knikolla> lbragstad: i forgot that :p
18:41:29 <lbragstad> i can also see how operators would have a *ton* of stuff to clean up if they started using this feature
18:42:20 <lbragstad> since groups is batch processing for users
18:42:30 <dstanek> lbragstad: it would be nice to know if people would use it rather than the default behavior
18:43:05 <lbragstad> true
18:43:26 <lbragstad> projects like heat would probably like it because it would require less things in order for them to consume federation
18:43:52 <dstanek> lbragstad: how so?
18:44:12 <lbragstad> right now we are suggesting the operators place federated users in groups manually
18:44:20 <knikolla> also trusts
18:44:32 <lbragstad> before they can use heat which uses trusts
18:44:46 <lbragstad> which don't work with ephemeral group memberships
18:45:57 <dstanek> lbragstad: ah i see. it also adds effort to their user provising systems that they have to consider
18:46:06 <lbragstad> right
18:46:18 <lbragstad> they also have to clean things up manually
18:46:39 <lbragstad> regardless, of if the mapping engine makes the group membership persistent or if they do
18:46:48 <dstanek> yeah, anytime a group change in AD (or whatever) they need to "manually" make that change
18:47:04 <lbragstad> (which is totally another thing we need to document if we haven't already)
18:47:21 <dstanek> lbragstad: that's why it would be nice to just fix trusts so they don't have to do it at all
18:47:24 <lbragstad> ok - so random tangent question, would this be a problem if heat used something like oauth?
18:47:35 <lbragstad> instead of trusts
18:47:43 <dstanek> i suggested in the case of a federated trust that we don't do a group lookup, but i'm not sure it that feasible
18:48:17 <dstanek> lbragstad: i think with a little work on our side that would be entirely possible
18:48:35 <lbragstad> is it a more appropriate solution?
18:48:37 <dstanek> ...or api keys?
18:48:54 <lbragstad> i can ask the same question about api keys, too :)
18:49:03 <knikolla> i thought the underlying issue is that we can't know if the user still has that kind of group permissions. so everything persistent is sketchy
18:49:40 <dstanek> we'd still need to understand the tolerance for the risk of a user no longer being in a group
18:49:54 <lbragstad> ok - so oauth might not help us here?
18:50:02 * lbragstad totally thought it might for some reason
18:50:20 <dstanek> knikolla: that's exactly the problem. until they auth again we won't know
18:50:46 <dstanek> lbragstad: it totally could. we just have to understand the tolerance for group membership changes
18:50:48 <lbragstad> otherwise its a bunch of duplicated state across identity systems
18:51:23 <lbragstad> so if heat wanted to use oauth for federated users, what would that look like?
18:52:17 <dstanek> lbragstad:  i assume the user would auth and give heat a token. that token would then have roles back on groups that we can no longer verify
18:54:02 <lbragstad> hmm
18:54:05 <lbragstad> breton thoughts?
18:55:10 <knikolla> does an oauth idp have an api to check group mempership?
18:55:19 <dstanek> no matter what we run into the same problem. the question is what side is best for the solution or can we just assme the change-group risk for some period of time
18:55:48 <lbragstad> dstanek i feel like that has to be a question answered by the deployer
18:56:00 <lbragstad> if we provide both in keystone
18:56:16 <rderose> I thought we talked about making concrete role assignments to solve this
18:56:42 <dstanek> rderose: that doesn't solve group membership changes
18:56:45 <lbragstad> rderose i think this is more related to concrete role assignments
18:57:08 <lbragstad> s/role assignment/group membership/
18:57:32 <rderose> dstanek: right, but it's about the roles
18:57:49 <knikolla> until create user with federated attributes is merged, users have to auth once before they can be assigned concrete roles. with the mapping that is automatic.
18:57:59 <knikolla> but not concrete
18:58:13 <knikolla> if i understand correctly, breton wants an option in the mapping to make it concrete
18:58:16 <rderose> knikolla: right
18:58:22 <dstanek> rderose: right, that causes the issue of the operator needing to cleanup
18:58:41 <lbragstad> information sprawl across identity systems
18:58:53 <lbragstad> i think we need more input from operators on this
18:59:33 <dstanek> i'd really just like trusts to 'trust' the group membership (epheral groups) and make the operator responsible for kicking keystone when that changes
18:59:35 <dstanek> lbragstad: ++
18:59:57 <knikolla> we probably can have it as an option and let ops decide. it's their tradeoff to decide.
19:00:14 <lbragstad> alright - we can take this to -keystone
19:00:25 <lbragstad> #endmeeting