19:00:51 <lbragstad> #startmeeting keystone-office-hours
19:00:52 <openstack> Meeting started Tue Jan  2 19:00:51 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:55 <openstack> The meeting name has been set to 'keystone_office_hours'
19:00:59 <lbragstad> alrighty
19:11:01 <lbragstad> a bunch of the api-ref patches are looking good if anyone is interested in reviewing https://review.openstack.org/#/q/topic:api-ref-reorganization+(status:open+OR+status:merged)
19:14:49 <lbragstad> cmurphy: do you have follow up thoughts on https://review.openstack.org/#/c/529914/9 ?
19:22:44 <cmurphy> lbragstad: I still don't understand why it needs a new method and why the ldap driver needed to be modified but i'd have to play with it to be able to give solid feedback
19:23:44 <lbragstad> yeah - same here...
19:26:05 <cmurphy> unfortunately not in a position to do that atm
19:29:56 <gagehugo> o/
19:30:03 <gagehugo> I'll take a look at those api pages
19:43:53 <ayoung> kmalloc, what a wonderful naming convention.
19:44:18 <ayoung> "common" for what is explicitly supposed to be for a specific API.
19:44:28 <kmalloc> ayoung: ?
19:44:36 <ayoung> Convert use of self.<provider_api> to keystone.common.provider_api.ProviderAPIs.<provider_api> for manager calls
19:44:51 <ayoung> everything is now "common"
19:45:12 <kmalloc> because the storage location is common code.
19:45:22 <kmalloc> move it from common to keystone.provider_apis then
19:45:27 <kmalloc> i'd +2 it.
19:45:27 <ayoung> Oh, I get it....just that there is no need for the uncommon anymore...
19:45:53 <kmalloc> not sure if you're unhappy with it or not.
19:45:55 <kmalloc> fwiw.
19:46:26 <ayoung> Just laughing
19:46:32 <kmalloc> ok.
19:46:34 <kmalloc> *shrug*
19:46:54 <ayoung> I was the one that origianlly organizaed the codebase with a subdir for each section
19:47:33 <ayoung> I do like the idea that the interfaces are defined one place and the implementation separate, so no real complaints
19:48:00 <kmalloc> ah
19:48:19 <kmalloc> sorry context switching pretty hard atm, couldn't read tone of your typing ;)
19:48:45 <kmalloc> yeah, i am very happy that the "dependency" injection part is gone and centrally referenced.
19:48:58 <kmalloc> it'll be easier to understand (long term), less "magic"
19:49:26 <ayoung> But I think there was an assumption back when we wrote this that the APIs would be publically accessable, due to things like keystone-manage type behavior, and I am pretty sure that I don't want that anymore, either.  Kindof of the mind that everything should have to come through the web these days
19:51:01 <kmalloc> thats fair, i think keystone-manage is the only real exception - otherwise everything is "private" in code. we do kindof need the implementations centralized somehow.
19:51:33 <kmalloc> simply centralizing the instantiation (and locking that) is sufficent imo. i don't think we're really encouraging people to make more keystone-manage like applications.
19:51:53 <ayoung> Or third party drivers...
19:52:04 <kmalloc> those are rare.
19:52:29 <kmalloc> i would be happy to nuke 3rd party driver support (and the whole entry-point loaders) but that is a bigger conversation
19:52:47 <ayoung> I need to complete my "Running Keystone in OpenShift" implementation to figure out what I want to do about configuration
19:56:10 <ayoung> kmalloc, actually the reason I was checking in was that I was thinking about how long it takes to get patches merged.  I think it is hurting the project.
19:56:34 <ayoung> kmalloc, I was wondering if there was a subset of patches that we could reduce to requiring a single +2 on.
19:57:14 <lbragstad> kmalloc: i your patch for that
19:57:27 <lbragstad> kmalloc: i proposed a bunch of other patches replicating it for each subsystem
19:58:11 <kmalloc> ya, i saw\
19:58:18 <ayoung> lbragstad, what if we said "for a patch that only affects a single line of production code, a single +2 is sufficient for +A?"
19:58:30 <ayoung> just to start at the absolute minimum.
19:58:37 <ayoung> Or...a patch that only adds tests
19:58:50 <ayoung> or some other set of low-overhead changes...
19:58:51 <kmalloc> ayoung: honestly, i usually use best judgement on what to single-core-approve, official policy or not
19:59:12 <kmalloc> there are a number i simply push through (like simple string fixes, e.g. comments) etc.
19:59:36 <kmalloc> i always figure i can apologize if it messes up and we can revert if needed.
19:59:39 <kmalloc> just FYI.
20:00:41 <ayoung> kmalloc, I was just trying to think of ways we could safely reduce the backlog
20:00:57 <kmalloc> ayoung: delete it.
20:01:03 <kmalloc> completely.
20:01:11 <kmalloc> :P
20:01:28 <ayoung> Um...that is pretty much exactly the opposite of what I want to do, though.
20:01:43 <ayoung> I want to just blindly approve it all and let it merge
20:02:12 <kmalloc> i honestly don't think the backlog is providing much of any benefit.
20:02:18 <kmalloc> and not because it's moving slow
20:04:46 <ayoung> kmalloc, I stopped adding new patches due to the length of time it took to get things through
20:05:00 <ayoung> That is not healthy for a project
20:10:37 <lbragstad> i think we just have an overall deficit in reviewers
20:32:53 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Reorganize api-ref: v3 authenticate-v3  https://review.openstack.org/530365
20:42:05 <ayoung> lbragstad, why do you think that is?
20:42:18 <ayoung> I'd argue because there is not enough payoff for reviewing
20:44:39 <lbragstad> i'm not sure - that's a good question
20:46:23 <ayoung> lbragstad, I know one thing I wish I had was a queue of reviews that I was responsibile for clearing
20:46:46 <lbragstad> clearing?
20:46:47 <ayoung> kinda like how dolph used to use nextreview
20:46:59 <ayoung> like: I commit to reviwing them
20:47:04 <lbragstad> oh
20:47:11 <ayoung> not every last one that is in the pipeline
20:47:29 <ayoung> but like, a queue, and I can come in, grab the highest priority, review it, and move on
20:47:52 <lbragstad> nextreview had some logic built into it that handled stuff like that
20:48:32 <lbragstad> iirc it tried to prioritize reviews based on the time it was in review
20:49:33 <ayoung> lbragstad, published stats would help
20:49:46 <ayoung> total reviewed, number of +2As etc
20:50:00 <lbragstad> i have review dashboards set up that help with that
20:50:08 <ayoung> but I think making it so a core could approve a wider array of patches is the primary thing
20:50:31 <ayoung> if I could approve something in, say LDAP, that I feel comfortable signing off on, I'd love to move those kind of things along
20:50:46 <ayoung> as opposed to +2 and it sits until it needs a rebase
20:53:51 <openstackgerrit> Gage Hugo proposed openstack/keystone master: Reorganize api-ref: v3 project-tags  https://review.openstack.org/530533
20:57:46 <gagehugo> lbragstad the api-ref changes should be good now, fixed the two that had minor issues, the rest look good
21:02:37 <lbragstad> kmalloc: do you want to follow up on https://bugs.launchpad.net/keystone/+bug/1729933 ?
21:02:38 <openstack> Launchpad bug 1729933 in OpenStack Identity (keystone) "region update doesn't update extras" [Undecided,In progress] - Assigned to David Lyle (david-lyle)
21:02:43 <lbragstad> gagehugo: awesome, thanks
21:13:44 <lbragstad> gagehugo: i should get around to reviewing https://review.openstack.org/#/c/481284/ this week too
21:17:15 <gagehugo> lbragstad I think that needs some fine tuning still, but it should be close
21:21:37 <openstackgerrit> Merged openstack/oslo.policy master: Add a release note for enforce_scope  https://review.openstack.org/530756
22:00:26 <logan-> hello. I'm trying to use oslopolicy-policy-generator to dump the base RBAC so it can be combined with my policy overrides and provided to horizon. with nova i'm able to dump RBAC using "/path/to/nova/venv/bin/oslopolicy-policy-generator --namespace nova", but the doing the same with keystone using "keystone" or "identity" as the namespace does not work.
22:01:39 <lbragstad> logan-: do you have keystone installed?
22:01:57 <lbragstad> let me see if i can recreate
22:03:30 <logan-> o/ lbragstad. yep keystone's installed. here's the venv and output for the oslopolicy command at the bottom: http://paste.openstack.org/raw/636624/
22:03:53 <lbragstad> huh - weird
22:03:56 <lbragstad> i can recreate
22:04:48 <ayoung> lbragstad, logan- I bet it is a dependency issue
22:05:25 <ayoung> trying to load Keystone fails cuz some other library is missing, and I bet  that is pulled in from oslopolicy polgen
22:07:05 <ayoung> oslo.policy.policies =
22:07:05 <ayoung> # With the move of default policy in code list_rules returns a list of
22:07:05 <ayoung> # the default defined polices.
22:07:05 <ayoung> keystone = keystone.common.policies:list_rules
22:07:12 <ayoung> that is from setup.cfg
22:07:21 <ayoung> is that what iti is trying to load?
22:07:36 <lbragstad> well - it's should be an entrypoint in oslo.policy
22:07:47 <lbragstad> keystone is just responsible for exposing the namespace
22:07:58 <lbragstad> https://github.com/openstack/keystone/blob/master/config-generator/keystone-policy-generator.conf
22:08:26 <lbragstad> which is the same as what nova defines
22:08:27 <lbragstad> https://github.com/openstack/nova/blob/master/etc/nova/nova-policy-generator.conf
22:09:31 <ayoung> seems like it is not registered
22:12:16 <ayoung> yep, reproduced it here, too
22:15:32 <lbragstad> i think we're missing this entrypoint
22:15:33 <lbragstad> https://docs.openstack.org/oslo.policy/latest/user/usage.html#merged-file-generation
22:15:45 <lbragstad> which just needs something to return the _ENFORCER
22:15:55 <lbragstad> so keystone.common.policy:get_enforcer
22:15:58 <lbragstad> or something like that
22:16:12 <lbragstad> #endmeeting