18:58:04 <lbragstad> #startmeeting keystone-office-hours
18:58:05 <openstack> Meeting started Tue Sep 26 18:58:04 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:58:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:58:08 <openstack> The meeting name has been set to 'keystone_office_hours'
19:00:27 <gagehugo> I think the gerrit changes broke the office hours bookmark
19:01:02 <shewless> HOLY CRAP: truncate revocation_event
19:01:12 <shewless> openstack stack list now takes <1s
19:01:16 <shewless> token or ldap
19:01:26 <shewless> THANK you kmalloc and @lbragstad
19:01:27 <shewless> so good
19:01:31 <shewless> much better than 10 seconds
19:01:48 <gagehugo> https://review.openstack.org/#/c/504084/ stable/pike doc change that closes 2 bugs
19:04:10 <lbragstad> shewless: awesome - that should be much more consistent once you have Newton deployed
19:04:27 <lbragstad> since the index will be in place and we write a *lot* less events to that table
19:19:52 <hrybacki> https://review.openstack.org/#/c/507434/1 stable/octa backport that also closes bug
19:22:48 <shewless> yes looking forward to newton/ocata. Almost done upgrading in our staging environment
19:44:10 <lbragstad> shewless: each revocation event has an attribute called 'revoked_at'
19:44:24 <lbragstad> you could programmatically remove revocation events based on that attribute
19:45:15 <lbragstad> if the revoked_at time is older than time.now() - CONF.token.expiration_time, then you should be good to safely remove the revocation event
19:52:06 <shewless> @lbragstad: thanks!
20:45:38 <kmalloc> lbragstad: or we could publish the driver that disables rev events
20:45:39 <kmalloc> :P
20:47:06 <lbragstad> kmalloc: driver that disabled revocation events?
20:51:41 <kmalloc> lbragstad: we talked about it in the past
20:51:49 <kmalloc> basically just didn't store rev events at all
20:51:55 <kmalloc> for deployments that don't want it
21:32:53 <lbragstad> edmondsw: updated https://review.openstack.org/#/c/500141/4
21:33:16 <edmondsw> lbragstad ack
21:33:34 <lbragstad> i tried bending my head around the best way to document the use cases
21:33:42 <lbragstad> i ended up using examples to illustrate the point
21:53:41 <lbragstad> edmondsw_: done with https://review.openstack.org/#/c/500207/1 too
22:00:14 <openstackgerrit> Lance Bragstad proposed openstack/keystone-specs master: Clarify backlog instructions and add ideas dir  https://review.openstack.org/505057
22:11:13 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Refactor test_backend_ldap tests  https://review.openstack.org/507694
23:14:20 <openstackgerrit> Gage Hugo proposed openstack/keystone master: WIP - Refactor test_backend_ldap tests  https://review.openstack.org/507694
09:53:51 <openstackgerrit> Thomas Duval proposed openstack/oslo.policy master: Modification to add additional information in the HTTPCheck request.  https://review.openstack.org/498467
12:44:35 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
12:52:48 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
13:01:09 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
13:09:04 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
13:10:31 <openstackgerrit> Suramya proposed openstack/keystone master: Reorganize api-ref: v3 domains  https://review.openstack.org/505135
13:24:38 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
13:32:31 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
13:40:56 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
13:45:23 <openstackgerrit> Merged openstack/oslo.policy master: Modification to add additional information in the HTTPCheck request.  https://review.openstack.org/498467
13:48:48 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
14:58:26 <hrybacki> lbragstad: regarding https://review.openstack.org/#/c/507434 -- I did confirm that the patch is in both master and stable/pike
14:59:45 <lbragstad> hrybacki: so https://review.openstack.org/#/c/507434 is a backport to stable/ocata from https://review.openstack.org/#/c/465530/ which merged to master 30 hours ago
15:01:08 <hrybacki> lbragstad: it was cherry-picked against ocata 30 hours ago but on master (now Pike) on Aug 1 IIRC
15:01:34 <knikolla> o/
15:01:58 <lbragstad> hrybacki: bah - i'm backwards today
15:02:10 <hrybacki> lbragstad: no worries: https://github.com/openstack/keystone/commit/630d9b58fd957e8bb27a99ac5cd73a58826c6fc2 for verifcation
15:02:17 <hrybacki> o/ knikolla
15:05:23 <hrybacki> any cores able to review/+2 ^^? I know there are two LP's associated with it and live deployments being affected
15:08:00 <lbragstad> hrybacki: kmalloc and stevemar should kick that through
15:14:15 <hrybacki> lbragstad: ack, thanks
15:31:22 <gagehugo> o/
15:51:35 <kmalloc> Will do shortly
15:51:42 <kmalloc> Getting setup for the day
16:36:18 <kmalloc> lbragstad: pushed through
16:36:24 <hrybacki> kmalloc++
16:36:29 <hrybacki> thanks!
16:53:35 <stevemar> lbragstad: ?
16:55:49 <hrybacki> stevemar there was a review being backported but it's now approved
17:09:05 <kmARC> hi all, I'm trying to figure out how to connect to keystone via CLI. Using openstackclient >v3.0.0 I have multiple options, like v3oidc{clientcredentials,password}. Unfortunately both these result in a HTTP405, Method not allowed error. Reason is, the auth plugin tries to `POST` to my keycloak IDP server at one point, however it says: "Allow: HEAD, GET, OPTIONS"
17:09:21 <kmARC> _authentication_ seems to work, if I give in a wrong password, I get authentication error
17:09:37 <kmARC> The current setup also works with horizon
17:09:44 <openstackgerrit> Davanum Srinivas (dims) proposed openstack/oslo.policy master: External Policy hook should support SSL  https://review.openstack.org/491783
17:09:49 <kmARC> Any insights where I should start looking?
17:10:04 <stevemar> hrybacki: yay
17:11:38 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
17:19:19 <openstackgerrit> Davanum Srinivas (dims) proposed openstack/oslo.policy master: http/https check rules as stevedore extensions  https://review.openstack.org/507098
17:19:24 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
17:56:55 <openstackgerrit> Lance Bragstad proposed openstack/keystone-specs master: Specification for system roles  https://review.openstack.org/464763
17:57:14 <lbragstad> knikolla: cmurphy hrybacki kmalloc ^
17:57:27 <hrybacki> woo
17:57:32 <lbragstad> i reworked the entire global roles specification to fit the conversations from the PTG
17:57:37 <kmalloc> lbragstad: https://review.openstack.org/#/c/507098/6 please note my comment
17:57:48 <kmalloc> oslo.policy related things
17:57:53 <lbragstad> i also added a section that highlights the difference between system and global
17:57:55 <lbragstad> kmalloc: ack
17:58:13 <lbragstad> cc dims ^
17:58:41 <kmalloc> mordred: https://review.openstack.org/#/c/464763/17 (see above), this is of interest to you, shade, and generally people running/consuming clouds (cc fungi ) would like your views as well
17:58:59 <dims> lbragstad : ack thanks will line it up for later
17:59:21 <mordred> lbragstad, kmalloc: ack. it's open in a window
18:03:11 <kmalloc> lbragstad: one comment, but otherwise that represents what we discussed
18:03:20 <kmalloc> lbragstad: i'd like to see what other folks thing
18:03:22 <kmalloc> think*
18:03:29 <lbragstad> same here
18:03:44 <lbragstad> fwiw - it felt way more natural to use the term system over global
18:04:49 <kmalloc> yeah, that bit makes this a lot easier to understand
18:05:20 <lbragstad> right - its a lot more clear what a "system" operation is versus a "global" operation
18:08:09 <kmalloc> dims: removed the -1, entrypoints are a security risk
18:08:22 <lbragstad> I also modified the path to include system, which i think will help if we eventually want make it a hierarchy
18:09:02 <kmalloc> dims: i would, given full license to do so, remove their uses from openstack or at least keystone and all security-related things
18:09:52 <kmalloc> but i wont hold this up. i've voiced my concerns
18:10:25 <dims> kmalloc : if we get to a point when someone can inject a python package to be installed ... they already own you. no?
18:10:28 <dims> kmalloc : ack and thanks
18:10:45 <kmalloc> not really, you can register any entrypoint namespace
18:11:01 <kmalloc> this could allow *any* pythong package to register something that could be loaded by oslo.policy
18:11:30 <kmalloc> and if the module conflicts... you get both back, depending on how things are built in stevedore among other places you could grab the wrong one
18:11:35 <kmalloc> which is name-sorted
18:11:57 <kmalloc> it's ... lets just say entrypoints are not fun in this regard
18:11:57 <dims> understood kmalloc
18:35:00 <cfriesen_> just wondering if there is any documentation on what caching backends are recommended for keystone.  I found https://docs.openstack.org/keystone/latest/admin/identity-caching-layer.html but it doens't really have opinions.
18:36:43 <cfriesen_> kmalloc: with respect to https://review.openstack.org/#/c/505345/ (limiting the endpoints returned) are you saying that "give me the endpoints for this region/service-type" would be slower than "give me all the endpoints for all service types across ~20 regions"?
18:41:37 <kmalloc> in keystone, yes
18:41:52 <kmalloc> it is likely going to be much slower on the keystone side due to how we pull the data from the db
18:42:00 <kmalloc> in the clinet, parsing the data will be faster.
18:42:04 <kmalloc> it'll be a tradeoff
18:45:17 <kmalloc> cfriesen_: i haven't had time to look at the implications
18:47:40 <hrybacki> anyone here muck with aws / ec2 stuff?
19:09:55 <cfriesen_> kmalloc: no worries...I expected that we would be able to retrieve the service based on the type, and then look up the endpoint based on the region and service_id.  I assumed this would be faster than retrieving maybe 100+ endpoints and formatting them to send in the response.
19:10:45 <kmalloc> I think we need a lot more index to do that.
19:10:59 <kmalloc> Which is... Painful with the rolling upgrade support.
20:50:35 <lbragstad> kmalloc: ping
20:50:56 <kmalloc> lbragstad: pong
20:51:05 <lbragstad> kmalloc: so you know how we had the system roles discussion
20:51:09 * kmalloc plays atari with lbragstad
20:51:13 <kmalloc> uh, yeah
20:51:39 <lbragstad> and we talked about making the system assignment stuff a lot simpler than the existing assignment api (less kwargs and more explicit methods)?
20:52:30 <lbragstad> kmalloc: do you think it's fine to add a bunch of methods like `list_system_grants_for_user`, `list_system_grants_for_group`, etc...
20:52:59 <kmalloc> hm.
20:53:08 <lbragstad> like - in the assignment backend?
20:53:09 <kmalloc> i don't think it's an issue
20:53:26 <lbragstad> then everything is invoked by the manager?
20:53:31 <kmalloc> yeah.
20:53:34 <lbragstad> ok
20:53:58 <lbragstad> i'm working through the implementation now and realizing how many method signatures are going to be added to that backend
21:45:56 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Add a new table for system role assignments  https://review.openstack.org/507993
21:45:56 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Implement backend logic for system roles  https://review.openstack.org/507994
22:58:42 <openstackgerrit> Merged openstack/keystone master: Migrate to stestr  https://review.openstack.org/504442
00:04:13 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
00:12:00 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
00:23:05 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
00:30:34 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
00:38:28 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
00:46:02 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
00:51:30 <SamYaple> not having much luck figuring out why this is happening http://paste.openstack.org/show/622098/
00:53:56 <SamYaple> it could be a redherring for the issue im having though
02:05:23 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
02:13:08 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
02:56:46 <lbragstad> SamYaple: what's the situation look like?
02:56:57 <lbragstad> are you just seeing that for token validation?
02:57:44 <SamYaple> lbragstad: `openstack server list --all` is hanging. I am getting that in the logs. it is from ksa_exceptions.NotFound
02:57:49 <SamYaple> it doesnt happen always
02:57:59 <SamYaple> and i can't reproduce it outside of the nova logs
02:58:08 <lbragstad> huh - weird
02:58:18 <SamYaple> im suspecting a timeout issue... is it possible it presents that way?
02:58:24 <lbragstad> i assume you can get a token as that user and validate it?
02:58:29 <SamYaple> indeed
02:58:59 <lbragstad> i'm not aware of timeouts coming through as 404s from ksa
02:59:04 <SamYaple> if nova is failing to lookup, say, endpoints would it throw a NotFound? (i dont really understand when NotFound would be thrown)
02:59:05 <lbragstad> cc mordred efried kmalloc ^
02:59:28 <lbragstad> the error message seems totally specific to token validation
03:00:02 <SamYaple> right, but https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/exceptions/http.py#L146
03:00:07 <SamYaple> what "resource" is it refering too?
03:01:12 <lbragstad> that might be something general
03:01:18 <lbragstad> as in any keystone resource...
03:01:21 <lbragstad> let me check something
03:04:37 <lbragstad> that error string doesn't actually appear in the ksa source from what i can tell
03:04:50 <SamYaple> its in keystonemiddleware
03:04:52 <lbragstad> do the keystone logs emit a 404?
03:04:53 <lbragstad> oh
03:05:13 <SamYaple> its just catching the exception NotFound from keystoneauth
03:06:13 <lbragstad> aha
03:06:14 <lbragstad> yeah
03:06:29 <lbragstad> i wonder if the discovery bits are tripping somewhere?
03:06:45 <SamYaple> well thats just it, it doesnt happen always
03:07:04 <SamYaple> as i said, *I* can't reproduce it, and it only exists in nova logs
03:07:35 <SamYaple> `openstack server list` returns fine, `openstack server list --all` breaks most of the time, and sometimes I get that error
03:12:29 <lbragstad> that's strange - this is the first i've heard of something like this with ksa+ksm
03:12:34 <lbragstad> what version of ksa are you using?
03:14:03 <SamYaple> 3.2.0, but i did revert 2.18 or so (stable/ocata upper-constraints) because i know 3.2.0 had that fun discovery stuff
03:14:07 <SamYaple> same behaviour with both
03:14:24 <SamYaple> (i need 3.2.0 for the latest version of shade which im using, but again, i tested without it)
03:16:15 <lbragstad> hmm
03:16:44 <SamYaple> i dont think keystone is broken to be honest. i did a few hours ago, but after walking through the code i think this is something else and this is a symptom
03:17:10 <SamYaple> the fact youve never heard or seen this kinda confirms that to me
03:21:23 <SamYaple> thanks for your insight. im going to call it for the night. ping me if you think of anything else lbragstad
03:21:51 <lbragstad> SamYaple: will do - thanks for bringing it up
03:22:02 <lbragstad> SamYaple: i'll sync with mordred tomorrow and see if he has any ideas
03:27:48 <mordred> lbragstad, SamYaple: I'm not really here - but will help look at it tomorrow
04:38:59 <mani_> hi anyone can help
04:39:00 <mani_> http://paste.openstack.org/show/622103/
04:39:48 <mani_> Run Cmd: openstack endpoint list
05:52:51 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
06:03:17 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
12:29:26 <efried> SamYaple lbragstad I took a quick look at that NotFound thing.
12:29:37 <efried> I don't believe it's ksa's NotFound exception.
12:29:51 <efried> I believe it's keystone's TokenNotFound exception.
12:33:05 <efried> Are we perchance using TokenlessAuth and providing an unversioned auth_url?
12:37:08 <efried> Mm, I take back the thing about ksa's NotFound.  That guy is involved.
13:02:43 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
13:10:38 <openstackgerrit> OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements  https://review.openstack.org/470137
13:40:58 <kmARC> Hey guys, I'm still being driven crazy with cli auth for OpenID
13:41:02 <kmARC> anyone has expertise in this?
13:41:25 <kmARC> or an easy alternative (like, a user could get an access token from horizon, after logged in securely with openID)
13:44:35 <lbragstad> kmARC: do you have a list of steps to recreate?
13:45:42 <kmARC> - Installed Keycloak IDP. Configured, works well with Horizon.
13:45:42 <kmARC> - Trying to use cli. No idea how to configure.
13:45:51 <kmARC> That's it basically :-)
13:46:39 <kmARC> right now my problem is that the v3oidcpassword plugin somehow tries to POST login data to one of the keycloak endpoints, however keycloak reports that HEAD, GET, OPTIONS are the only allowed operations
13:47:14 <kmARC> I can see that the auth part works - a token is generated. If I screw up the password, I would get an authn error
13:47:23 <kmARC> *authn part works
13:53:36 <kmARC> also it works flawlessly through horizon so far.
13:54:25 <kmARC> If my users had any means of getting a client_secret/token/whatever through horizon with which they could configure their openrc, that'd be also fine
14:00:07 <openstackgerrit> OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements  https://review.openstack.org/500005
14:02:50 <lbragstad> kmARC: you're not following a writeup of some kind, are you?
14:03:22 <kmARC> now I tried to follow the Nash-Topol-Martinelli book, the error is the same
14:03:50 <kmARC> https://books.google.ch/books?id=MZcpCwAAQBAJ&pg=PA91&lpg=PA91&dq=5.5.3+testing+it+all+out&source=bl&ots=bhqVpsW3tw&sig=FROSoOn_RcydyvG6114j25QECtY&hl=en&sa=X&ved=0ahUKEwiwqJX_hcjWAhXmDZoKHQwjDPoQ6AEIKDAA#v=onepage&q=5.5.3%20testing%20it%20all%20out&f=false
14:04:08 <kmARC> Section 5.5.3 Testing it all out
14:04:37 <kmARC> it lists a short python snippet to try to authenticate with the v3 oidc password plugin
14:05:16 <kmARC> lbragstad do you have a recommendation on what writeup to follow?
14:05:50 <lbragstad> kmARC: not really - that's why i was curious if you were following a specific one
14:05:59 <lbragstad> stevemar: ^
14:06:19 <lbragstad> i think knikolla uses keycloak at BU?
14:07:04 <knikolla> lbragstad: not yet, but just did a POC for that.
14:08:05 <kmARC> keep in mind, it works beautifully through horizon
14:08:33 <knikolla> didn't get time to test the cli yet.
14:08:45 <knikolla> only the horizon flow for now.
14:08:49 <kmARC> right now I'm at a point where I'd rather implement a small service that gives my users a long lived token/clien_secret and configure keystone to accept that.
14:10:23 <kmARC> knikolla: what kind of solution do you provide to your users with cli on the system where you have the horizon flow in place?
14:12:35 <knikolla> kmARC: am not going to roll it out to users until I solve the CLI use case. so i'll keep playing around with it when i get more time.
14:13:03 <knikolla> kmARC: this is until app credentials get implemented, then there'll be a great story for that :)
14:13:09 <kmARC> You're my gest for a beer in Sydney if you solve it somehow :-D
14:13:33 <kmARC> app creds - if they are what I think they are - also works
14:13:54 <lbragstad> yeah - that sounds like a great fit for app credentials
14:13:57 <knikolla> kmARC: that's the correct motivation for an engineer.
14:14:25 <lbragstad> we've got action items to update the specification and start the implementation this release
14:16:59 <kmARC> :-S that's a bit too late for me :-)
14:17:00 <kmARC> anyhow
14:17:22 <kmARC> now I'm gitblameing the v3oidcpassword folks and hunt them down for more info :-)
14:20:17 <kmARC> So I haven't dug deep into horizon's code. But is my assumption correct that the horizon flow does _not_ use v3oidc{password,credentials} but it's all dispatched to apache2 mod_oidc?
14:37:12 <kmARC> stevemar: maybe?
14:56:33 <knikolla> kmARC: that is correct. it uses the apache mod
14:56:51 <kmARC> Ah okay, obviously the difference between the horizon flow and the cli flow is that the cli sends the username/password itself to IDP, while with horizon it's the user who enters it.
14:56:58 <knikolla> yep
15:05:56 <kmARC> This is what happens:
15:05:56 <kmARC> - REQ: curl -g -i -X POST https://keycloak/auth/realms/<REALM>/protocol/openid-connect/token
15:05:56 <kmARC> - an access_token is generated. this is how one talks to keycloak APIs (I've done it many times), with a Authorization: Bearer <token> header.
15:05:56 <kmARC> - this means that the authentication works.
15:05:56 <kmARC> - REQ: curl -g -i -X POST http://openstack-keystone/v3/OS-FEDERATION/identity_providers/<IDP>/protocols/openid/auth
15:05:56 <kmARC> - this is then gives back the apache mod_oidc response, which includes the IDP authentication endpoint. In my case this is gonna be:
15:05:56 <kmARC> Location: https://keycloak/auth/realms/<REALM>/protocol/openid-connect/auth?response_type=code&
15:05:57 <kmARC> scope=openid%20email%20profile&client_id=<CLIENT_ID>&state=gWTSWn1C9mPJFaOiQRvy2WYiiXI&redirect_uri=http%3A%2F%2Fopenstack-keystone%2Fv3%2FOS-FEDERATION%2Fidentity_providers%2F<IDP>%2Fprotocols%2Fopenid%2Fauth%2Fredirect&nonce=kH3H6X2n66Y83ca72hP_ZO5N5w_lK1onitb8SOQIPJk
15:05:57 <kmARC> - then openstackclient issues a POST request to this location. keycloak gives back an error:
15:05:58 <kmARC> RESP: [405] ... WildFly/10 Allow: HEAD, GET, OPTIONS X-Powered-By: Undertow/1 ...
15:06:30 <kmARC> so this last step is supposed to be a form post.
15:06:45 <kmARC> which is -  I guess - up to the idp how they implement it, isn't it?
15:07:47 <kmARC> Or is there any specification how it is supposed to be implemented in an ID provider? That would be strange, I mean what if an identity provider doesn't even let username/password auth but let's say face recogniton or such
15:19:45 <kmARC> According to the RFC,
15:19:45 <kmARC> "The authorization endpoint is used to interact with the resource
15:19:45 <kmARC> owner and obtain an authorization grant.  The authorization server
15:19:45 <kmARC> MUST first verify the identity of the resource owner.  The way in
15:19:45 <kmARC> which the authorization server authenticates the resource owner
15:19:45 <kmARC> (e.g., username and password login, session cookies) is beyond the
15:19:45 <kmARC> scope of this specification."
15:19:46 <kmARC> ...
15:19:46 <kmARC> "  The authorization server MUST support the use of the HTTP "GET"
15:19:47 <kmARC> method [RFC2616] for the authorization endpoint and MAY support the
15:19:47 <kmARC> use of the "POST" method as well."
15:19:48 <kmARC> Source: https://tools.ietf.org/html/rfc6749
15:20:28 <kmARC> So it seems the implementation is bugous in the sense that it expects the auth endpoint to accept POST, however, according to the RFC, it's not required :-\
15:33:42 <knikolla> jdennis is the keycloak expert
15:42:05 <kmARC> jdennis: helpme :-)
15:43:55 <jdennis> kmARC: sorry I can't be of immediate assistance, I know keycloak well with SAML but hardly at all with openidc
15:45:51 <kmARC> :-(
15:47:13 <jdennis> kmARC: I suggest you try the keycloak user list: https://lists.jboss.org/mailman/listinfo/keycloak-user
15:47:32 <kmalloc> kmARC, jdennis: this might be something osc/keystoneauth is assuming
15:47:46 <kmalloc> keycloak might be doing the right (ish) thing here
15:49:08 <kmalloc> we may only support (currently) the use of IDPs that support post.
15:49:37 <kmalloc> and that is fine, it's not a bogus implementation, it's a narrow implementation that doesn't cover the whole spec.
15:50:20 <kmalloc> OIDC via CLI tools has always been very difficult
15:50:31 <kmalloc> since OIDC (like most SSO tech) assumes a web browser
15:51:28 <jdennis> kmalloc: so this is a command line issue and not browser?
15:52:53 <kmalloc> jdennis: if i'm reading it right, yes
15:53:12 <kmalloc> jdennis: looks like OSC is trying to POST to keycloak and keycloak says "hah, no, get or head"
15:54:35 <kmalloc> jdennis: i don't think this is a keycloak issue.
15:54:58 <kmalloc> (well keycloak *could* support posts, but in this case doesn't seem to)
15:55:09 <kmalloc> it might be a config issue on keystone's side/mod_oidc
15:55:36 <jdennis> kmalloc: I'd have to look at the code, the spec and review some recent posts on how KC handles tokens for command line access, but I can't jump into this atm
15:57:32 <kmalloc> jdennis: yeah i figured, just wanted to let you know it doesn't look like it's fundamentally a keycloak issue. it looks more on the Openstack side/config sided
15:58:07 <jdennis> ok
15:58:42 <kmARC> kmalloc pls read my findings above. The RFC says IDP MAY support POST, however keycloak does not. It MUST support GET tho, therefore the correct implementation should use GET.
15:59:00 <jdennis> kmalloc, kmARC: if someone wants to open a bug and assign it to me I'll try to look at it when I get the chance
15:59:34 <kmARC> jdennis, sounds good, thanks.
15:59:43 <kmARC> will do tomorrow, for today I'm braindead.
16:01:14 <kmalloc> kmARC: right like i said, it very well might be on the keystoneauth/osc side, we may have implemented a narrow form of supported oidc idps, we can expand, but it is likely that change is not going to be backportable directly and will become usable in queens (we can evaluate backports, but I can't commit to them at this point)
16:03:15 <kmARC> this looks like a client issue, therefore I'm expecting the proposed bugfix to work backward-compatible with the Mitaka server - after all, the browser flow works. So I'm looking forward to the fix. I know python unfortunately well enough to volunteer to help with coding :-)
16:04:47 <kmalloc> kmARC: the issue is the way things are implement in openstackclient and keystoneauth
16:04:57 <kmalloc> those are also locked to specific releases [sometimes]
16:05:07 <kmalloc> and distributions tend to bundle the releases
16:05:36 <kmalloc> it may require a much newer client and that could be incompatible if you're running on a system with other openstack-related-things (non-venv, etc)
16:05:44 <kmalloc> just wanted to give you an FYI
16:05:55 <kmARC> jdennis: I'm much more looking forward to a solution that works without the shady form post. like v3oidcauthcode or v3oidcaccesstoken. Let me know if you know how to configure keycloak to enable users to create `API tokens`, `API secrets` or something like that, with which they'd be able to issue a secret key that authenticates them into various service providers - if at all this is possible
16:06:43 <kmARC> kmalloc, regarding versions, it's not a problem I think, if I document the means of accessing openstack APIs for my users, and it involves virtualenv, then it is what it is, they're still gonna be happy.
16:06:53 <kmalloc> wfm :)
16:30:40 <SamYaple> efried: its fernet tokens, and there should be no tokenless auth goign on
16:30:53 <kmARC> jdennis: wait a sec. The `openstack` doesn't list any SAML related auth types... O.o
18:08:30 <lbragstad> gagehugo: o/
18:08:44 <lbragstad> did you have anything specific in mind for the last session here? https://etherpad.openstack.org/p/SYD-keystone-forum-sessions
18:09:41 <gagehugo> lbragstad other than what's on there not really
18:09:56 <gagehugo> was just an idea in case we were lacking them
18:10:26 <lbragstad> gagehugo: think we should propose a session specific to jwt?
18:11:07 <gagehugo> hmm
18:11:17 <gagehugo> dunno if that would fill an entire session?
18:11:24 <gagehugo> it might be a good idea
18:12:00 <lbragstad> probably not?
18:12:10 <lbragstad> that might be something we can do solely in a specification
18:12:21 <lbragstad> gagehugo: https://trello.com/c/25sBHXcM/14-write-up-a-specification-for-json-web-tokens
18:12:35 <gagehugo> yeah
18:12:57 <gagehugo> maybe jwt as part of operator feedback?
18:53:10 <aruna> Hi , created a new domain , user, project , role in devstack .But get this error while trying to do "openstack user list "
18:53:23 <aruna> User has no access to project  _populate_roles /opt/stack/keystone/keystone/token/providers/common.py:339
18:53:28 <aruna> any help ?
19:34:15 <lbragstad> aruna: that users needs a role on a project in order to do that
19:34:38 <lbragstad> do you have an admin user available? devstack will provide one for you
19:34:59 <lbragstad> (you see the credentials listed when devstack exits)
19:37:07 <aruna> @lbragstad : got it thanks
19:45:29 <lbragstad> this would be a good backport to get merged - https://review.openstack.org/#/c/504084/1
20:05:47 <gagehugo> lbragstad is https://review.openstack.org/#/c/491574/13/keystone/common/utils.py ok for a comment?
20:07:03 <lbragstad> gagehugo: oh - yes, that will work
20:07:10 <lbragstad> thanks!
20:07:22 <gagehugo> I'll fix the tags # after that merges
20:07:39 <lbragstad> gagehugo: is there a unified stance on implementing HEAD for tag APIs?
20:07:56 <lbragstad> we have the whole "all GET methods should also support HEAD"
20:08:04 <lbragstad> but - we don't have those documented in the spec or policy
20:08:07 <lbragstad> for project tags,
20:08:20 <lbragstad> i'm wondering if that will result in a bug asking for it to be added later?
20:08:42 <gagehugo> could be, the controller/router has get_or_head
20:09:31 <lbragstad> oh - nice
20:09:35 <lbragstad> so it's implemented already
20:11:30 <gagehugo> yeah I think this was brought up earlier
20:11:59 <gagehugo> I don't think the api-ref says explicitly that you can do HEAD
20:12:03 <gagehugo> but it's implemented
20:12:29 <lbragstad> gagehugo: does the API ref for project tags have something against doing HEAD?
20:12:33 <lbragstad> or implementing HEAD?
20:13:56 <gagehugo> http://docs-draft.openstack.org/96/472396/18/check/gate-keystone-api-ref/b38e869//api-ref/build/html/v3/index.html#project-tags
20:15:16 <lbragstad> ah - we should modify that patch so that it documents head, too
20:15:42 <gagehugo> sure
20:15:47 <lbragstad> 1.) because all keystone v3 GET methods should also support HEAD
20:15:54 <lbragstad> 2.) the work is already done ;)
21:07:21 <gagehugo> lbragstad thanks for the reviews!
21:08:35 <lbragstad> gagehugo: yep! stuff looks real good
21:08:42 <lbragstad> gagehugo: most of my comments are style things
21:08:55 <lbragstad> otherwise the code looks really clean, good work
21:09:13 <lbragstad> cc lamt ^
21:09:23 <lbragstad> and the rest of the AT&T team
21:11:52 <gagehugo> will do
21:11:59 <gagehugo> I like that removing the v2 stuff makes this easier
21:12:12 <gagehugo> spent more time than I liked getting the v2 tests to pass :(
21:15:44 <lbragstad> gagehugo: yeah... sorry about that =/
21:16:09 <lbragstad> i spent an entire flight getting v2 auth ripped out and refactoring tests, i feel your pain
21:16:15 <gagehugo> heh
22:05:07 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add JSON schema validation for project tags  https://review.openstack.org/484483
22:06:09 <gagehugo> I think there's some zuul funny business
22:06:29 <gagehugo> lbragstad I'm gonna put some depends on for these patches instead of rebasing them all on each other
22:29:47 <openstackgerrit> Gage Hugo proposed openstack/keystone-specs master: Update project-tags spec  https://review.openstack.org/508339
22:41:52 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add policy for project tags  https://review.openstack.org/486757
00:14:54 <stevelle001> Anyone able to help me refine this search: looking for design decisions leading to tokens always being returned in headers, instead of in body
00:24:59 <SamYaple> stevelle001: you want to find a conversation/spec that talks about whether the auth tokens should be passed via the hedears or in the body?
00:29:58 <stevelle001> SamYaple: that's what I'm hoping for, particularly in terms of the operations which create tokens
00:30:09 <stevelle001> also hello again
00:35:45 <SamYaple> im not sure tht exists, if i understand you correctly. The auth header is parsed by keystonemiddleware, and middleware doesnt dig into the body is my undertanding
00:35:53 <SamYaple> stevelle001: hi!
00:40:15 <stevelle001> I'm only interested in the keystone api itself, not how the header is used on other service APIs (handled by the middleware).  See https://github.com/openstack/keystone-specs/blob/master/attic/v3/identity-api-v3.rst "While token objects do have identifiers, they are not passed in resource URL's nor are they included in the objects themselves." I'm
00:40:15 <stevelle001> trying to get a clear idea of why the OS_TOKEN isn't in the resource.
00:40:46 <stevelle001> I know I'm not asking that very clearly
00:46:03 <SamYaple> Oh i see you question now. I don't have an answer for you though. someone else will come along though, im sure
00:52:21 <samueldmq> stevelle001: SamYaple: hi, that's somewhat a historical decision
00:52:39 <stevelle001> I figured as much
00:52:44 <samueldmq> but I think it had something to do with being safer to be transmitted at the header? I'm not sure
00:52:58 <SamYaple> easier to parse maybe
00:52:59 <samueldmq> but I think kmalloc may know it
00:54:18 <stevelle001> I assumed it was to prevent security issues -> logging the response body. wanted to find the discussion to consider fully
00:55:15 <kmalloc> Yep
00:55:38 <kmalloc> Mostly to help eliminate logging, especially of the request itself containing secure data.
00:56:00 <stevelle001> request payloads are not treated the same, only response
00:56:08 <stevelle001> was hoping to get a little insight into that too
00:56:45 <stevelle001> I couldn't find a cve for this when I looked
05:59:37 <openstackgerrit> Jamie Lennox proposed openstack/keystone master: Remove middleware reference to PARAMS_ENV and CONTEXT_ENV  https://review.openstack.org/508410
05:59:38 <openstackgerrit> Jamie Lennox proposed openstack/keystone master: Move auth header definitions into authorization  https://review.openstack.org/508411
05:59:38 <openstackgerrit> Jamie Lennox proposed openstack/keystone master: Remove the TokenAuth middleware  https://review.openstack.org/508412
13:14:21 <Dinesh_Bhor> Hi all, can anyone take a look at this and add his/her opinion? http://lists.openstack.org/pipermail/openstack-dev/2017-September/122725.html
13:21:39 <Dinesh_Bhor> lbragstad, dstanek: It will be great if you reply to this or add comment on the bug directly: http://lists.openstack.org/pipermail/openstack-dev/2017-September/122725.html
13:53:19 <knikolla> o/
14:21:03 <openstackgerrit> Colleen Murphy proposed openstack/keystonemiddleware master: Rename auth_uri to www_authenticate_uri  https://review.openstack.org/508522
14:21:56 <openstackgerrit> Colleen Murphy proposed openstack/keystonemiddleware master: Rename auth_uri to www_authenticate_uri  https://review.openstack.org/508522
14:28:07 <openstackgerrit> Colleen Murphy proposed openstack/keystonemiddleware master: Rename auth_uri to www_authenticate_uri  https://review.openstack.org/508522
14:37:51 <gagehugo> o/
14:40:48 <knikolla> gagehugo: o/
15:01:02 <knasim-wrs> hi experts, quick question on keystone admin and public apps... before Newton, when keystone was running under eventlets we had certain operations that were not allowed over publicURL. But now with gunicorn running 2 separate app instances, I don't see any distinction between admin and public apps
15:01:23 <knasim-wrs> what does the keystone-admin app provide that the keystone-public app doesn't?
15:01:59 <lbragstad> knasim-wrs: good question - the keystone-admin app and keystone-public app was a thing we had to do with the v2.0 API
15:02:18 <lbragstad> the v2.0 API isolated admin functionality to keystone-admin and public functionality to the keystone-public app
15:02:42 <lbragstad> when we implemented v3, we combined both applications and manage policy for what you can and can't do in the application itself
15:02:55 <lbragstad> that way you don't have to host two separate identity applications for full functionality
15:03:43 <knasim-wrs> so we are on Identity V3, does that mean I can have one or the other and it'd be equal? Right now I have 2 gunicorn apps (port 35357 and 5000)
15:03:48 <lbragstad> some of that history is actually documented https://docs.openstack.org/keystone/latest/contributor/http-api.html
15:04:29 <lbragstad> v3 doesn't care or change functionality if it is run on 5000 versus 35357
15:04:37 <lbragstad> the v3 api should be the same regardless
15:05:33 <knasim-wrs> thanks a lot Lance. This is very helpful for us
15:05:50 <lbragstad> knasim-wrs: anytime!
15:06:05 <knasim-wrs> now that we are migrating to Ocata, I can get rid of one of the app
15:06:19 <lbragstad> knasim-wrs: so long as you aren't deploying v2.0 in anyway
15:06:52 <lbragstad> knasim-wrs: but yeah, that would be awesome, because we removed almost all v2.0 bits in queens
15:07:44 <knasim-wrs> thanks Lance. I'll keep that in mind, last I remembered as of Newton, Neutron was still using Identity V2 so need to make sure its moved onto V3 in Ocata/Pike
15:09:28 <lbragstad> knasim-wrs: we had a big push to move everything to v3
15:30:28 <lbragstad> FYI - http://lists.openstack.org/pipermail/openstack-dev/2017-September/122886.html
15:33:26 <knasim-wrs> thanks Lance. One more question:
15:34:06 <knasim-wrs> to prevent people from deleting the admin user or the services users / services project, I've added hacks inside the Keystone code but I realize that it'd be better to do this as RBAC rules
15:35:57 <knasim-wrs> something like: identity:delete_project: not services:%(target.project.name)
15:36:07 <knasim-wrs> does RBAC allow NOT rules?
15:37:46 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Add policy for project tags  https://review.openstack.org/486757
15:39:18 <lbragstad> knasim-wrs: oslo.policy appears to support it - but i've never experiemented with NOT specifically https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html
15:39:50 <knasim-wrs> thanks a bunch Lance!
15:39:51 <lbragstad> gagehugo: i think you're changes are failing because of https://review.openstack.org/#/c/508511/
15:40:00 <lbragstad> knasim-wrs: yep - let me know how that works for you
15:40:31 <gagehugo> :(
15:41:02 <lbragstad> gagehugo: i added a depends on to https://review.openstack.org/#/c/486757/
15:41:12 <lbragstad> we'll see if that clears things up
15:41:24 <gagehugo> lbragstad thanks!
15:41:50 <gagehugo> I figured things will just move slow until the issues with zuul3 get fixed
15:42:00 <lbragstad> yeah...
15:42:13 <lbragstad> i'm going through keystone changes to see if there is anything else that might affect us
15:44:34 <gagehugo> rip those changes I made for skipping jobs
15:44:57 <gagehugo> I'm reading the new zuul stuff now
15:47:48 <lbragstad> we haven't had a lot of stuff enter the gate recently so we might not seem
15:47:51 <lbragstad> see much*
15:51:54 <gagehugo> oh they have the skipping in there now, cool
15:52:11 <gagehugo> https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n16834
15:52:37 <knikolla> irrelevant-files, i like the naming.
15:53:14 <gagehugo> knikolla ++
15:53:43 <knikolla> gagehugo: ksm doesn't have that section
15:54:04 <gagehugo> yeah I'll edit https://review.openstack.org/#/c/504243/ for zuul3
15:54:35 <knikolla> gagehugo: cool!
15:57:32 <openstackgerrit> Gage Hugo proposed openstack/python-keystoneclient master: DNM: This is a change that makes keystoneclient.session.Session explode  https://review.openstack.org/503207
16:18:40 <lbragstad> gagehugo: https://review.openstack.org/#/c/484483/ passes though
16:20:04 <gagehugo> \o/
16:21:14 <lbragstad> only one comment on that patch, just to make sure we don't miss updating the specification
16:21:54 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add project tags api-ref documentation and reno  https://review.openstack.org/472396
16:24:12 <gagehugo> lbragstad https://review.openstack.org/#/c/508339/
16:28:26 <lbragstad> gagehugo: nice - thanks!
16:34:12 <SamYaple> lbragstad: so my issue *was* timeouts. lots of em
16:34:38 <SamYaple> one of the nova tables had like a million entries (and no indexing) so the db was returning ultraslow like
16:35:09 <SamYaple> somehow that manifested in middleware getting NotFound exceptions
16:35:18 <lbragstad> SamYaple: whoa...
16:35:28 <lbragstad> it's totally opaque
16:35:47 <SamYaple> indeed. but its fixed now
16:36:02 <SamYaple> so now you can say "ive seen that before!" if it pops up again
16:53:33 <gagehugo> lbragstad https://review.openstack.org/#/c/507694/ is definitely WIP, I had to whiteboard out the inheritance for those tests :(
16:54:36 <lbragstad> gagehugo: ack - i assume the classes that inherit LDAPIdentity somehow inherit the unit.TestCase class
16:55:14 <gagehugo> there's one in the test_backend_ldap_pool that does
16:55:24 <gagehugo> and another that inherits just LDAPIdentity
16:57:13 <gagehugo> I need to look over it again, there is definitely no reason that each of those tests need to be ran ~8 times
17:56:26 <lbragstad> samueldmq: https://review.openstack.org/#/c/504459/1 looks good, couple suggestions on things we can add
18:19:13 <aahh> @lbragstad : any idea why would we encounter this error on devstack http://www.paste.org/86300
18:19:25 <aahh> havent modified any files in it
18:21:25 <lbragstad> aahh: that looks like a pbr bug
18:21:48 <lbragstad> or something is wrong with the dependencies installed
18:23:24 <aahh> was working all good until few minutes back , any suggestions on how to fix
18:27:02 <lbragstad> you could try reinstalling some of the dependencies, or the package that is giving you problems and retry?
18:27:04 <lbragstad> https://ask.openstack.org/en/question/88600/installation-of-openstack-fails-with-attributeerror-module-object-has-no-attribute-add_metaclass/
18:27:22 <lbragstad> sounds like there might be conflicting versions of the same package on the system
18:27:39 <lbragstad> weird stuff happens when system and local packages are both installed
18:29:00 * lbragstad steps away to grab lunch quick
18:35:22 <knasim-wrs> @lbragstad: the "not" operations worked in Keystone RBAC. Thanks!
18:54:33 <ayoung> lbragstad, is gagehugo not working on 968696 anymore?  Are you going to drive on with my Nova fix for it?
19:08:07 <lbragstad> ayoung: yeah - we need to reassess after the ptg discussions
19:08:08 <lbragstad> if gagehugo isn't able to pick it back up i can try and carve out cycles for it
19:08:18 <lbragstad> (not sure if those messages came through)
19:08:37 <gagehugo> ayoung I wasn't sure if we were continuing with is_admin_project
19:09:34 <ayoung> I thought the idea was to eventually go for the Service Roles, but since those are undefined now, and we can transition from is_admin_project to service roles (I think) this gives a path forward.  Was not going to push, though
19:09:52 <lbragstad> gagehugo: i think you dropped yourself from that bug prior to all the discussions in Denver, right?
19:11:56 <gagehugo> lbragstad I stopped working on it once global roles because a thing
19:12:12 <gagehugo> and I wasn't sure what direction we were going in
19:12:18 <lbragstad> gagehugo: ack
19:12:22 <lbragstad> that makes sense
19:12:42 <lbragstad> at the PTG jamielennox made a bunch of point about providing a path from one to the other since is_admin_project is technically in the wild
19:13:13 <lbragstad> part of that roadmap consisted of building a thing in oslo.policy/context that projects should consume
19:13:30 <lbragstad> that knows how to handle system roles and is_admin_project equally
19:13:46 <lbragstad> thus, shielding the projects from having to care about the implementation detals
19:13:48 <lbragstad> details*
19:14:19 <ayoung> Service scoped roles could have is_admin_project set to true
19:14:39 <ayoung> tokens with Service scoped roles could have is_admin_project set to true
19:15:26 <lbragstad> a system scoped token and a token with is_admin_project are the same thing
19:15:32 <lbragstad> essentially
19:17:04 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 identity APIs  https://review.openstack.org/499783
19:18:38 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 token APIs  https://review.openstack.org/499784
19:18:51 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 auth APIs  https://review.openstack.org/504465
19:18:55 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add project tags api-ref documentation and reno  https://review.openstack.org/472396
19:24:34 <ayoung> lbragstad, so, we can continue to work on getting the projects to enforce on is_admin_project, which will be a 1-to-1 match with Service scoped rules in the future, and and can add the logic in oslo context once we have service scoped roles implemented.
19:24:52 <ayoung> but, I'm not going to be writing any more code for a bit...new role and all that
19:26:03 <lbragstad> ayoung: yeah - thats fine, i figured you'd be busy with other things
19:26:10 <ayoung> so gagehugo if you want to take https://review.openstack.org/#/c/384148/  and work on it in conjunction with the Nova team, please go ahead and do so, as I think it is the single most important thing that needs to happen in Keystone right now
19:26:55 <ayoung> Even if the rules change, that patch is probably the basis for any other implementation you are going to end up with, so please take it and run with it
19:28:01 <ayoung> same with https://review.openstack.org/#/c/257636/  .  lbragstad perhaps the best thing to do is to take that patch and make it look like you want
19:28:22 <gagehugo> ayoung sure
19:29:58 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add project tags api-ref documentation and reno  https://review.openstack.org/472396
19:30:09 <ayoung> lbragstad, gagehugo the one sticking point on the keystone review was that I put the service_role into is_admin_project.  This is for services out there, and I think would translate almost directly to a service scoped roles.  Do you two agree?
19:30:38 <lbragstad> ayoung: we haven't gotten to service roles yet, or service scoping
19:30:48 <ayoung> lbragstad, that does not matter
19:31:01 <lbragstad> i could see that coming later if system scoping pans out the way we need it to
19:31:06 <ayoung> the question is whether the current usage of the service role should be considered is_admin_project only
19:31:06 <gagehugo> that will be nice if it does translate directly
19:31:14 <ayoung> and I think it needs to be
19:31:28 <ayoung> it is, IIUC, only ever assigned to a service user for validating tokens
19:34:02 <ayoung> lbragstad, look at it this way:  would it ever make sense to grant the service_role to someone for an operation scoped to a project?  Seems to contradict the meaning of service there
19:34:44 <ayoung> and...I don't think we actually currently use that for anything.
19:34:59 <ayoung> $ grep -rni service_role keystone/* | fpaste
19:34:59 <ayoung> Uploading (0.6KiB)...
19:34:59 <ayoung> https://paste.fedoraproject.org/paste/UJqHAtz8LeRFVBUyT~WGSQ
19:35:08 <ayoung> only in unit tests.  I can remove that line if you want.
19:35:34 <ayoung> and, since we don't use it, I am OK with removing it
19:36:47 <lbragstad> ayoung: i need to dig into the patch, i haven't look at it recently
19:36:59 <ayoung> ah...we do use it, just via the constants
19:37:00 <lbragstad> there's a lot of discussion there and it looks like jamielennox had comments
19:37:20 <ayoung> $ grep -rni RULE_SERVICE_OR_ADMIN keystone/* | fpaste
19:37:20 <ayoung> Uploading (0.6KiB)...
19:37:20 <ayoung> https://paste.fedoraproject.org/paste/Jrmn84weUIuKojBJH4cSWQ
19:37:26 <ayoung> lbragstad, that was his one comment
19:38:01 <ayoung> service is a role that is assigned to, say the nova service user that calls back to Keystone in order to validate tokens and check revoke status
19:38:49 <ayoung> seems to me to be a hole if we were to let a project level admin or lower perform that operation.  So scoping it to a project does not make sense.
19:39:14 <ayoung> If we had a global role for token operations, it would be used here instead
20:37:22 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Use stestr directly instead of ostestr  https://review.openstack.org/508611
20:37:31 <lbragstad> mtreinish: ^
20:54:07 <kmalloc> lbragstad: are we clear for removing 2.0 stuff now?
20:54:16 <kmalloc> lbragstad: looks like the depends on stuff has been droppeD?
20:54:33 <lbragstad> kmalloc: one of the patches merged and the other didn't need to be a dependency
20:55:09 <lbragstad> a rebase of https://review.openstack.org/#/c/499783/7 should do the trick
20:55:31 <lbragstad> we'll see what the tests say but i'm not expecting any real issues
20:55:43 <kmalloc> great. I'll shove it through if it's all happy
20:56:12 <lbragstad> awesome - there is a bunch of stuff queued up behind it
20:56:16 <kmalloc> yep
20:56:40 <lbragstad> also - https://review.openstack.org/#/c/508611/ would be good to review
21:24:43 <openstackgerrit> Jamie Lennox proposed openstack/keystone master: Check policy_complete on keystone request  https://review.openstack.org/508619
21:27:44 <openstackgerrit> Jamie Lennox proposed openstack/keystone master: Move auth header definitions into authorization  https://review.openstack.org/508411
21:27:44 <openstackgerrit> Jamie Lennox proposed openstack/keystone master: Remove the TokenAuth middleware  https://review.openstack.org/508412
21:29:34 <jamielennox> ayoung: a present on that: https://review.openstack.org/#/c/507726/
21:48:33 <openstackgerrit> Jamie Lennox proposed openstack/keystone master: Remove the TokenAuth middleware  https://review.openstack.org/508412
22:18:15 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 identity APIs  https://review.openstack.org/499783
22:18:15 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 token APIs  https://review.openstack.org/499784
22:18:16 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 auth APIs  https://review.openstack.org/504465
22:18:16 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 test plumbing  https://review.openstack.org/506748
23:06:19 <openstackgerrit> Jamie Lennox proposed openstack/keystonemiddleware master: Issue a deprecation warning for validating PKI tokens  https://review.openstack.org/508631
23:10:03 <openstackgerrit> Jamie Lennox proposed openstack/keystonemiddleware master: gitignore .stestr folder  https://review.openstack.org/508632
00:27:48 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Remove the v2_deprecated decorator  https://review.openstack.org/499785
00:28:08 <openstackgerrit> Morgan Fainberg proposed openstack/keystone master: Remove deprecated secure_proxy_ssl_header config  https://review.openstack.org/499798
01:12:25 <openstackgerrit> chenaidong1 proposed openstack/keystone master: _list_tokens_for_consumer should use sql read sessions  https://review.openstack.org/499535
02:20:12 <openstackgerrit> Merged openstack/keystone master: Properly normalize protocol in Fedrations update_protocol  https://review.openstack.org/502311
04:53:13 <openstackgerrit> Li Yingjun proposed openstack/keystonemiddleware master: Fix context issue for neutron audit  https://review.openstack.org/508659
15:15:37 <lbragstad> whew! we're green to remove the rest of v2.0!
15:15:47 <lbragstad> starting with https://review.openstack.org/#/c/499783/
15:19:07 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove deprecated secure_proxy_ssl_header config  https://review.openstack.org/499798
15:26:07 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 token APIs  https://review.openstack.org/499784
15:31:47 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 auth APIs  https://review.openstack.org/504465
15:32:01 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove v2.0 test plumbing  https://review.openstack.org/506748
16:00:15 <samueldmq> lbragstad: approved. all looking great
16:00:33 <lbragstad> samueldmq: i'm refactoring a patch you had comments on 9 months ago
16:00:59 <samueldmq> lbragstad: they had +2 (and even +A) some time ago, so I decided to go ahead and kick 'em though the gates
16:01:04 <samueldmq> lbragstad: aha! :-)
16:01:20 <samueldmq> lbragstad: what patch is that, I am just curious ..
16:01:45 <lbragstad> https://review.openstack.org/#/c/389371/4
16:02:57 <samueldmq> lbragstad: "This is not Pike yet." is still true, just s/yet/anymore
16:02:59 <samueldmq> :-)
16:03:09 <lbragstad> right lol
16:03:13 <samueldmq> hhehe
16:19:57 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove the v2.0 validate path from validate_token  https://review.openstack.org/389371
16:20:04 <lbragstad> samueldmq: ^
16:20:20 <lbragstad> resolved the merge conflict and it passes tests locally
16:22:36 <samueldmq> lbragstad: +2ed, looks awesome...
16:23:04 <samueldmq> we've been cleaning up a bunch of code and docs, which seems maintainability has greatly improved
16:23:42 <lbragstad> yeah - it feels good
16:36:51 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove deprecated secure_proxy_ssl_header config  https://review.openstack.org/499798
21:56:25 <openstackgerrit> ayoung proposed openstack/keystone master: Shift to check_policy for resource creation  https://review.openstack.org/462670
05:49:22 <Suramya> Hey anybody around who can give me some advice on the commit message conventions on my 2nd patch
01:45:47 <openstackgerrit> Davanum Srinivas (dims) proposed openstack/oslo.policy master: http/https check rules as stevedore extensions  https://review.openstack.org/507098
13:19:42 <openstackgerrit> Colleen Murphy proposed openstack/keystonemiddleware master: Rename auth_uri to www_authenticate_uri  https://review.openstack.org/508522
14:03:38 <efried> cmurphy To answer your question: https://review.openstack.org/#/c/490057/21/nova/utils.py
14:04:30 <efried> cmurphy Couple months ago I tried solving the problem with this, which you can see is in the same spirit (adding those methods to a baser class): https://review.openstack.org/#/c/491203/
14:04:36 <efried> That ^ didn't work at all :(
14:25:56 <cmurphy> efried: okay I guess that makes sense
15:23:28 <lkwan_> quit
15:23:30 <lkwan_> exit
17:41:38 <openstackgerrit> Colleen Murphy proposed openstack/keystonemiddleware master: Rename auth_uri to www_authenticate_uri  https://review.openstack.org/508522
18:02:03 <kmalloc> o/
18:09:46 <lbragstad> o/
18:33:05 <openstackgerrit> Colleen Murphy proposed openstack/keystonemiddleware master: Rename auth_uri to www_authenticate_uri  https://review.openstack.org/508522
19:35:48 <knasim-wrs> hi, just reading up on Pike Rel Notes... says admin_token is eventually going away
19:35:55 <knasim-wrs> what are the alternatives to bootstrap then?
19:43:59 <gagehugo> knasim-wrs https://docs.openstack.org/keystone/latest/admin/identity-bootstrap.html
19:44:14 <gagehugo> using "keystone-manage bootstrap"
19:55:41 <knasim-wrs> thanks gage
19:57:03 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Add database migration for project tags  https://review.openstack.org/484456
20:16:39 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Implement backend logic for project tags  https://review.openstack.org/499726
20:33:16 <itlinux> hello guys.. if I have keystone on my OOO and default is uuid.. want to change to fernet.. and later I want to add a new node.. will that break the  process? Thanks! I asked OOO they said to ask here!
20:40:55 <lbragstad> itlinux: you'll have an extra step to do when you add a new node to the deployment
20:41:27 <lbragstad> itlinux: you'll need to make sure you sync the key repository (/etc/keystone/fernet-keys/) from the existing keystone nodes in the deployment to the new node
20:41:48 <lbragstad> that will ensure the new node is able to validate tokens issued by the other nodes
20:42:00 <itlinux> ok
20:42:14 <itlinux> thanks @lbragstad:
20:42:16 <lbragstad> itlinux: we walked through an example in this presentation https://www.youtube.com/watch?v=702SRZHdNW8&t=2s
20:42:26 <lbragstad> that might help you visualize things a bit better
20:42:27 <itlinux> k
20:43:15 <itlinux> is it way faster than UUID?
20:43:32 <lbragstad> itlinux: if you have caching configured, yes
20:43:41 <itlinux> yes..
20:43:43 <lbragstad> the performance will be better if not the same
20:43:45 <lbragstad> than UUID
20:43:51 <itlinux> I have 3 controllers with memcached
20:44:07 <lbragstad> but - you'll get the added benefit of not having to wait for backend replication in order to validate tokens across the cluster
20:44:20 <itlinux> k
20:44:38 <itlinux> so it works similar to the PKI..
20:44:39 <lbragstad> with UUID, you'd be constrainted by SQL in that case, because keystone-1 creates the token and has to replicate it
20:44:44 <lbragstad> kinda, yeah
20:44:53 <itlinux> k
20:44:56 <lbragstad> except fernet tokens can't be validated offline
20:45:08 <itlinux> ok
20:45:36 <lbragstad> with a fernet token, you can create it on one node and immediately validate it against another, so long as both keystone nodes share the same key repository (they can decrypt each others tokens)
20:46:26 <lbragstad> (e.g. i get a token from my Chicago datacenter and I can immediately use it in Sydney because I don't have to wait for data replication - since fernet isn't persisted to the SQL database)
20:46:33 <itlinux> yes I remember while back when AD was the PTL.. a
21:46:43 <openstackgerrit> Jamie Lennox proposed openstack/keystonemiddleware master: Issue a deprecation warning for validating PKI tokens  https://review.openstack.org/508631
22:48:31 <openstackgerrit> jessegler proposed openstack/python-keystoneclient master: Add project tags to keystoneclient  https://review.openstack.org/481223
22:52:46 <openstackgerrit> jessegler proposed openstack/python-keystoneclient master: Add project tags to keystoneclient  https://review.openstack.org/481223
00:59:57 <itlinux> @lbragstad: are you still around?
02:05:05 <namnh> lbragstad: Hi Lance,
02:05:35 <namnh> lbragstad: are you here?
02:05:45 <lbragstad> namnh: o/
02:07:49 <namnh> lbragstad: I see you are updating policy goal for many projects. all patch sets like this [1], it means you already have a plan to do it? [1] https://review.openstack.org/#/c/501029/1
02:08:44 <lbragstad> namnh: the goal behind those patches was to exclude projects that didn't require the goal from the document
02:09:27 <lbragstad> if a project didn't expose APIs that were protected by the policy.json file pattern in openstack, then i updated the goal to say that project wasn't affected
02:14:23 <namnh> lbragstad: I got it, however do you have a plan to update policy code for all projects that are using policy.json?
02:14:24 <namnh> https://review.openstack.org/#/q/status:open++branch:master+topic:policy-and-docs-in-code+owner:%22Lance+Bragstad+%253Clbragstad%2540gmail.com%253E%22
02:14:52 <lbragstad> namnh: i'm trying to help out some of the projects that haven't started yet
02:15:01 <lbragstad> tracking some of that work here - https://www.lbragstad.com/policy-burndown/
02:16:27 <lbragstad> my plan is to at least get the initial patch or two done at least, then hoping that helps some of the developers who are more familiar with the project
02:16:44 <lbragstad> then they can see the rest of the work though
02:24:06 <namnh> lbragstad: your website is great, could I do this task with you?
02:24:58 <lbragstad> namnh: sure - how would you like to help?
02:26:59 <lbragstad> namnh: we have a ton of things in review, as you already pointed out, but there are several projects that have asked for help getting started...
02:27:57 <namnh> lbragstad: sure, I will review and implement, what projects?
02:28:20 <lbragstad> i just wrapped up a patch for openstack/panko
02:28:32 <lbragstad> but other than that, the burndown chart should be pretty accurate
02:28:45 <lbragstad> as to which projects have yet to get started
02:29:23 <lbragstad> is there any one in particular you want to pick up?
02:29:35 <lbragstad> there is a glance patch up for review that needs to be dusted off
02:32:11 <namnh> i'm thinking about tacker, but firstly, I need to understand deeply
02:32:54 <lbragstad> namnh: we have a template patch against sandbox that acts as a boilerplate
02:33:08 <lbragstad> https://review.openstack.org/#/c/502506
02:35:14 <namnh> lbragstad: great, thanks for sharing. is there any project that you are wrapping up?
02:35:52 <lbragstad> i proposed patches for zun, zaqar, and panko today
02:36:14 <lbragstad> i poked a bit at the networking libraries, but i think i'm really going to have to coffee up for those
02:39:39 <namnh> lbragstad: I understood, I will pick up some other projects, thanks for your time.
02:40:12 <lbragstad> namnh: no problem - thanks for the willingness to help out
02:41:41 <lbragstad> namnh: i'm located in central US time UTC -5
02:52:13 <namnh> I've come US for PTG-Denver =)). so you are a hard-working person. I am UTC+7.
02:52:17 <namnh> lbragstad:
02:57:45 <openstackgerrit> Tin Lam proposed openstack/keystonemiddleware master: Updates for stestr  https://review.openstack.org/504433
06:09:25 <openstackgerrit> Bhagyashri Shewale proposed openstack/keystoneauth master: Added new logger to log request_id  https://review.openstack.org/509088
10:18:38 <Dinesh_Bhor> cmurphy: Hi, It will be great if you take a look at it again: https://review.openstack.org/#/c/329913/ whenever you get time.
13:07:59 <randomhack> hey guys, having an issue getting the openstack client to use --os-auth-type v3samlpassword - openstack: error: argument --os-auth-type: invalid choice: u'v3samlpassword' (choose from 'v2token', 'none', 'password', 'admin_token', 'v3oidcauthcode', 'v2password', 'v3password', 'v3oidcaccesstoken', 'token_endpoint', 'token', 'v3oidcclientcredentials', 'v3tokenlessauth', 'v3token', 'v3totp',
13:08:05 <randomhack> 'v3oidcpassword', 'noauth')
13:42:46 <randomhack> how would I enable v3samlpassword, it does show up on my MacBook in the list but not in any other system I'm testing.  The python package versions are the same for openstackclient, keystoneclient, keystoneauth1.
13:43:18 <randomhack> Is there another package requirement for it to be enabled?
14:33:17 <prashkre> lbragstad: Hi. Could you help me on my query, Does keystone ldap drivers support Microsoft Active Directory 2003 as identity backend?
14:38:25 <lbragstad> prashkre: i assume it does but i've never tried it
14:38:46 <lbragstad> i've heard of people using active directory as an identity backend before
17:26:23 <prashkre> lbragstad: thank you! I am searching for which minium version of Active Directory that keystone ldap supports.
17:50:53 <kmalloc> lbragstad: going to miss the meeting. Can we do the policy thing not this meeting?
17:51:15 <kmalloc> I have to pick up my car, might be back by 30-45 after the hour.
17:51:40 <kmalloc> Policy (re what Adam emailed about)
17:52:06 <lbragstad> kmalloc: yeah - that will be next week mayube
17:52:11 <kmalloc> Ok
17:52:15 <lbragstad> kmalloc: we'll also save that for a dedicated policy meeting i think
17:52:21 <kmalloc> Wfm
17:52:29 <lbragstad> unless there is a reason to hold it in the keystone meeting?
17:52:40 <kmalloc> Maybe for keystone eyes
17:53:02 <kmalloc> Policy meeting is not a full keystone compliment. And this might be worth more eyes.
17:53:22 <kmalloc> We can talk about that later though
17:53:33 <kmalloc> That is future lbragstad's problem ;)
17:53:37 <ayoung> prashkre, RE Active Director, yes, but there are caveats
17:54:01 * ayoung wonders what kmalloc and lbragstad were talking about....has not shown in evesdrop yet
17:54:12 <kmalloc> ayoung: ++ yeah it has some oddities. As long as it supports proper LDAP
17:54:18 <kmalloc> Interface it should work
17:54:27 <kmalloc> ayoung: policy thing you emailed about.
17:54:37 <ayoung> kmalloc, there were a few presentations about the differences.   I remember a GoDaddy once called AD != LDAP
17:54:53 <ayoung> kmalloc, ah, the comparison with AIM?
17:54:56 <kmalloc> Yeah
17:55:24 <ayoung> kmalloc, is it just me, or do we have the harder problem to solve, as Amazon can hide all of the internal administrative traffic in a way that we cannot?
17:56:13 <ayoung> Like, the service level operations we have in the main interfaces would never show up to someone coming via their web front ends over the public internet
18:22:33 <openstackgerrit> Ken'ichi Ohmichi proposed openstack/keystone master: Fix prompts of mysql on installation doc  https://review.openstack.org/509247
18:27:22 <kmalloc> ayoung: it isn't just you
18:27:32 <kmalloc> It is an accurate assessment of the differences.
18:28:59 <ayoung> Fezzik: Well, I'm carrying three people. And he's got only himself.
18:28:59 <ayoung> Vizzini: I do not accept excuses! I'm just going to have to find myself a new giant, that's all.
18:28:59 <ayoung> Fezzik: Don't say that, Vizzini. Please?
19:00:10 <openstack> lbragstad: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
19:06:11 <lbragstad> #endmeeting