16:00:33 <lbragstad> #startmeeting keystone
16:00:38 <openstack> Meeting started Tue Apr  3 16:00:33 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:42 <openstack> The meeting name has been set to 'keystone'
16:00:43 <cmurphy> o/
16:00:44 <hrybacki> o/
16:01:04 <gagehugo> o/
16:01:25 <lbragstad> o/
16:01:33 <lbragstad> ping ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy
16:01:40 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:01:43 <lbragstad> agenda ^
16:03:05 <lbragstad> we'll give it another minute
16:03:43 <kmalloc> i was getting coffee.
16:03:44 <kmalloc> i;m here now
16:03:59 <lbragstad> cool
16:04:10 <lbragstad> #topic specifications
16:04:25 <lbragstad> reminder that specification proposal freeze is on the 20th
16:05:05 <lbragstad> we should have everything we talked about during dublin proposed though
16:05:22 <lbragstad> we do need some more eyes on several of them
16:05:34 <lbragstad> #topic specifications: hierarchical limits
16:05:36 <lbragstad> #link https://review.openstack.org/#/c/540803/
16:05:40 <lbragstad> #link https://review.openstack.org/#/c/549766/
16:06:31 <lbragstad> the one wxy is authoring includes a lot of things we should do regardless of the model
16:06:38 <lbragstad> s/model/enforcement model/
16:07:00 <lbragstad> i'm curious if people have an opinion about how we should track that work
16:07:08 <lbragstad> if it needs to be a separate specification?
16:07:34 <lbragstad> or if it should be grouped with a specification the details *an* enforcement model (kind of like what johnthetubaguy has proposed)
16:09:17 <wxy|> o/
16:09:20 <lbragstad> curious to get peoples thoughts in review
16:10:13 <cmurphy> i thought the agreement was basically to just do one model for now
16:10:17 <kmalloc> cmurphy: ++
16:10:20 <lbragstad> ++
16:10:22 <kmalloc> that was my understanding
16:10:26 <lbragstad> yeah - i think that's still the direction
16:10:37 <wxy|> ++ yeah
16:10:38 <kmalloc> with the ability to add future models once we have the framework
16:10:48 <lbragstad> but there are other details in those specifications like GET /limit-model
16:10:48 <wxy|> base one john's
16:12:11 <lbragstad> so - keep all of the enforcement model discussion in john's specification and all the "additional" details in wxy|'s ?
16:12:54 <kmalloc> that would be my preference, as enforcement has nothing to do with what we land in keystone *except* the expected data formats
16:13:03 <lbragstad> sure
16:13:04 <cmurphy> can we turn the question around - what is the next stage of work that needs to be accomplished in Rocky?
16:13:27 <kmalloc> but... if the difficulty too high to keep them separate for cmurphy's question and others, merge it.
16:13:32 <wxy|> I have a POC about john's two-level-model https://review.openstack.org/#/c/557696/ The way is different with the spec's. Need your eyes on.
16:13:56 <kmalloc> my preference is simply so we can avoid a hard-to-manage kystonespec
16:14:01 <lbragstad> i would say that the next logic piece of work is to firm up what we have an make it stable, which is what wxy|'s spec talks about
16:14:05 <kmalloc> but not if it gets in the way of the work
16:14:21 <cmurphy> lbragstad: okay then let's go with that
16:14:56 <lbragstad> ok - that helps
16:15:40 <lbragstad> wxy|: was that the intention of your specification, or were you planning on having it evolve into an enforcement model of some kind?
16:17:34 <wxy|> it's about hierarchical model in Keystone which john wrote in his spec, but i changed the way, not sure which is better.
16:18:16 <wxy|> TBH, his spec is about some api changes which I don't like a bit.
16:18:22 <lbragstad> ok - so part of your specification focuses on an enforcement model
16:19:19 <lbragstad> well - maybe what we can do is take the bits that you see differently from john's proposal and put those into a different specification from the things that we need to do to make the API stable
16:22:58 <lbragstad> i can help write a specification for stablizing the unified limits API so that wxy| can focus on the limit enforcement details
16:23:02 <cmurphy> lbragstad: tbh I partly see implementing the first model as part of stabilization
16:23:22 <lbragstad> oh?
16:23:47 <lbragstad> does flat count as the first model?
16:24:10 <lbragstad> or first model == first *hierarchical* model?
16:24:28 <cmurphy> eh I guess flat can count
16:25:21 <lbragstad> we don't have to split them, i was just trying to think of was to make the purpose of each one more clear
16:25:37 <lbragstad> and that can be done without splitting, depending on how it's broken up in the specification
16:25:59 <cmurphy> sorry, no objections from me, we can keep them split if that makes more sense
16:26:21 <lbragstad> i'll go back and review it again... maybe that will help
16:26:56 <lbragstad> any other questions on unified limits?
16:27:49 <lbragstad> #topic specification: application credentials
16:27:58 <lbragstad> #link https://review.openstack.org/#/c/396331/
16:28:07 <lbragstad> the latest revision includes all the changes we talked about last week
16:28:15 <lbragstad> i just have a few follow-up comments
16:28:23 <lbragstad> otherwise, i think it's looking pretty good
16:28:47 <wxy|> I think john's is a right direction. I'm not oppose to that model, but only have different opinion about code implementation. That's all.
16:29:00 <lbragstad> wxy|: ++
16:30:18 <lbragstad> i pinged jgrassler yesterday to see if he'd had a chance to see my comments, but i haven't heard anything yet
16:30:22 <wxy|> maybe mine could move to backlog, since it talks a lot about the whole workflow.
16:30:56 <cmurphy> lbragstad: we had a four-day weekend in europe
16:31:04 <lbragstad> oh
16:31:05 <lbragstad> sure
16:31:07 <cmurphy> some people are still gone
16:32:31 <lbragstad> we still have plenty of time, i think that spec is getting really close thoguh
16:32:37 <lbragstad> #topic specification: JWT
16:32:43 <lbragstad> so - this one is fun...
16:32:47 <lbragstad> #link https://review.openstack.org/#/c/541903/
16:33:22 <lbragstad> several people spent time last week discussing the direction of this
16:33:35 <lbragstad> i've attempted to capture as much as possible in the reproposed version
16:33:51 <lbragstad> because it brings up some important notes about JWE vs JWS
16:34:13 <lbragstad> if you read cmurphy's weekly recap last Friday, it was in there too (thanks!)
16:34:53 <lbragstad> does anyone have questions or concerns, given the new details included in the specification?
16:35:30 * cmurphy still needs to reread it
16:37:03 <gagehugo> yeah I need to take another look at it
16:37:22 <lbragstad> cool - i'm curious what people think about it
16:38:02 <lbragstad> #topic specification: default roles
16:38:10 <lbragstad> #link https://review.openstack.org/#/c/523973/
16:38:23 <lbragstad> this one's gotten a couple reviews
16:38:34 <lbragstad> smcginnis had a suggestion on the naming
16:38:43 <lbragstad> thanks to hrybacki for keeping it updated
16:38:54 <hrybacki> which zane had a pretty strong counter-opinion for
16:38:55 <hrybacki> aye
16:39:08 <hrybacki> basically, sean proposed s/writer/operator/
16:39:27 <hrybacki> so auditor/operator/admin vs reader/writer/admin
16:40:02 <lbragstad> i tend to lean on zaneb's argument
16:40:25 <hrybacki> if operator ~== cloud admin -- then I agree
16:40:35 <hrybacki> that would just make things more confusing
16:40:54 <lbragstad> but i'm not sure i have a different alternative to "writer"
16:41:18 <hrybacki> BUT I will say read/write/admin is confusing as well -- in that the diff. between write and admin isn't clear plus admin breaks the '*nix' file permissions metaphor
16:41:29 <cmurphy> ah yeah i definitely agree with zaneb, calling member -> operator would be super confusing
16:41:45 <hrybacki> I've got it! 'auditor/writer/adminer' done
16:41:53 <hrybacki> pack it up folks, all done for the day /s
16:42:03 * lbragstad is about to ask a _really_ dumb question
16:42:11 <lbragstad> do we need writer then?
16:42:17 <hrybacki> yes
16:42:22 <lbragstad> what if we just targetted admin and reader?
16:42:38 <lbragstad> and handled scope properly?
16:42:47 <hrybacki> I like that ^^ but the folks at PTG were very specific in the ask for all three
16:42:54 <lbragstad> yes..
16:42:55 <cmurphy> that doesn't make sense
16:43:08 <lbragstad> yeah... after i say it outload, it doesn't make sense
16:43:13 <lbragstad> disregard
16:43:14 <lbragstad> :)
16:43:41 <hrybacki> if we were to de-scope I would say make a default 'reader' role and try to have it land in as many projects as possible
16:43:52 <hrybacki> but I don't think that's the right action given our timeline and comments from PTG
16:44:00 <lbragstad> that's fair
16:44:24 <hrybacki> so, to avoid further bikeshedding -- can we (as keystone team) agree upon three names for these categories?
16:44:46 <cmurphy> i don't think member is that bad
16:44:53 <hrybacki> at the lowest level we seem to have landed on either reader or auditor
16:45:13 <lbragstad> cmurphy: why is that?
16:45:34 <hrybacki> cmurphy: the issue with member IIUC is that it's already overloaded a bit and it's used inconsistently e.g. Member vs _member_
16:46:08 <cmurphy> lbragstad: idk, "membership" to me means belonging to a project but it doesn't imply administrator
16:46:31 <lbragstad> ok - so
16:46:33 <cmurphy> hrybacki: i don't think it matters that we have member and Member and _member_ we can just choose one and keep going with it
16:46:44 <hrybacki> fair enoguh
16:46:45 <hrybacki> enough*
16:47:02 <lbragstad> option 1: admin/operator/reader option 2: admin/writer/reader option 3: admin/member/reader
16:47:17 <hrybacki> lbragstad: what about 'auditor' vs 'reader' ?
16:47:46 <hrybacki> personally I like the former. I think auditor/member/admin paints a relatively clear picture when paired together
16:48:11 <hrybacki> all read as nouns with a purpose imo
16:48:45 <lbragstad> #1 operator #2 writer #3 member
16:48:56 <lbragstad> #4 reader #5 auditor
16:49:24 <hrybacki> I vote 3/5 or 2/4
16:49:42 <lbragstad> if we're not going with the *nix permission model, then i'm inclined to say #3 and #5
16:49:46 <hrybacki> operator seems an obvious no given its history
16:50:11 <hrybacki> contextual* history
16:50:45 <hrybacki> two votes for auditor/member/admin
16:51:04 <lbragstad> if we did either reader or writer, i'd be inclined to include the other
16:51:22 <hrybacki> same
16:51:58 <hrybacki> if no one opposes, I'll re-write the spec accordingly
16:52:32 <hrybacki> cmurphy: what was your issue with tying the spec to domain level operations?
16:52:43 <hrybacki> apologies -- can't find it in the review atm
16:53:10 <lbragstad> i was never really a fan on "member", but if we're not doing the *nix permission thing, then it makes more sense to stick with member
16:53:18 <cmurphy> hrybacki: we don't have real domain scope right now
16:53:58 <cmurphy> as far as i know?
16:54:10 <hrybacki> yeah, I'm not even sure now that you mention it. lbragstad ?
16:54:13 <lbragstad> cmurphy: you're correct
16:54:14 <cmurphy> i think we have project scope and system scope and you can maybe say we have domain-is-project scope but not domain scope as a first class scope
16:54:51 <lbragstad> domain scope would essentially `if 'project' in scope_types and project.is_domain`
16:55:00 <hrybacki> okay, I think 'domain' scope helps to solidify the concepts we are proposing
16:55:09 <hrybacki> but we can add a caveat in the spec noting as much ^^
16:55:36 <hrybacki> would that be enough cmurphy or would that be a bit too misleading?
16:56:01 <cmurphy> if this is what we're asking projects to implement then implying that we have real domain scope seems a little misleading to me
16:56:46 <hrybacki> okay, lemme chew on this for a bit
16:57:07 <hrybacki> are there any serious issues that folks see that would prevent this from landing by M1?
16:57:28 <hrybacki> e.g. should I prioritize getting feedback for certain parts of the spec?
16:57:35 <cmurphy> back on naming - aws has reader and writer https://aws.amazon.com/iam/details/manage-permissions/
16:58:36 <lbragstad> 2 minutes remaining
16:59:01 <lbragstad> hrybacki: i don't see any issues outside of the naming bits and relaying domain scope
16:59:08 <lbragstad> in a way that makes sense
16:59:29 <hrybacki> ack. I'll think on it today and get back to you with some questions later
16:59:35 <hrybacki> thanks all for the input :)
16:59:39 <lbragstad> sounds good - thanks hrybacki
16:59:57 <lbragstad> we can wrap up and i'll start office hours in a minute
17:00:00 <lbragstad> #endmeeting