19:02:25 <lbragstad> #startmeeting keystone-office-hours
19:02:26 <openstack> Meeting started Tue Aug 22 19:02:25 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:30 <openstack> The meeting name has been set to 'keystone_office_hours'
19:03:58 <knikolla> o/ reporting for office hours
19:04:23 <lbragstad> kmalloc: mind lifting your -2 here? https://review.openstack.org/#/c/496343/
19:04:38 <lbragstad> we'll need that based on how reno operates
19:04:41 <kmalloc> in pike?
19:04:47 <kmalloc> we didn't land the pike change did we?
19:04:57 <kmalloc> just the master one(s)?
19:05:07 <lbragstad> we need to ignore those release notes from rendering in pike release notes
19:05:23 <kmalloc> right, we landed the change in pike?!
19:05:26 <kmalloc> or just master
19:05:36 <lbragstad> yes - let me grab the link
19:05:42 <kmalloc> want to be sure.
19:05:45 <kmalloc> related: ugh
19:06:11 <lbragstad> #link https://github.com/openstack/keystone/commit/77500b3615ae94ea45837f3fc0d503c8aadcc462
19:06:11 <kmalloc> can we just make this a tree of static files instead? [i know not today[]
19:06:53 <kmalloc> lbragstad: that landed in master 8 days ago
19:06:59 <kmalloc> stable/pike was already split
19:07:02 <kmalloc> right?
19:07:26 <kmalloc> https://review.openstack.org/#/c/496312/
19:07:30 <kmalloc> not landed.
19:07:46 <lbragstad> https://docs.openstack.org/releasenotes/keystone/pike.html
19:07:53 <lbragstad> ^ they still render there for the pike notes
19:07:58 <lbragstad> because those links changed
19:08:13 <kmalloc> how did the links change in the pike branch?
19:08:17 <kmalloc> we didn't land the change
19:08:28 <kmalloc> something is broken in the rendering systme not in our repo then
19:08:35 <kmalloc> it's rendering from master not stable/pike
19:08:47 <kmalloc> land the ignore in master, we have to do that
19:08:52 <kmalloc> but we shouldn't need to in pike
19:09:04 <kmalloc> if we do, something else is broken
19:09:35 <kmalloc> i think we horked this up becuase i think the reno is always rendered from master
19:09:42 <kmalloc> meaning we are effecitvely broken
19:09:51 <kmalloc> on the docs page
19:10:43 <lbragstad> https://review.openstack.org/#/c/492774/
19:11:34 <kmalloc> if we did not land a change to the release notes on stable/pike how are the changed links effecting the release notes
19:11:55 <kmalloc> this really is not making sense.
19:12:13 <lbragstad> kmalloc: want me to see if dhellmann will join us here?
19:12:14 <kmalloc> if those are rendering in pike and the fix landed in master we have a bigger problem.
19:12:17 <kmalloc> sure.
19:12:44 <kmalloc> i am guessing things are not rendering from the right places
19:13:22 <lbragstad> kmalloc: that would appear to be the case
20:37:20 <openstackgerrit> Merged openstack/keystone master: Include a link in release note for bug 1698900  https://review.openstack.org/496322
20:37:22 <openstack> bug 1698900 in OpenStack Identity (keystone) "DB check appears to not be working right" [High,Fix released] https://launchpad.net/bugs/1698900 - Assigned to Lance Bragstad (lbragstad)
20:55:10 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Clarify documentation for release notes  https://review.openstack.org/496417
20:56:22 <lbragstad> cc kmalloc ^
20:56:28 <lbragstad> i also had to update https://review.openstack.org/#/c/496343/
20:59:29 <openstackgerrit> Merged openstack/keystone master: Remove missing release note from previous revert  https://review.openstack.org/496342
21:01:19 <lbragstad> sweet - https://review.openstack.org/#/c/496343/ is the only thing we need for rc3
21:09:28 <mjax> Anyone know what the middleware module in keystone does? I'm having some trouble with understanding its functionality
21:17:18 <lbragstad> mjax: are you referencing https://github.com/openstack/keystone/tree/master/keystone/middleware or https://github.com/openstack/keystonemiddleware ?
21:17:54 <mjax> lbragstad: /keystone/keystone/middleware
21:18:30 <lbragstad> mjax: ah - so that's "middleware" that runs in the paste pipeline in front of keystone
21:19:07 <mjax> lbragstad: is it mainly in charge of interacting with wsgi? Does it have any specific connection to keystonemiddleware?
21:19:50 <lbragstad> mjax: no - not really, keystonemiddleware is a separate project that is designed to run in front of other services
21:20:46 <lbragstad> mjax: for example json_body middleware runs in front of keystone
21:20:54 <lbragstad> as noted in the paste pipeline
21:20:56 <lbragstad> https://github.com/openstack/keystone/blob/master/etc/keystone-paste.ini#L16
21:21:08 <lbragstad> and following the entry point here - https://github.com/openstack/keystone/blob/master/setup.cfg#L195
21:21:38 <mjax> lbragstad: I see, was curious because of the shared name and the import in auth.py
21:22:10 <lbragstad> mjax: yeah - keystone/middleware is specific to keystone
21:22:25 <lbragstad> keystonemiddleware is a generic middleware for other openstack services to use
21:22:38 <lbragstad> (e.g. keystonemiddleware is what sits in front of nova or cinder)
21:24:27 <mjax> lbragstad:  thanks, got it. By the way is the /keystone/auth the first point where keystone tries to authenticate a user? Will services also authenticate from there
21:25:19 <lbragstad> both services and users interact with the same endpoint for authentication
21:25:52 <mjax> which endpoint is that?
21:26:00 <lbragstad> either /v2.0/tokens or /v3/auth/tokens
21:26:10 <lbragstad> GET /v3/auth/tokens is validate token
21:26:16 <lbragstad> and POST /v3/auth/tokens is authenticate for token
21:26:29 <mjax> hmm I see, will the token differ depending on whether its a service or user trying to authenticate
21:27:36 <lbragstad> no - keystone doesn't know if it's a service or a user authenticating
21:28:24 <lbragstad> services like nova have a service account (e.g. a user named nova) that they use to make API requests
21:32:05 <mjax> right - how do the service account's password and credentials get set or passed? If I were to write an auth plugin that expects a password to an external SSO for that user, would I just have to include multiple case statements to catch the special case for users?
21:32:56 <lbragstad> mjax: those are included in each services configuration file
21:33:13 <mjax> also, it is /keystone/auth that handles the requests to the authentication endpoint right?
21:34:16 <mjax> oh so thats how it works!
21:34:17 <lbragstad> mjax: as in how does nova authenticate to keystone?
21:34:31 <lbragstad> nova uses the keystoneauth1 library to authenticate to keystone
21:34:49 <lbragstad> and keystonemiddleware to run process tokens before they reach nova's api
21:35:07 <mjax> when you make a request to /auth/v3/tokens a json request body is passed in right? which module is in charge of breaking that down to do the authentication
21:37:14 <lbragstad> that's this endpoint
21:37:29 <lbragstad> https://github.com/openstack/keystone/blob/master/keystone/auth/routers.py#L27
21:37:44 <lbragstad> which routes the request based on the request method (GET, POST, etc.)
21:37:51 <lbragstad> to the appropriate controller method
21:38:29 <lbragstad> so when you do a POST /v3/auth/tokens you can see the router wire the call to authenticate_for_token()
21:38:30 <lbragstad> https://github.com/openstack/keystone/blob/master/keystone/auth/routers.py#L30
21:38:57 <lbragstad> which is found here - https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L107
21:39:54 <mjax> That clears up a lot! Thank you
21:40:33 <lbragstad> mjax: yep
21:40:49 <lbragstad> fwiw - that pattern can be applied to all apis in keystone
21:41:09 <lbragstad> traffic comes in from the router -> controller -> core -> backend
21:42:50 <mjax> lbragstad: then the controller calls the corresponding core's methods which make use of the relevant backend? Makes sense
21:43:17 <lbragstad> yep - it's a pretty straight forward app
21:44:38 <mjax> lbragstad: I'm still quite a newbie to dev and design patterns, so this is really helpful! Thanks again for going over it for me
21:50:53 <aahh> hi , could someone shed some light on how to store users locally  who are authorized using a custom identity backend which is not implemented via a saml or oauth protocol
21:53:23 <lbragstad> mjax: anytime!
21:54:06 <lbragstad> aahh: what release are you using?
21:54:38 <aahh> @lbragstad : ocata
21:54:55 <lbragstad> aahh: are you familiar with shadow users?
21:55:20 <aahh> not yet , had been reading the specs docs on the ocata release. would be helpful on how its created and mapped
21:55:48 <lbragstad> aahh: that works started in ocata
21:55:52 <lbragstad> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/shadow-users.html
21:56:01 <lbragstad> and continued into newton
21:56:02 <lbragstad> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/newton/shadow-users-newton.html
21:56:21 <lbragstad> but the idea was that users should have some sort of reference stored within keystone regardless of where they authenticate from
21:56:55 <lbragstad> meaning they could be authenticated through federation using a SAML assertion of some sort, or an external LDAP instance
21:57:34 <lbragstad> assuming the authentication is successful - a user reference is created for that user
21:57:41 <lbragstad> and stored within keystone
21:58:01 <aahh> could you point to me the relevant files where this happens ??
21:58:28 <lbragstad> aahh: yeah - so all of that should be pretty self contained in keystone's identity API
21:58:46 <lbragstad> which is here - https://github.com/openstack/keystone/tree/3e8f16dec47907bdded68e58880779a74bbeffef/keystone/identity
21:58:54 <lbragstad> er - it starts there
21:59:56 <lbragstad> aahh: from there you can see how the shadow_user_api is used in the business logic for identity - https://github.com/openstack/keystone/blob/3e8f16dec47907bdded68e58880779a74bbeffef/keystone/identity/core.py#L442
22:00:27 <lbragstad> the interfaces and backend for storing shadow users is kept here - https://github.com/openstack/keystone/tree/3e8f16dec47907bdded68e58880779a74bbeffef/keystone/identity/shadow_backends
22:01:36 <lbragstad> #endmeeting