17:00:43 <cmurphy> #startmeeting keystone-office-hours
17:00:44 <openstack> Meeting started Tue May 28 17:00:43 2019 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:49 <openstack> The meeting name has been set to 'keystone_office_hours'
17:00:53 <cmurphy> hi again o/
17:01:04 <vishakha> Hello o/
17:02:12 <lbragstad> o/
17:02:13 <cmurphy> #topic bug triage
17:02:33 <cmurphy> #link https://etherpad.openstack.org/p/keystone-office-hours-topics office hours topics
17:03:08 <gagehugo> o/
17:03:23 <cmurphy> first up on my triage list is "RFE: Token returns Project's tag properties"
17:03:29 <cmurphy> #link https://bugs.launchpad.net/keystone/+bug/1807697
17:03:31 <openstack> Launchpad bug 1807697 in OpenStack Identity (keystone) "RFE: Token returns Project's tag properties" [Wishlist,In progress] - Assigned to Yang Youseok (ileixe)
17:03:59 <cmurphy> ileixe seems to be satisfied with closing it but i wanted to get other eyes on the suggested solution
17:05:10 * lbragstad reads
17:10:23 <lbragstad> makes sense
17:11:42 <lbragstad> so - to clarify
17:12:12 <lbragstad> we're going to keep the fix in the clients and have them query keystone for additional tags once they understand the token
17:12:20 <lbragstad> er the project the token is scoped to
17:13:21 <lbragstad> as opposed to exposing tags as a first-class attribute of tokens
17:13:55 <cmurphy> right, except i think this isn't about a change to the clients but in how a service like neutron would use the keystone client to retrieve a project
17:14:06 <lbragstad> aha
17:14:07 <cmurphy> and also this is expected to happen during policy enforcement aiui
17:14:50 <lbragstad> so - services are going to have to build their own credential and target information with tags in them?
17:15:17 <lbragstad> in order for this to be useful in oslo.policy enforcement
17:15:20 <lbragstad> right?
17:15:22 <cmurphy> i think so
17:15:46 <lbragstad> this kinda feels like dynamic policy and the issues we hit with that
17:15:49 <lbragstad> but...
17:16:44 <cmurphy> remind me what that means?
17:17:04 <cmurphy> like an external policy engine?
17:17:37 <lbragstad> we're enabling someone to be able to do fine-grained authorization via the api, but ultimately an operator has to tweak .yaml files to get policies to work depending on how people are modifying things in the API
17:18:43 <lbragstad> e.g., if i tag a project 'gold' and another project 'platinum' and that affects authroization, then i probably have to supply my own overrides
17:19:54 <lbragstad> unless they're using the http_check oslo.policy path
17:20:03 <cmurphy> hmm
17:21:09 <cmurphy> so what should we advise? this sounds unfun to implement
17:21:13 <bnemec> Maybe relevant to this discussion: https://review.opendev.org/#/c/658675/
17:21:17 * bnemec saw http_check
17:21:44 <lbragstad> sorry - i'm off in the weeds, we're probably advising the right thing
17:21:57 <cmurphy> lol
17:22:18 <lbragstad> i was just making the point that an underlying issue makes this whole thing a little strange because it can't be API driven completely
17:22:52 <cmurphy> okay i'll close for now and invite them to talk to us again if they get stuck and we need a better solution
17:22:57 * lbragstad sits back down
17:22:59 <lbragstad> sounds good
17:24:55 <cmurphy> next is "[<= Queens] With token-provider='uuid', roles of dynamically obtained federated groups are not taken into account during token-based authentication (for project-scoped token creation)"
17:25:01 <cmurphy> #link https://bugs.launchpad.net/keystone/+bug/1828126
17:25:02 <openstack> Launchpad bug 1828126 in keystone (Ubuntu) "[<= Queens] With token-provider='uuid', roles of dynamically obtained federated groups are not taken into account during token-based authentication (for project-scoped token creation)" [Undecided,New]
17:26:31 <cmurphy> another problem with federated groups, but only affects UUID tokens
17:27:09 <lbragstad> so - federated users don't get tokens with the groups from the mapping with the uuid provider?
17:27:18 <kmalloc_away> totally unrelated... i just ate some fresh pineapple i brought back from hawaii. holy crap it's good.
17:27:37 <kmalloc_away> since uuid is dead in master, "won't fix, sorry"
17:27:40 <kmalloc_away> lbragstad: ^
17:28:01 <kmalloc_away> they're going to need to get off uuid tokens anyway or implement their own provider
17:28:07 <cmurphy> queens is still maintained so i told them we'd still accept a fix
17:28:34 <kmalloc_away> honestly, i think that might be borderline when considering a stable patch.
17:28:48 <kmalloc_away> my answer would be "really use fernet"
17:28:59 <cmurphy> that might be true, it may be too big to fix in stable
17:29:47 <lbragstad> i wonder if they have any issues just migrating to fernet?
17:30:08 <kmalloc_away> i'd like to know if they have issues with fernet and if future releases solve them.
17:30:21 <cmurphy> they might just be reporting it for the sake of completeness
17:30:24 <kmalloc_away> my guess is key rotation sync issues (not wanting to develop tooling for it)
17:30:32 <kmalloc_away> if anything
17:30:50 <kmalloc_away> a lot of folks don't like dealing with fernet key rotation
17:32:57 <cmurphy> asked on the bug report
17:33:08 <lbragstad> ++
17:34:22 <cmurphy> next I have is "PY3 unicode text values change in ldap not taking care of py2 special charater unicode strings"
17:34:30 <cmurphy> #link https://bugs.launchpad.net/keystone/+bug/1825867
17:34:31 <openstack> Launchpad bug 1825867 in OpenStack Identity (keystone) "PY3 unicode text values change in ldap not taking care of py2 special charater unicode strings" [Undecided,New] - Assigned to Abhishek Sharma M (abhi.sharma)
17:34:50 <cmurphy> there is a proposed fix but it doesn't work, i'm not totally sure this is really a bug
17:37:09 <lbragstad> i guess i'd wait for the author to fix the patch
17:37:25 <lbragstad> or bump it to see if they're still planning on fixing it
17:37:31 <cmurphy> that's fair
17:38:21 <kmalloc_away> ++
17:38:35 <cmurphy> bumped the patch
17:39:18 <kmalloc_away> cmurphy: we have a "Removed as of Train" bug right?
17:39:28 <cmurphy> kmalloc_away: yes we do now
17:39:44 <kmalloc_away> ok going to close the bp out then
17:39:44 <cmurphy> https://bugs.launchpad.net/keystone/+bug/1829453
17:39:45 <openstack> Launchpad bug 1829453 in OpenStack Identity (keystone) "Removed as of Train" [Low,In progress] - Assigned to Vishakha Agarwal (vishakha.agarwal)
17:40:17 <cmurphy> the last one i wanted to talk about was "no create time for project", since we actually discussed reviving an old spec related to that
17:40:25 <cmurphy> #link https://bugs.launchpad.net/keystone/+bug/1822135
17:40:26 <openstack> Launchpad bug 1822135 in OpenStack Identity (keystone) "no create time for project" [Undecided,Incomplete] - Assigned to XiaojueGuan (xiaojuegaun)
17:40:44 <cmurphy> in the bug report we advised to use cadf notifications for this purpose
17:41:06 <cmurphy> at the ptg we also decided to revive http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/model-timestamps.html
17:41:18 <cmurphy> (this was saturday morning)
17:43:09 <lbragstad> hmmm
17:43:43 <lbragstad> so - are model times stamps going to be done for everything then?
17:44:23 <cmurphy> looks like Project, Domain, Role
17:44:43 * lbragstad would be curious to hear if there is objection to the current advice?
17:45:01 <cmurphy> me too
17:45:31 <cmurphy> also wondering if we still want to do http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/model-timestamps.html given that we do have cadf notifications
17:45:56 <lbragstad> i feel like we'd need more support for it
17:46:15 <lbragstad> or more operators coming to us telling us that notifications aren't cutting it
17:46:22 <lbragstad> but that's just my knee-jerk reaction
17:46:44 <lbragstad> if feels like one of those features that would be a slippery slope to do for all things in keystone
17:47:09 <cmurphy> agreed
17:47:24 <cmurphy> i'll bump the bug and mention the spec and see if they can tell us whether cadf is sufficient
17:47:36 <lbragstad> ++
17:50:10 <cmurphy> that was all i had on my list
17:50:17 <cmurphy> any other bugs people want to look at?
17:50:52 <lbragstad> looks good to me
17:51:04 <cmurphy> not bug related but there's an interesting discussion happening in https://review.opendev.org/651790
17:51:37 <cmurphy> wrt the admin endpoint in ksm
17:52:16 <cmurphy> and what the default interface should be and whether to use warnings to alert people about it
17:56:15 <cmurphy> weigh in on the patch if you have thoughts, i'm especially on the fence about whether to issue a warning or just do a cutover + release note
17:56:43 <cmurphy> thanks for participating everyone :)
17:57:05 <cmurphy> feel free to add topics to the etherpad for next office hours if you want to
17:57:08 <cmurphy> #endmeeting