16:00:39 <lbragstad> #startmeeting keystone
16:00:40 <openstack> Meeting started Tue Dec  4 16:00:39 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:43 <openstack> The meeting name has been set to 'keystone'
16:00:46 <cmurphy> o/
16:00:46 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:49 <lbragstad> agenda ^
16:00:50 <lbragstad> o/
16:01:42 <knikolla> o/
16:01:52 <kmalloc> o/
16:01:52 <lbragstad> we'll give folks a minute or two
16:01:59 * kmalloc drinks coffee
16:02:11 <gagehugo> o/
16:03:56 <lbragstad> alright
16:04:13 <lbragstad> #topic Welcome Outreachy Interns
16:04:16 <lbragstad> cmurphy o/
16:04:16 <wxy|> o/
16:04:18 <cmurphy> hello
16:04:33 <cmurphy> So for this outreachy round we have two interns, erus and imus
16:04:38 <cmurphy> please give them a warm welcome
16:04:42 <lbragstad> awesome!
16:04:47 <lbragstad> hi erus and imus
16:04:59 <imus> hi
16:05:00 <cmurphy> erus will be working on some federation improvements and imus will be working on the api unit test refactor
16:05:03 <wxy|> welcome~
16:05:08 <gagehugo> hey!
16:05:09 <kmalloc> woohoo! great to have you all
16:05:14 <erus> Hi everyone thanks o/
16:05:14 <imus> Thanks
16:05:16 <knikolla> welcome :)
16:05:19 * kmalloc cheers for imus and erus
16:05:38 <imus> :)
16:05:48 <cmurphy> that's about all I had for that, glad to have erus and imus on board :)
16:06:13 <erus> Glad to have the opportunity :)
16:06:19 <lbragstad> imus erus i'm located in utc-6, don't hesitate to reach out if you have questions
16:06:22 <erus> Thanks cmurphy
16:06:45 <kmalloc> we have pretty good coverage
16:06:47 <cmurphy> erus: imus: by the way lbragstad is the Project Technical Lead so he knows everything
16:06:52 <lbragstad> false
16:06:56 <cmurphy> ;)
16:07:02 <lbragstad> i "pretend" to know everything
16:07:03 <erus> Haha
16:07:21 <lbragstad> but i end up leaning on everyone else when i'm wrong ;)
16:07:22 <erus> I'm in utc-3
16:07:33 <erus> XD
16:07:44 <lbragstad> erus cool - that sounds good
16:07:48 <kmalloc> i'll probably be awake later than most folks, hm.. Pacific is UTC-8 now?
16:07:56 <kmalloc> so i'll be around probably later than most folks.
16:08:02 <erus> Cool
16:08:12 <kmalloc> also lbragstad does know everything
16:08:14 <kmalloc> :P
16:08:24 <erus> I'm always awake too xd
16:08:50 <erus> So good to have a mixed utc team :)
16:09:00 * kmalloc is just trying to make everyone to not look at git blame and see "Morgan" name on everything
16:09:32 <lbragstad> alright - few more things on the agenda
16:09:40 <lbragstad> #topic Summit recap
16:09:57 <kmalloc> yeah. it's a great team. i'm super happy we got to add both of you to it (at least for now! hopefully longer after outreachy finishes this cycle)
16:10:17 <lbragstad> in case you haven't noticed, the foundation has updated all the recorded content from the summit
16:10:20 <erus> Yeah it would be great!
16:10:38 <imus> happy to be here and yes hopefully for longer
16:10:54 <lbragstad> i've put together a short summary of keystone and TC related content https://www.lbragstad.com/blog/openstack-summit-berlin-recap
16:11:00 <kmalloc> the thumbnail for the talk ayoung, knikolla, and I did is perfect :P
16:11:20 <lbragstad> does anyone else know of recaps floating around?
16:11:25 <knikolla> can't imagine it happening accidentally
16:11:29 <cmurphy> I didn't do one this time
16:11:42 <lbragstad> ack - just double checking
16:12:28 <lbragstad> #topic Outstanding Reviews
16:12:31 * kmalloc didn't do a keystone IDP recap... but next summit/ptg expects to.
16:12:38 <kmalloc> since we'll be further along
16:12:43 <lbragstad> kmalloc good idea
16:12:58 <lbragstad> alright - does anyone have patches up for review that they need eyes on?
16:13:33 <lbragstad> specification reviews included
16:14:02 <cmurphy> https://review.openstack.org/615190
16:14:05 <kmalloc> https://review.openstack.org/#/c/605043/
16:14:21 <cmurphy> https://review.openstack.org/615847
16:14:36 <cmurphy> poor ldappool gets no love
16:14:38 <kmalloc> cmurphy: +2/A on ldappool
16:14:48 <kmalloc> done
16:14:58 <kmalloc> the keystoneauth rate-limit patch needs eyes
16:15:14 <kmalloc> it has a functional cross-over test with SDK, we should eventually have a first-party in-tree test too
16:15:23 <kmalloc> but i'm ok with it as long as we have eyes on the code
16:15:26 <cmurphy> also it's not ready yet but i wouldn't mind feedback on https://review.openstack.org/615384
16:15:48 <lbragstad> cmurphy ah - i was going to start looking at that earlier today, but saw it was still WIP
16:15:58 <lbragstad> kmalloc ack - i can take a look today
16:16:37 <wxy|> cmurphy: the guide is awesome, I'm waiting for the TODO part. :)
16:16:55 <cmurphy> :)
16:17:03 <cmurphy> need to find some extra time to get back to it
16:17:15 <kmalloc> it's amazing how there always seems to be no time
16:17:23 <lbragstad> fact
16:17:39 <lbragstad> any other reviews people want to draw attention to?
16:18:36 <lbragstad> #link https://review.openstack.org/#/c/614195/ will unblock some patches for us in keystone
16:18:52 <lbragstad> same iwth
16:18:54 <lbragstad> #link https://review.openstack.org/#/c/611443/
16:19:46 <lbragstad> i also re-spun all the patches for implementing default roles late last week
16:19:54 <lbragstad> those should be passing and ready for some eyes
16:19:57 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles
16:20:16 <lbragstad> and some patches to cleanup the policy.v3cloudsample.json
16:20:21 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:clean-up-v3-cloud-sample
16:21:34 <lbragstad> alright - moving on
16:21:48 <lbragstad> #topic Renewable Application Credentials
16:21:50 <lbragstad> knikolla o/
16:21:54 <knikolla> o/
16:21:59 <knikolla> spec is up
16:22:01 <knikolla> #link https://review.openstack.org/#/c/604201/
16:22:06 <kmalloc> hooray!
16:22:12 <knikolla> i have reworked it a bit from the discussion we had last week
16:22:16 * kmalloc quickly +2/+As it before anyone can -1 it :P
16:22:25 <knikolla> mainly i kept one list of roles instead of two
16:22:25 * kmalloc adds this to a list to review today
16:22:42 <kmalloc> knikolla: ok, i'm interested in how that ends up working.
16:22:52 <knikolla> and added `last_renewed` and `identity_provider`
16:22:56 <knikolla> to the app cred model
16:22:58 <kmalloc> hm.
16:23:20 <kmalloc> but how does it work with knowing if a role is conferred via the IDP vs concretely on creation?
16:23:24 <lbragstad> i missed that discussion last week, but i'll take a pass at the spec before i start firing off questions
16:23:25 <knikolla> the entire app cred deactivates when it's not renewed.
16:23:26 <kmalloc> so we know what roles might change.
16:23:50 <knikolla> to prevent users from indefinitely logging in even though their account in the idp has been disabled
16:24:00 <knikolla> (this one was influenced by our cloud admin)
16:24:01 <kmalloc> or do we not care and just look when the IDP conferred roles change to see if the app cred's roles are valid?
16:24:14 <kmalloc> so if a role changes and no longer available just invalidate?
16:24:18 <knikolla> on renew we expand the group membership and see if it has all the roles
16:24:23 <knikolla> if it doesn't. fail renew
16:24:28 <knikolla> yup
16:24:30 <kmalloc> ok.
16:24:51 <knikolla> on concrete roles, the current logic disables the app cred already if i'm not mistaked.
16:24:53 <kmalloc> and it is still possible to create an unexpired/non-renewable app cred based upon concrete roles?
16:24:56 <knikolla> when a concrete role is removed
16:25:07 <knikolla> yes, if not using a federated token
16:25:12 <lbragstad> iirc - that's handled with a callback
16:25:17 <knikolla> if federated token, enforce renewal
16:25:23 <kmalloc> and it looks like you are limiting an app cred to roles from a single IDP
16:25:27 <kmalloc> just from your description
16:25:36 <knikolla> because roles are in the token
16:25:40 <kmalloc> since the app-cred (not the roles) are linked to the IDP
16:25:40 <knikolla> through groups
16:25:51 * kmalloc is ok with this.
16:25:54 <knikolla> and user will present the token to get an app cred
16:26:02 <knikolla> can't really have a token with roles from multiple idps
16:26:12 <kmalloc> and the IDP still configures the refresh window/period then
16:26:22 <kmalloc> knikolla: true.
16:26:34 <kmalloc> we might need to revisit that with full IDP/autoprovision
16:26:40 <knikolla> yes, there is a default ttl for backwards compat with existing idps in the db, configurable
16:26:41 <kmalloc> but for now, this is a good starting place
16:26:51 <kmalloc> knikolla: perfect.
16:27:34 <knikolla> also the idp of the app cred changes if the user comes in through a different idp to renew but has same roles
16:27:39 <knikolla> and the ttl changes based on the last idp to renew
16:27:50 <kmalloc> hm.
16:28:21 <kmalloc> so, a new app cred is implicitly created if a renew is done via a different idp?
16:28:51 <kmalloc> or just idp updatE?
16:28:54 <knikolla> kmalloc: no, just the idp associated with it changes for calculating the expiration.
16:28:55 <kmalloc> because that sounds... broken
16:29:14 <kmalloc> i'll review the spec
16:29:16 <kmalloc> i want to think on that
16:29:35 <kmalloc> i am not sure i want to see app-creds change owning idp. $securityconcerns$
16:29:50 <knikolla> ++, i don't feel strongly about it.
16:29:56 <knikolla> this was mostly for UX.
16:30:07 <knikolla> the roles are immutable either way.
16:30:13 <kmalloc> i might ask a lot more ux related questions on that front
16:30:18 <knikolla> can't add or remove after expiration.
16:30:24 <knikolla> creation*
16:30:28 <kmalloc> but i have security concerns, i'll comment on the spec
16:30:33 <knikolla> ok, cool.
16:30:35 <kmalloc> can be not-in-meeting :)
16:30:43 <knikolla> i'll be around office hours for all questions
16:30:48 * kmalloc nods.
16:30:59 <lbragstad> thanks knikolla
16:31:04 <lbragstad> anything else on this?
16:32:13 <knikolla> i think that's all i had, i'll be around in the office hours to discuss in more detail.
16:32:18 <knikolla> please review the spec
16:32:36 <lbragstad> sounds good
16:32:40 <lbragstad> #topic admin role deletion
16:32:42 <lbragstad> cmurphy again
16:32:45 <cmurphy> hi
16:33:08 <cmurphy> so a customer of ours had an outage where an inexperienced administrator accidentally deleted the admin role via horizon
16:33:22 <kmalloc> eek
16:33:29 <kmalloc> like... EEEEEK
16:33:29 <cmurphy> it's pretty destructive since usually service users use the admin role too
16:33:54 <knikolla> hmmm... do we want to take the next steps and make default roles immutable?
16:33:58 <kmalloc> knikolla: no.
16:34:05 <cmurphy> so my team mate was inquiring if this is something we can deal with upstream somehow
16:34:19 <knikolla> thought so
16:34:24 <kmalloc> i could see a "resource option" for immutable though
16:34:32 <lbragstad> cmurphy is there a particular solution your team is looking for?
16:34:40 <knikolla> like a "lock"
16:34:46 <kmalloc> but not inherently immutable
16:34:53 <kmalloc> as in, something that could be toggled.
16:34:54 <lbragstad> are they looking for a "confirm delete" workflow?
16:34:58 <cmurphy> lbragstad: no we're not advocating anything specific, just make it harder to footgun like this
16:35:27 <cmurphy> i suggested maybe just make a "are you sure?" thing in horizon but that doesn't help if you accidentally do this with the cli
16:35:36 <lbragstad> yeah...
16:35:37 <cmurphy> which is a likely scenario in bad scripts
16:36:17 <kmalloc> i think a resource option with an immutable flag (or locked, whatever UX is best) would be great... this is a lot mroe work though since horizon doesn't understand Resource Options
16:36:44 <kmalloc> also, *wince* soft delete(s) in general make recovery easier.
16:37:30 <lbragstad> hmm
16:37:40 <kmalloc> if we implement a resource option for roles, i'd like to see the "cannot be changed/deleted" added to other resources as well via the same mechanism
16:38:08 <lbragstad> to be consistent with other resources, we could implement enabled/disabled for roles and have the default behavior for deleting a role be to disable it first
16:38:22 <cmurphy> lbragstad: the problem with that is it's not backwards compatible
16:38:31 <kmalloc> cmurphy: ++
16:38:34 <lbragstad> true
16:38:42 <kmalloc> we could add an opt-in "this is locked"
16:38:48 <kmalloc> we cannot change basic delete behavior
16:38:51 <kmalloc> (in v3)
16:38:59 <cmurphy> but adding it as a resource option might work, but it would only be useful if the default behavior of bootstrap is to set that flag
16:39:11 <kmalloc> cmurphy: i'm ok with making that the default behavior
16:39:18 <kmalloc> or at least bootstrap to add that as an option
16:39:25 <kmalloc> --make-created-roles-immutable
16:39:25 <knikolla> we can also add keystone doctor checks
16:39:37 <knikolla> your admin role is not locked, an admin might accidentally delete it
16:39:39 <kmalloc> for the transition period
16:39:47 <kmalloc> so 1) add Resource Option
16:40:00 <kmalloc> 2) opt-in via bootstrap (doctor check saying "OMG LCOK THIS")
16:40:08 <kmalloc> 3) default behavior in bootstrap to set flag
16:40:15 <kmalloc> with an opt-out flag.
16:40:16 <knikolla> ++
16:40:27 <kmalloc> over... a release barrier between 2/3
16:40:35 <cmurphy> sounds good to me
16:40:44 <lbragstad> cool - does someone want to write this up?
16:40:47 <cmurphy> i'll bring this back to my teammate to see what they think
16:40:51 <cmurphy> i can write it up as a backlog spec
16:40:56 <kmalloc> cmurphy: ++
16:40:56 <lbragstad> awesome
16:40:57 <cmurphy> probably won't have time to implement it this cycle
16:41:09 <lbragstad> how high of a priority is this for your team?
16:41:10 <kmalloc> we have some need to do resource opptions for projects this cycle
16:41:21 <kmalloc> so it would be not a lot of work to add that construct to roles
16:41:25 <kmalloc> at the same time.
16:41:36 <cmurphy> lbragstad: well the customer recovered from it and the admin is now educated so not very high priority any more :)
16:41:55 <lbragstad> ack
16:42:09 <kmalloc> i also would like to lean on this before we expose the root-domain, so we can limit update and auto-set the immutable flag otherwise
16:42:17 <cmurphy> ++
16:42:19 <lbragstad> at least until the next customer hits it
16:42:24 <kmalloc> rather than needing to exempt it from delete/update/etc apis
16:42:37 <lbragstad> makes sense
16:43:06 <lbragstad> cool - so long as we get the approach written down, that'll be a good start
16:43:29 <knikolla> ++
16:43:35 <kmalloc> and later today (once I get my new monitor) i can start hacking on code/specs again for things this cycle
16:43:43 <lbragstad> anything else here?
16:43:48 <kmalloc> i can lump in resource option additions for roles
16:43:57 <kmalloc> and we can add the immutable work as a followup
16:44:05 <knikolla> kmalloc: uuu new monitor, nice
16:44:20 * kmalloc is planning to expand resource options as a default for all resources
16:44:26 <kmalloc> even if it's unused.
16:44:34 <kmalloc> silly not to
16:44:59 <kmalloc> that way it's trivial to add this type of stuff when needed.
16:45:25 * kmalloc is done with this topic.
16:45:34 <lbragstad> #topic identity provider proxy diagram
16:45:42 <kmalloc> ok so this is VERY rough
16:45:43 <kmalloc> and early on
16:45:49 <kmalloc> https://usercontent.irccloud-cdn.com/file/Au4e3DXb/Keystone%20IDP%20(initial)%20Diagram.png
16:46:15 <kmalloc> this will get massively refined and have a DB schema diagram added as well as a UI site-map-y target diagram
16:46:20 <cmurphy> #link https://usercontent.irccloud-cdn.com/file/Au4e3DXb/Keystone%20IDP%20(initial)%20Diagram.png IdP diagram
16:46:33 <kmalloc> and this one will be split into a single diagram per-workflow
16:46:41 <kmalloc> it doesn't show autoprovisioning
16:46:53 <kmalloc> with that said, this is starting to show what the target of Keystone should be
16:47:05 <kmalloc> and takes an initial stab at data-flows.
16:47:49 <kmalloc> please forgive the fact i did this at like... 3am in the morning
16:47:59 <cmurphy> i like the icons
16:48:14 <kmalloc> once i iterate a bit more we'll land this in a common/official place
16:48:14 <cmurphy> suitcase == assignment
16:48:18 <kmalloc> cmurphy: :)
16:48:33 <kmalloc> draw.io is pretty badass with the icons it has
16:48:59 <kmalloc> and i'll render this as an .svg for our official space so we can iterate on it as things change within keystone
16:49:53 <kmalloc> any questions/concerns.... happiness?
16:50:08 <knikolla> seems fairly standard federation
16:50:24 <kmalloc> yeah. it's just trying to give us an explicit target to reference
16:50:25 <lbragstad> what's the difference between black highlight and white highlighting in the flows?
16:50:36 <kmalloc> lbragstad: just so you could see the different ones
16:50:39 <kmalloc> lbragstad: grouping
16:50:54 <kmalloc> i will split those into separate diagrams down the line
16:50:58 <lbragstad> ok
16:51:12 <kmalloc> so non-openstack SPs, OpenStack SPs, Keystone Crud as an SP, and JS-UI
16:51:30 <kmalloc> those will be data flow, and indicate autoprovision where needed.
16:51:57 <kmalloc> i hope this is helping folks see what is in my head (as early as it is)
16:52:07 <kmalloc> and each will be it's own diagram
16:52:42 <lbragstad> ok
16:52:58 <lbragstad> kmalloc how do you want feedback, just pings for now?
16:53:11 <knikolla> devil will be in the details
16:53:30 <kmalloc> lbragstad: yeah
16:53:50 <kmalloc> since this is a first pass, it's just a "hey, everyone happy with the start of this direction?"
16:54:19 <lbragstad> ok
16:54:19 <lbragstad> i'll pick through this a bit more
16:54:26 <lbragstad> thanks for putting this together kmalloc
16:54:29 <kmalloc> expect it is missing most of the stuff still
16:54:31 <kmalloc> :)
16:54:39 <lbragstad> anything else on this?
16:54:40 <kmalloc> it will get better with iterations
16:54:44 <kmalloc> nothing else. i'm done
16:54:49 <lbragstad> #topic open discussion
16:55:19 <lbragstad> there has been a trend for people to just hold meetings in their respective IRC channels
16:55:34 <lbragstad> how do people here feel about that?
16:55:39 <cmurphy> -1
16:56:04 <cmurphy> it's nice to have it in a shared channel because we tend to pull in people from other projects randomly
16:56:27 <lbragstad> true
16:56:48 <cmurphy> also we get enough traffic in the main channel that i think it's better to split out the meeting so that people asking questions dont' feel like they have to wait for the meeting to be over
16:57:34 <lbragstad> ok - that's fair
16:57:55 <lbragstad> anything else for open discussion?
16:58:09 <kmalloc> -1
16:58:18 <kmalloc> same reason supplied as cmurphy
16:59:15 <lbragstad> alright - with that, we're about out of time
16:59:34 <lbragstad> thanks for attending
16:59:46 <lbragstad> #endmeeting