16:00:22 <cmurphy> #startmeeting keystone
16:00:23 <openstack> Meeting started Tue Jun 18 16:00:22 2019 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:27 <openstack> The meeting name has been set to 'keystone'
16:00:29 <lbragstad> o/
16:00:33 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:00:42 <cmurphy> o/
16:00:57 <vishakha> o/
16:01:19 <knikolla> o/
16:02:57 <cmurphy> #topic unified limits update
16:03:04 <cmurphy> lbragstad: it's all you
16:03:18 <lbragstad> ok - so you might have picked up on some spam about oslo.limit recently
16:03:41 <lbragstad> i decided to get that rolling after the retrospective last week
16:04:00 <lbragstad> this is really just an update on all that stuff and a summary of the discussion we had last week
16:04:00 <bnemec> \o/
16:04:16 <lbragstad> first off... the existing documentation we have is really stale
16:04:28 <lbragstad> it's missing the strict-two-level enforcement model
16:04:40 <lbragstad> and the descriptions of the enforcement models in general is pretty vague
16:05:02 <gagehugo> o/
16:05:09 <lbragstad> fortunately, we have a bunch of good documentation in the specs
16:05:24 <lbragstad> (the general unified limit spec, the flat enforcement spec, the strict two level spec)
16:05:35 <lbragstad> i want to port the useful bits over to formal docs
16:05:40 <kmalloc> o/
16:05:53 <lbragstad> feels weird to pass people links to specs as formal documentation
16:06:00 <lbragstad> #link https://docs.openstack.org/keystone/latest/admin/unified-limits.html
16:06:10 <lbragstad> #link https://review.opendev.org/#/c/664933/ is the update
16:06:36 <lbragstad> ok - moving on to oslo.limit
16:06:47 <lbragstad> i had a discussion with john garbutt
16:06:56 <lbragstad> which was carry over from the PTG
16:07:12 <lbragstad> and the idea is to make oslo.limit's enforcement strategy really simple
16:07:20 <lbragstad> we're trying to do that in a couple of ways
16:07:33 <lbragstad> 1.) oslo.limit isn't going to do verification for race conditions, initially
16:08:04 <lbragstad> 2.) we'll drop the idea of abstracting everything into a context manager, initially (we can add this later and right now it complicates some of the usage without a need for verification)
16:08:18 <lbragstad> this should hopefully make it even easier for people to pick up the oslo.limit work and start consuming it
16:08:59 <lbragstad> but - this kinda lines up with what we talked about at the PTG, specifically just getting something out the door that people can use
16:09:13 <lbragstad> that said - i started ripping apart oslo.limit last week
16:09:19 <lbragstad> #link https://review.opendev.org/#/c/665708/ (starting here)
16:09:36 <lbragstad> ^ that chain gets us back to the basics
16:09:55 <lbragstad> next i'm going to start incorporating the interface john worked on in his fork #link https://github.com/JohnGarbutt/oslo.limit/commits/interface-v2
16:10:00 <lbragstad> #link https://github.com/JohnGarbutt/oslo.limit/commits/interface-v2
16:10:20 <lbragstad> i'll also be re-proposing some of the stuff wxy-xiyuan did with ksa and openstacksdk
16:10:37 <lbragstad> i'd like to have all that ready for review by the EOW
16:11:12 <lbragstad> if anyone's interested in helping out with that, just let me know
16:11:32 <lbragstad> or if you just want to be a part of the interface planning bits, we can use tmate and hop on a call to work through stuff
16:11:51 <lbragstad> for context
16:12:15 <lbragstad> here is the discussion i had with john where we walked through the basic requirements we need to hit before nova can start using this
16:12:15 <lbragstad> #link http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-06-13.log.html#t2019-06-13T16:31:15
16:12:45 <lbragstad> and i also had an interesting discussion with another openstack developer about toggling oslo.limit to not query keystone for unified limit information and instead go into a local mode
16:12:45 <lbragstad> #link http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2019-06-14.log.html#t2019-06-14T00:41:01
16:13:22 <lbragstad> i'm not sure how all that would work, yet... but i wanted to advertise it to the group in case anyone found that interesting
16:13:45 <lbragstad> that's about all i have, does anyone have comments, questions, or concerns about the unified limit/oslo.limit work?
16:13:46 <cmurphy> the point of having it in keystone is that's where the projects are, if you don't have keystone then you don't have projects
16:14:05 <bnemec> That gets us back to the problem of the service owning the database definition, but oslo.limit needing to interact with it directly.
16:14:17 <lbragstad> cmurphy bnemec
16:14:18 <lbragstad> right
16:14:34 <lbragstad> is it safe to say we're not going to support that?
16:14:53 <lbragstad> and that oslo.limit will be tailored to "unified limits"
16:15:08 <cmurphy> i just think there can't be a concept of a project-based quota if there's no keystone involved
16:15:34 <lbragstad> that's fair
16:15:46 <lbragstad> i'm not sure if there was another aspect of non-project based enforcement i missed in that discussion
16:16:10 <bnemec> lbragstad: I'm inclined to say yes. We couldn't find a sane way to do this without unified limits in the past, so I don't think we should try to support that case.
16:16:11 <lbragstad> but it feels like doing that would go against openstack's concept of tenancy
16:16:29 * lbragstad nods
16:16:56 <bnemec> I suppose it's possible we could support non-keystone backends at some point, but that's waaaaay down my priority list at the moment.
16:17:06 <lbragstad> sure
16:17:45 * lbragstad appreciates the sanity check
16:18:02 <lbragstad> any other comments, questions, or concerns?
16:18:05 * bnemec hopes this isn't an insane echo chamber ;-)
16:20:04 <bnemec> I've got nothing else. Thanks for pushing on this.
16:20:22 <cmurphy> thanks for the update lbragstad
16:20:32 <lbragstad> yep!
16:20:37 <cmurphy> #topic
16:20:41 <cmurphy> er
16:20:53 <cmurphy> #topic Remove [signing] config
16:21:03 <cmurphy> #link https://review.opendev.org/#/c/659434
16:21:04 * bnemec notes that there is a #undo
16:21:14 <cmurphy> too late now
16:21:17 <vishakha> Since all the options of [signing] are deprecated, and those options are used in os_simple_cert API.
16:21:17 <vishakha> So I was wondering how to remove the options but not removing the API.
16:23:10 <vishakha> I wasnt able to find the solution for that
16:23:46 <lbragstad> vishakha i just left a comment
16:24:15 <lbragstad> but you might be able to remove the implementations
16:24:17 <lbragstad> #link https://review.opendev.org/#/c/659434/9/keystone/api/os_simple_cert.py
16:24:26 <lbragstad> and just return empty response objects
16:24:34 <lbragstad> (don't use the CONF object at all)
16:25:35 <lbragstad> the API would still exist but it would always return the same thing and we could remove the configuration
16:25:56 <lbragstad> (i think we took a similar approach with the revocation list API?)
16:26:10 <cmurphy> yep i think so
16:26:14 <cmurphy> vishakha: does that make sense?
16:26:21 <vishakha> lbragstad: Wont it create a problem when user will use this API https://developer.openstack.org/api-ref/identity/v3/#list-revoked-tokens
16:26:40 <lbragstad> users will still be able to call the API, but it will always return the same thing
16:26:53 * lbragstad digs up an example
16:28:50 <lbragstad> was it https://opendev.org/openstack/keystone/src/branch/master/keystone/api/auth.py#L262-L268 ?
16:28:54 <lbragstad> #link https://opendev.org/openstack/keystone/src/branch/master/keystone/api/auth.py#L262-L268
16:29:11 <lbragstad> there we're actually raising a 403, you can ignore that part i think
16:29:36 <cmurphy> maybe kmalloc remembers ^
16:30:38 <vishakha> lbragstad: ohh yes. Ok thanks
16:31:06 <cmurphy> okay great
16:31:12 <vishakha> Skipping that part is a good option
16:31:38 <kmalloc> hmmm.
16:32:02 <lbragstad> like this
16:32:04 <lbragstad> #link https://pasted.tech/pastes/5e06b00e9e7a050b973700f32c24a8668277b1d1.raw
16:32:34 <lbragstad> just make it an empty request
16:32:39 <vishakha> lbragstad: thanks I will update it
16:32:48 <kmalloc> yeah a 403 was chosen there because it required signing certs
16:33:12 <kmalloc> you can totally just make it respond with an empty json doc (the api in question) instead, as if no certs were defined.
16:33:39 <vishakha> kmalloc: ok thanks
16:34:09 <cmurphy> cool
16:34:16 <cmurphy> #topic open reviews
16:34:26 <cmurphy> anyone have reviews they would like to call out?
16:34:35 <lbragstad> #link https://review.opendev.org/#/c/665231/ closes a couple of bugs
16:34:53 <cmurphy> nice
16:35:07 <cmurphy> i have some spec cleanups that have been open for a while
16:35:16 <cmurphy> #link https://review.opendev.org/658893
16:35:19 <lbragstad> i saw one of those passing zuul now
16:35:23 <lbragstad> i can take a look today
16:35:27 <cmurphy> #link https://review.opendev.org/658894
16:35:33 <vishakha> https://review.opendev.org/#/c/665313/ just a url update
16:35:38 <cmurphy> #link https://review.opendev.org/659159
16:36:06 <cmurphy> #link https://review.opendev.org/662106 mission statement update
16:36:16 <lbragstad> vishakha what's the story behind updating https://review.opendev.org/#/c/665313/1 ?
16:39:45 <bnemec> That's the recommended url for u-c now.
16:39:57 <lbragstad> oh - sweet
16:40:09 <bnemec> Let me see if I can find the thread about it.
16:40:28 <lbragstad> so it was on the mailing list
16:41:46 <bnemec> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006647.html
16:42:48 <bnemec> Or maybe http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006478.html
16:42:56 <bnemec> Which is linked from the first one.
16:43:44 <lbragstad> thanks
16:44:06 <vishakha> lbragstad: That was a long mail chain on which I read about it. I will summarize and will share it to you after meeting
16:44:41 <lbragstad> it makes sense - i was just thinking it would be useful to link to that in the commit message
16:44:47 <cmurphy> ++
16:45:05 <vishakha> lbragstad cmurphy  Sure I will add it to commit message
16:45:12 <cmurphy> great
16:45:15 <cmurphy> #topic open discussion
16:45:22 <cmurphy> no office hours after this
16:45:28 <cmurphy> any other business to cover?
16:48:17 <cmurphy> alright we'll close the meeting and get a few minutes back
16:48:20 <cmurphy> thanks everyone
16:48:24 <cmurphy> #endmeeting