17:01:05 <lbragstad> #startmeeting keystone-office-hours
17:01:06 <openstack> Meeting started Tue Mar 20 17:01:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:10 <openstack> The meeting name has been set to 'keystone_office_hours'
17:01:37 <lbragstad> #link https://bluejeans.com/8559013623
17:03:37 <gagehugo> going out for lunch, will be back in an hour or so
17:11:23 <openstackgerrit> Johannes Grassler proposed openstack/keystone-specs master: Add whitelist-extension-for-app-creds  https://review.openstack.org/396331
17:14:36 <cmurphy> o/
17:20:02 <lbragstad> reviewing https://review.openstack.org/#/c/396331/ since jgr won't be around all of office hours
17:30:34 <lbragstad> in case you missed it - https://bluejeans.com/8559013623/
17:30:55 <cmurphy> oh we're bluejeansing?
17:31:20 <lbragstad> yep - we actually have questions for you cmurphy
17:31:31 <cmurphy> bah okay
17:31:34 <cmurphy> one sec
17:36:34 <lbragstad> kmalloc: i'm not sure if it's just me, but it sounds like your mic is clipping
17:37:47 <adriant> kmalloc: added some comments, and will fix up most of that in a patch after lbragstad, or cmurphy get a chance to also comment.
17:41:24 <cmurphy> adriant: want to join the bluejeans session ^
17:42:59 <lbragstad> moving on to https://review.openstack.org/#/c/553670/
17:43:05 <adriant> cmurphy: might jump on in a sec :)
18:04:48 <hrybacki> lbragstad: ping, default roles chat?
18:09:09 <cmurphy> kmalloc: your puppy left :'(
18:22:22 <gagehugo> o/ back
18:52:42 <hrybacki> gagehugo: we just dropped bridge fyi
18:53:06 <gagehugo> hrybacki ok I was listening in
18:53:25 <hrybacki> ack -- didn't want you to feel as if we abandoned you gagehugo
18:53:29 <gagehugo> heh
18:53:36 <gagehugo> nah I caught the tail end of system scope
18:53:50 <hrybacki> ++
18:54:03 <hrybacki> relocating now o/
18:56:01 <gagehugo> lbragstad https://review.openstack.org/#/c/554327/ fixes the same bug as https://review.openstack.org/#/c/553108/ but it refactors the sql backend logic for tags, which I'm not sure about
18:57:31 <gagehugo> it uses nova's approach which looks like using inner joins, but we had some concerns about if that would be worse performance
19:09:17 <lbragstad> gagehugo: revieing
19:09:19 <lbragstad> reviewing*
19:09:40 <gagehugo> I need to be revived on this tue
19:09:45 <gagehugo> :)
19:26:52 <lbragstad> gagehugo: is https://review.openstack.org/#/c/553108/3 the perferred way to close the bug?
19:27:30 <lbragstad> i'm spinning up an environment to test it quick
19:28:09 <gagehugo> lbragstad I think it's a much simpler fix than Nic's
19:28:23 <gagehugo> I'm sure the logic could be refactored to be better
19:29:05 <gagehugo> and it may require refactoring if we add starts/ends with & contains
19:31:08 <kmalloc> lbragstad: extensive comments on app-cred whitelist
19:31:15 <kmalloc> it should cover all the things we talked about
19:31:20 <lbragstad> perfect
19:31:35 <kmalloc> it's a pretty big re-work, but it should simplify and clarify what we allow
19:48:06 <hrybacki> lbragstad: I think we need to find a good way of de-coupling default roles from scope types
19:49:50 <hrybacki> at least in documentation. e.g. Here are default roles X, Y, and Z. This is generically what their purpose should be. Have you heard of scope types A and B? Here is generically what their purposes <link to spec/doc/whatever>. Here is how we envision default roles being applied in the following scoped operations.
19:50:15 <hrybacki> thoughts? I think it gets v confusing when we introduce both the default roles and how they are used with scope at the same time
19:51:42 <lbragstad> right
19:51:52 <lbragstad> it's almost like a support matrix
19:52:19 <gagehugo> yeah roles & scope like to confuse people
19:52:29 <gagehugo> more clarification would be great
19:53:12 <lbragstad> would an abstracted support matrix with "scopes" being one axis and "default roles" being the other help?
19:53:44 <hrybacki> lbragstad: I'm not sure I follow precisely
19:53:49 <hrybacki> so maybe XD
19:54:28 <lbragstad> trying to find an example
19:55:39 <hrybacki> ack
20:04:17 <gagehugo> lbragstad you tested tags with ksc right?
20:06:16 <lbragstad> gagehugo: yeah
20:06:22 <lbragstad> hrybacki: gagehugo - https://imgur.com/a/XGMnW
20:06:43 <lbragstad> i apologize for the chicken scratch
20:07:16 <gagehugo> oh man engineering paper
20:07:18 <hrybacki> hah, no you are fine
20:07:37 <hrybacki> lbragstad: do we have any documentation specific to system, domain, and project scope atm?
20:08:53 <hrybacki> I'm thinking 1) intro the default roles and their generic purpose 2) brief review of scope levels (system, domain, project) and link to more info for the curious 3) present something akin to your diagram demoing how they 'should' overlap
20:09:19 <gagehugo> lbragstad http://paste.openstack.org/show/706590/
20:09:22 <gagehugo> it works for curl
20:09:27 <gagehugo> wonder if ksc is borked as well
20:09:41 <hrybacki> and maybe in reverse order of how we have e.g. reader, write, and admin roles -> project, domain, and system scopes
20:10:33 <lbragstad> hrybacki: that was kind of my thinking behind https://bugs.launchpad.net/keystone/+bug/1757151
20:10:34 <openstack> Launchpad bug 1757151 in OpenStack Identity (keystone) "Token and scope documentation needs an update" [Medium,In progress] - Assigned to Lance Bragstad (lbragstad)
20:10:36 <gagehugo> I can add a testcase though
20:10:44 <lbragstad> huh - interesting
20:10:49 <lbragstad> i can retest with curl
20:11:36 <hrybacki> lbragstad: okay. I'll work on this draft in an abstract way and then we can fill in the specifics together this week?
20:12:10 <lbragstad> yeah - i'll start working on the scope docs
20:12:22 <hrybacki> ++
20:12:39 <lbragstad> also - i was wondering if it would be useful to break the scope doc up depending on the audience
20:12:59 <lbragstad> having a document that explains scope types for users and operators
20:13:16 <lbragstad> and a separate document that explains scope types for developers writing other services
20:14:37 <hrybacki> lbragstad: would it be too much to have them separate but in the same doc? Not sure how different they would be
20:17:25 <lbragstad> hrybacki: we'll - we have a section for user guides and then we have this - https://docs.openstack.org/keystone/latest/contributor/services.html
20:17:28 <lbragstad> which is in a separate document
20:18:08 <lbragstad> but then we have https://docs.openstack.org/keystone/latest/admin/identity-tokens.html#authorization-scopes which is in the admin-guide
20:20:02 <hrybacki> I feel like I need to read all of our docs. I haven't the slighest clue as to how they are structured rn
20:20:47 <lbragstad> the last major restructuring we did was in PIke
20:20:55 <lbragstad> we moved all the openstack manuals content into keystone
20:21:11 <lbragstad> and per the specification, we broke it into several guides
20:21:25 <lbragstad> (admin guide, install guide, configuration guide, user guide, API references, etc...)
20:22:06 <hrybacki> ack, that does ring a bell
20:24:40 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove references to UUID from token documentation  https://review.openstack.org/554581
20:25:22 <lbragstad> but yeah, we have things that are applicable to multiple guides,
20:25:31 <lbragstad> scope and roles feel like one of them
20:39:12 <gagehugo> ++ multiple guides
20:40:15 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove references to UUID from token documentation  https://review.openstack.org/554581
20:40:15 <openstackgerrit> Lance Bragstad proposed openstack/keystone master: Remove references to v2.0 from external developer doc  https://review.openstack.org/554690
20:49:50 <hrybacki> alright lbragstad -- I made a bunch of changes and shared the doc with you. Adding comments on the side to allow for easy communication without muddling up the already murky doc
20:50:04 <lbragstad> checking
20:50:16 <hrybacki> I have to drop for the night at 5PM (meetings outside of work-work) but will pick this up based on your comments lbragstad
20:57:19 <gagehugo> I think the stable/queens neutron-grenade job is bork
20:57:38 <gagehugo> https://review.openstack.org/#/c/548788/
20:58:18 <cmurphy> anyone have thoughts on https://review.openstack.org/#/c/549723 ? the problem i think is that we're not mapping to the extra column but i don't know if we want to encourage that
21:01:24 <gagehugo> yeah it should come from extras
21:01:54 <gagehugo> I would assume?
21:02:54 * gagehugo takes a look
21:03:42 <cmurphy> yeah it should be an extra but i guess for federated users we're not passing arbitrary attributes in to the shadow user
21:04:19 <cmurphy> which sort of seems fine to me but it makes our example here wrong https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#mappings-examples
21:04:51 <gagehugo> ah
21:05:08 <gagehugo> yeah it should use arbitrary attributes then I guess
21:07:40 <openstackgerrit> Merged openstack/keystone master: Fix api-ref for project tag create  https://review.openstack.org/553422
21:20:29 <lbragstad> hrybacki: responded inline
21:23:24 <adriant> lbragstad, cmurphy: What's the response code when attempting auth with an expired token? Or trying to use an expired token?
21:23:40 <lbragstad> 401 i believe
21:23:55 <lbragstad> or 404... i need to double check..
21:23:55 <cmurphy> yeah i think still 401
21:24:06 <adriant> I'm just trying to decide and add to the spec what we return when a receipt expires
21:24:22 <adriant> because knowing the failure was expiry would be useful
21:24:36 <adriant> but if we can add that to the 401 error message that works
21:25:02 <lbragstad> yeah - 401, just tested it
21:25:39 <adriant> I'm imagining horizon flow: username+password > totp screen > wait 6 mins > hit enter > error redirect to login again
21:25:53 <adriant> in that case should the user be made away the failure was expiry
21:26:06 <adriant> and if so, then we need to convey that in the response :/
21:26:56 <hrybacki> mmm should Horizon handle a timeout like that?
21:27:14 <hrybacki> think of when your bank kicks you off a login screen without you making any prompt at all
21:27:27 <hrybacki> (maybe that's just my bank)
21:27:35 <adriant> oh, so have the js do it?
21:27:37 <adriant> Actually...
21:27:44 <hrybacki> aye
21:27:46 <adriant> yes, we'd return the expiry time in the receipt
21:28:07 <adriant> horizon would know when it expires and could pass to the js that time
21:28:27 <adriant> then redirect back to login before even hitting the failure
21:28:45 <kmalloc> yeah, i'd have horizon handle that case if possible
21:28:45 <adriant> yeah, that works
21:36:19 <adriant> kmalloc: as a middle ground, you ok with 10mins for expiry and having it configurable should a cloud want it short/longer?
21:36:40 <kmalloc> i'd rather it not be configurable, not my followup comment, don't worry about timing.
21:37:18 <kmalloc> pick a timeout, go with it.
21:37:28 <adriant> alright, I'll put 10 then since it's a little safer than 15, and not quite as short as 5
21:37:43 <kmalloc> honestly i don't think it'll matter
21:37:55 <kmalloc> remember this is only every supposed to be used from initial password -> followup
21:38:05 <kmalloc> what usecase are you solving with 10 or 15m timeout
21:38:14 <kmalloc> my opinion is start very low and increase
21:38:17 <kmalloc> vs the inverse
21:38:23 * adriant nods
21:38:28 <adriant> done, 5m it is
21:38:34 <kmalloc> but answer what you're solving with the longer timeout before selecting above 5 :)
21:38:46 <kmalloc> and then i'm on the same page as you for the reasoning.
21:39:20 <adriant> kmalloc: I don't have a good reason, more just that I expect people to be silly and take too long for stuff that shouldn't and then complain :P
21:39:30 * adriant is quite cynical when it comes to users
21:39:43 <kmalloc> i'd rather they complain and we increase it in code ;)
21:40:00 <kmalloc> because then we can ask "why does it take you 10m to get your auth process done?" ;)
21:43:04 <hrybacki> ack, thanks lbragstad
21:43:23 <lbragstad> no problem
22:04:06 <lbragstad> #endmeeting