17:01:35 <lbragstad> #startmeeting keystone-office-hours
17:01:36 <openstack> Meeting started Tue Jul 10 17:01:35 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:40 <openstack> The meeting name has been set to 'keystone_office_hours'
17:01:41 <kmalloc> LOL
17:01:51 * lbragstad shrugs
17:09:54 <tosky> ehm, is there some specific topic or can I (re)ask a question?
17:16:19 <lbragstad> tosky: no - this is just office hours
17:18:05 <lbragstad> tosky: the failure linked in the patch is just warning though - it looks like keystone isn't preventing nova from responding?
17:20:15 <tosky> lbragstad: I may have swapped the working and the failing log
17:20:33 <lbragstad> pass http://logs.openstack.org/02/579602/2/check/openstack-ansible-functional-ubuntu-xenial/a54186d/logs/openstack/openstack1/nova/nova-api-wsgi.log.txt.gz#_2018-07-03_00_14_49_783
17:20:39 <lbragstad> fail http://logs.openstack.org/14/573514/3/check/openstack-ansible-functional-ubuntu-xenial/88d0dd9/logs/openstack/openstack1/nova/nova-api-wsgi.log.txt.gz#_2018-06-27_06_32_09_753
17:20:40 <lbragstad> ?
17:21:40 <tosky> yes, I swapped the label, sorry
17:21:55 <lbragstad> keystonemiddleware doesn't actually throw an error there - http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n385
17:22:00 <lbragstad> it's just a warning i believe
17:22:02 <tosky> the working log shows the warning, and it works
17:22:22 <tosky> the failing log (marked incorrectly as PASS) throws a 401 on that operation which was working before
17:29:41 <tosky> so the question is: is that an error in nova? (which apparently can pass the tempest tests)? Should sahara change something there?
17:33:47 <lbragstad> tosky: sounds related to https://bugs.launchpad.net/keystone/+bug/1779889
17:33:47 <openstack> Launchpad bug 1779889 in OpenStack Identity (keystone) "Lack of documentation for validating expired tokens with service users" [Medium,Triaged]
17:34:01 <lbragstad> can you confirm that the nova service is using a service token?
17:34:21 <lbragstad> the irc log in that bug report goes into detail about how service tokens work
17:35:43 <tosky> uh, I'm not sure about the nova configuraton, but I can check how it was setup
17:36:05 <tosky> but shouldn't the bug be visible also with some other tests?
17:36:25 <lbragstad> nova's configuration file will have a section in it for keystone_authtoken
17:36:52 <lbragstad> so if a deployment tool is setting that up to use service tokens, but not setting up the service user properly, then you'll likely have a problem
17:39:38 <tosky> apparently not: http://logs.openstack.org/86/569886/7/check/openstack-ansible-functional-centos-7/e34b95c/logs/etc/openstack/openstack1/nova/nova.conf.txt.gz
17:40:43 <tosky> the change that introduced service_token_roles_required=true did not add anything else relevant to [keystone_authtoken]: https://review.openstack.org/#/c/578618/
17:44:41 <lbragstad> tosky: https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L554
17:45:05 <lbragstad> so osa is setting https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L210-L215 to true
17:45:16 <lbragstad> but https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L202-L209 is still the default of 'service'
17:45:28 <lbragstad> so a "service token" is considered a token with a role named "service" in it
17:45:46 <lbragstad> does osa have that role and does it use it with nova?
17:45:56 <lbragstad> if not, that's probably causing the issue
17:46:29 <tosky> I suspect it does not, but I will raise the question (aka: a bug)
17:46:45 <tosky> it looks like the source of the issue
17:48:02 <tosky> oooh, thanks for askin there
17:48:04 <tosky> asking*
17:48:19 <lbragstad> yep
18:54:16 <lbragstad> gagehugo: didn't we have a bug open for https://review.openstack.org/#/c/576640/ ?
18:54:48 <gagehugo> lbragstad did we?
18:55:03 <lbragstad> i'm parsing the meeting logs and i thought we said something about it?
18:55:12 <lbragstad> maybe i'm imagining things
18:58:07 <gagehugo> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-175
18:59:06 <gagehugo> I didn't make one, I can though
18:59:38 <lbragstad> no worries - it probably isn't necessary
18:59:47 <lbragstad> i was just double checking
19:18:48 <nicodemus_> Hello!
19:19:16 <nicodemus_> I've configured keystone federation, with Keystone acting as an SP with an external IdP
19:19:58 <nicodemus_> Login works just fine, but if I logout and then try to login again, I'm not asked for my user/pass (as if the session was never destroyed)
19:20:42 <nicodemus_> Has anyone seen something like that? I'm unsure where to begin looking (keystone logs don't show any error
19:25:39 <lbragstad> i have not personally experienced that
19:26:18 <lbragstad> kmalloc: we should revisit https://review.openstack.org/#/c/555279/
19:27:01 <cmurphy> nicodemus_: that's normal, your idp stores a cookie saying you are logged in and there's no way for horizon to be aware of that so logging out of horizon doesn't affect it
19:27:21 * kmalloc looks
19:27:24 <cmurphy> there might be an endpoint/button you can go to on your idp to log out of it directly
19:27:24 <lbragstad> thanks cmurphy
19:27:27 <cmurphy> or you can clear your cookies
19:30:08 <cmurphy> it'll also time out eventually
19:44:30 <nicodemus_> cmurphy: so, if I logout from horizon that doesn't trigger a logout to the IdP?
19:45:01 <nicodemus_> I imagined the logout endpoints from the Mellon metadata would somehow handle the logout
19:46:11 <cmurphy> nicodemus_: you're right that should be possible but I don't think we've hooked that up between horizon and keystone and saml
19:52:21 <nicodemus_> cmurphy: got it. So at least for now, I cloud say that login works fine but logout needs to be done outside of horizon
19:52:45 <cmurphy> nicodemus_: yes
19:53:00 <nicodemus_> thanks a lot!
19:57:35 <kmalloc> lbragstad: yeah we should revisit that cleanup
20:02:56 <lbragstad> http://flask.pocoo.org/docs/1.0/quickstart/#unique-urls-redirection-behavior explains some of the stuff we had to fix in our implementation
20:03:12 <lbragstad> in case anyone else is wondering about the 418 Teapot stuff in the flaskification review
20:03:17 <lbragstad> reviews*
20:08:11 <kmalloc> yeah, we had some weirdness
20:08:44 <kmalloc> the 418 teapot stuff [yes we can change the error code]
20:09:44 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add docs for case-insensitivity in keystone  https://review.openstack.org/576640
20:10:06 <kmalloc> we also had a number of cases where [even before flask] we referenced an incorrect url and got a 404
20:10:11 <kmalloc> we expected a 404 in our tests
20:10:16 <kmalloc> but it was the wrong kind of 404
20:11:28 <kmalloc> it was "app level" 404 not "not found resource" 404
20:11:55 <kmalloc> lbragstad: do you want me to move from 418 to something else, like 499 or something for testing?
20:12:47 <kmalloc> it isn't hard to change that code out... but, *shrug* i like 418, it wont be used for anything serious
20:29:24 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add docs for case-insensitivity in keystone  https://review.openstack.org/576640
20:56:32 <lbragstad> yeah - doesn't matter to me i don't thik
20:56:35 <lbragstad> think*
20:56:40 <lbragstad> i understand the reasoning for it now
21:17:08 <lbragstad> #endmeeting