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