16:00:17 <lbragstad> #startmeeting keystone
16:00:18 <openstack> Meeting started Tue Mar 27 16:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <openstack> The meeting name has been set to 'keystone'
16:00:28 <cmurphy> o/
16:00:30 <lbragstad> o/
16:00:37 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:40 <gagehugo> o/
16:00:42 <lbragstad> agenda ^
16:00:50 <jgr> Hello
16:00:50 <wxy|> o/
16:00:55 <lbragstad> ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy
16:01:12 <hrybacki> o/
16:01:37 <knikolla> o/
16:02:03 <kmalloc> o/ also zzzzzzzzzz
16:03:10 <lbragstad> #topic Rolling upgrade bug
16:03:39 <lbragstad> someone dropped by the keystone channel this morning with another rolling upgrade bug that we suspected to be related to one that has been reported before
16:03:41 <lbragstad> #link https://bugs.launchpad.net/keystone/+bug/1755906
16:03:46 <openstack> Launchpad bug 1755906 in OpenStack Identity (keystone) "Occasional deadlock during db_sync --contract during Newton to Pike live upgrade" [High,Confirmed]
16:04:04 <lbragstad> i threw it on the agenda before we reached a resolution
16:04:14 <lbragstad> turned out to be a different problem
16:04:27 <lbragstad> i'm goingt o try and dig into this relatively soon, pending spec reviews,
16:04:37 <raildo> o/
16:04:43 <lbragstad> if anyone else is interested in tag-teaming this, let me know
16:05:05 <lbragstad> we've had several people hit it (excluding the false positive this morning)
16:05:14 <kmalloc> I can take a gander this morning.
16:05:21 <lbragstad> thank kmalloc
16:05:37 <kmalloc> I have a history of being able to dig out weird SQL edge cases.. :(
16:05:41 <lbragstad> it's a pretty interesting upgrade problem
16:06:06 <lbragstad> it consists of a surprisingly common edge case
16:06:07 <kmalloc> I'll hit it post meeting.
16:06:12 <lbragstad> sweet
16:06:20 <lbragstad> #topic specifications
16:06:43 <lbragstad> #info reminder that specification proposal freeze is april 20th
16:06:53 <kmalloc> MFA receipt: ayoung needs to look at it and +2/+A it :P
16:07:06 <kmalloc> Unless someone already +a'd it
16:07:14 <lbragstad> I +2'd it
16:07:26 <kmalloc> Yeah, I think it is ready.
16:07:34 <kmalloc> Saw your score on it.
16:07:47 <lbragstad> I didn't +A it because we need to fix up the shuffling of specs/trello boards/etc...
16:07:56 <lbragstad> i can propose a follow on to do that and then +A it
16:08:19 <lbragstad> otherwise - yeah, exciting to see the needle move there
16:08:45 <kmalloc> And, we need to also do the whitelist one.
16:08:54 <lbragstad> also - we need to come to consensus on application credentials
16:08:55 <kmalloc> Which is very close if not ready as well.
16:08:56 <lbragstad> #link https://review.openstack.org/#/c/396331/
16:09:23 <jgr> Yeah...
16:09:32 <lbragstad> i think the details are fine, but we need to make sure we document and reach consensus on a attribute name for it
16:09:37 <jgr> So I'm not terrible wedded to the term "whitelist" if we really must change it.
16:10:02 <lbragstad> i wanted to ping adam this morning, because he needs to be a part of the conversation, but he wasn't online
16:10:08 <kmalloc> Also, whitelist is fine
16:10:19 <kmalloc> No reason to block it on that
16:10:25 <jgr> I still think getting rid of it is over the top, but if the consensus turns out otherwise I'm ok with changing it.
16:10:28 <kmalloc> It *is* a whitelist
16:10:28 <hrybacki> he's on on internal this morning either
16:10:46 <kmalloc> So, let me just take a stand and say we don't need to change the term.
16:10:50 <kmalloc> Really.
16:10:52 <lbragstad> regardless of the term, we *need* to document the justification for it and provide supporting evidence
16:11:16 <lbragstad> in a public forum
16:11:22 <cmurphy> I think capability list is more descriptive
16:11:35 <kmalloc> Except it isn't imo
16:11:52 <kmalloc> It isn't a strictly defined list of capabilities
16:12:00 <cmurphy> isn't it?
16:12:05 <kmalloc> It is a fluid list of allowed uris
16:12:28 <lbragstad> does the usage of wildcards make it fluid?
16:12:45 <lbragstad> or ! strict?
16:12:49 <kmalloc> That doesnt really sound like a capability list to me, it is an opt-in restriction of allowed resource actions
16:13:05 <kmalloc> That is a whitelist (almost to a tee)
16:13:35 <kmalloc> If it was "boot vm" and "make volume", etc strictly defined, it would be more capability list
16:13:58 <kmalloc> But, due to architecture, that isnt really doable.
16:14:23 <kmalloc> It could still be "white listed actions" or whitelisted capabilities
16:14:51 <kmalloc> This acts like a whitelist, if it is a duck, call it a duck :)
16:15:26 <jgr> Yeah. Problem is, there's this tweet from this Microsoft guy out there who considers it an unfriendly term :-/
16:15:42 <kmalloc> But that is just my stance (and I wouldn't change my view of the core of the spec being ready if we change it)
16:15:54 <kmalloc> We won't make everyone happy.
16:16:20 <jgr> I'm not terribly happy with changing either, but I can live with it if we really must.
16:16:21 <hrybacki> I think documenting the reasoning behind choosing (whichever) term is the most important thing. Everything is in the context tbh
16:16:23 <kmalloc> Why is it "unfriendly" (that is a bad justification for not using the term) without more info.
16:17:19 <lbragstad> again - i think we need to involve adam in this part of the discussion
16:17:26 <kmalloc> Anyway, just gave my quick $0.002 that could be used for calling it a whitelist, feel free to steal it/use it/give ot not give credit.
16:18:00 <jgr> This guy pretty much sums up my take on it: https://twitter.com/dtoebe/status/976977954608594944
16:18:19 <kmalloc> lbragstad: we can ping him, but he has to be more available than drive by reviewing if he is going to be a blocker for specs..
16:18:54 <jgr> There are people out there thinking the term is racially charged.
16:19:22 <lbragstad> jgr: you found some level of documention by a linguist, right?
16:19:30 <jgr> lbragstad: yes, just a second
16:19:41 <jgr> https://www.quora.com/Is-the-term-blacklist-racist
16:19:55 <kmalloc> jgr:  I am not going to make you change the term for that tweet. This is not worth justifying on our end imo for this reason.
16:20:31 <lbragstad> and that is included in the review it looks like
16:21:01 <kmalloc> Can we discuss if the term is descriptive and correct, not if it is racially charged..
16:21:23 <lbragstad> i think that is getting to cmurphy's input
16:22:17 <jgr> "descriptive" (and more easily understandable to a non-native English speaker than an awkward circumlocution) is why I'd like to retain it, yes.
16:22:30 <hrybacki> jgr: are you advocating for a term synonymous with 'white list' but could not be considered insensitive?
16:23:15 <kmalloc> hrybacki: please drop this line.
16:23:47 <kmalloc> Let's get away from the insensitive or not part of the convo, it is not relevant to this part of the discussion.
16:23:55 <hrybacki> he's the spec author. I'm trying to provide a solution that meets your and his desires here
16:24:51 <jgr> hrybacki: I'm not advocating for a synonym (or circumlocution). But I'm willing to live with it so as not to hold up the spec (which I'd like to see land) over terminology.
16:25:43 <kmalloc> lets drop the line of questioning/assessment based upon the "unfriendliness"
16:25:50 <kmalloc> refocus the convo
16:26:07 <kmalloc> cmurphy: do you feel capability list is a better term (for technical/descriptive reasons)
16:26:16 <kmalloc> and enough so to warrant changing away from whitelist.
16:26:27 <kmalloc> hrybacki: ^ same to you.
16:26:39 <cmurphy> i do think it is better for technical reasons
16:26:43 <knikolla> access list?
16:27:05 <kmalloc> can you expand a little bit. and i'm happy to have the change with that reasoning.
16:27:48 <cmurphy> whitelist to me doesn't describe what is being listed
16:28:24 <cmurphy> capability list to me is all the things this app cred is capable of
16:28:26 <kmalloc> so, as i understand, you're seeing it as whitelist is a modifier, it could be a "capability whitelist" but "whitelist" is insufficient?
16:28:52 <kmalloc> [the converse of the implementation in the spec would be a capability blacklist]
16:29:23 <cmurphy> sure
16:30:08 <cmurphy> but we're never going to have a blacklist so it doesn't even entirely make sense to have whitelist when we're never going to have the converse
16:30:46 <kmalloc> right - i'm just clarifying
16:30:51 <lbragstad> fwiw - if capability is more descriptive of boot_vm, it's not to say we won't get to that in the future either
16:31:07 <kmalloc> on why we should change, that whitelist is insufficient
16:31:07 <lbragstad> even though the system doesn't work that way today
16:31:18 <kmalloc> as a term. not that we would have the inverse supported
16:31:48 <kmalloc> s/insufficient/insufficient in itself/
16:31:57 <cmurphy> sure, but that's another reason why i think whitelist is inappropriate, is because it implies the converse is possible
16:35:04 <lbragstad> that's true...
16:35:11 <kmalloc> cmurphy: that is fair
16:35:39 <kmalloc> i like that it is called a whitelist, because the functionality is that of a whitelist
16:36:15 <lbragstad> that's not to say we can't describe it as a whitelist in the documentation
16:36:17 <kmalloc> if the documentation clearly says it acts as a whitelist
16:36:22 <lbragstad> ++
16:36:26 <kmalloc> i'm thinking that is enough for me.
16:36:32 <cmurphy> i'm fine with that
16:36:35 <kmalloc> jgr: ^ would that be good?
16:36:51 <kmalloc> jgr: it hits both things, pretty clearly.
16:37:24 <lbragstad> cmurphy: have you left feedback about capability lists in the review?
16:37:34 <cmurphy> no, i can
16:37:42 <lbragstad> just double checking
16:37:59 <jgr> kmalloc: so "capability list" and document "it acts as a whitelist"?
16:38:36 <jgr> kmalloc: (sorry, the discussion has been going back and forth quite a bit so I want to be sure I got the conclusion right)
16:38:57 <cmurphy> i think that's the conclusion
16:39:03 <lbragstad> jgr: ++
16:39:06 <jgr> Sure, that works for me.
16:39:31 <lbragstad> mainly because the term "capability" is in the name, and it is descriptive, and that it doesn't imply we support the inverse
16:39:46 <jgr> I think I may actually have called it a "list of capabilities" back when I proposed this spec in Barcelona...
16:39:48 <lbragstad> cmurphy: kmalloc correct me if i'm wrong
16:41:10 <cmurphy> i agree with that
16:41:30 <lbragstad> cool - we have things to do with that then
16:41:32 <lbragstad> let's move on
16:41:57 <lbragstad> there are two specs proposed for hierarchical limits
16:41:58 <lbragstad> #link https://review.openstack.org/#/c/540803/
16:42:02 <lbragstad> #link https://review.openstack.org/#/c/549766/
16:42:07 <lbragstad> eyes on both of those would be good
16:42:08 <kmalloc> lbragstad: i also gave adam a direct response saying "don't use twitter as a source of knowledge and be careful of injecting things into the review process"
16:42:55 <lbragstad> one of them is actually CERN's write-up and encapsulates a lot of what we talked about in Dublin
16:43:41 <lbragstad> the other (written by wxy|) does a good job of laying out a bigger picture
16:44:13 <wxy|> i'll refresh them tomorrow, may merge them into one?
16:44:13 <kmalloc> jgr: please do not encapsulate any of the non-tech bits into the spec or documentation (insensitive/not/whatever) from this convo, it doesn't belong there, we can defend ourselves if needed, but it's not something we want in our docs.
16:44:35 <lbragstad> wxy|: yeah - that'd be good
16:44:36 <kmalloc> jgr: or in the spec itself, the comments on the review are enough/sufficient.
16:45:06 <lbragstad> wxy|: some of those action items might be better as bugs, too?
16:45:25 <wxy|> sure
16:45:57 <wxy|> and don't forget Sean's  https://review.openstack.org/#/c/441203/
16:46:07 <lbragstad> the specification for JWT needs eyes, specifically around the whole encryption/signing topic
16:46:08 <jgr> kmalloc: of course. I wasn't planning on doing that...
16:46:09 <lbragstad> #link https://review.openstack.org/#/c/541903/
16:46:31 <kmalloc> jgr: just wanted to be sure :)
16:46:55 <cmurphy> I think we're deferring on Sean's for now since we're focusing on just the CERN model
16:47:25 <lbragstad> Sean's or johnthetubaguy ?
16:47:32 <wxy|> cmurphy: could that be a backlog, not for Rocky?
16:47:54 <wxy|> Since some model seems helpful as well.
16:48:17 <cmurphy> i'm talking about this one https://review.openstack.org/#/c/441203/ we're not going to accomplish all those models this cycle so yes keep it in the backlog
16:48:25 <lbragstad> ++
16:48:32 <kmalloc> ++
16:49:19 <wxy|> cool. that works for me.
16:50:01 <lbragstad> alright - bumping the reviews topic since we're running short on time
16:50:08 <lbragstad> #topic help wanted
16:50:10 <lbragstad> cmurphy: o/
16:50:19 <cmurphy> oh right
16:50:34 <cmurphy> so i had this idea
16:50:49 <cmurphy> the tc has a "help wanted" list to try to constructively drive contributions
16:50:57 <cmurphy> i thought we could do something similar for keystone
16:51:11 <cmurphy> we have a lot of driveby contributions for like typo fixes or url fixes or PTI updates
16:51:18 <lbragstad> like - not add keystone as an item on the tc's help wanted list?
16:51:21 <cmurphy> we could steer those toward the little things that we really want help on
16:51:32 <cmurphy> right, not add keystone to the tc's, just have our own list
16:51:37 <lbragstad> ah
16:51:51 <gagehugo> that would be nice
16:51:58 <lbragstad> yeah..
16:52:03 <cmurphy> so like updating the docs to conform to the doc team's writing guide would be one thing
16:52:23 <cmurphy> fixing up usage of deprecated things in keystone would be one
16:52:37 <cmurphy> fixing up usage of deprecated keystone things in devstack and other projects would be one
16:52:48 <cmurphy> i'm sure we could come up with others
16:53:01 <lbragstad> i'm in favor of trying it...
16:53:13 <lbragstad> i also wouldn't be opposed to adding keystone to the tc's help wanted list
16:53:23 <lbragstad> i know we've talked about that in the past
16:53:30 <hrybacki> could we not do both?
16:53:39 <knikolla> ++
16:53:55 <hrybacki> or use one to drive potential contributors to the other, more formalized list of asks
16:53:59 <lbragstad> there isn't anything saying we can't
16:54:17 <lbragstad> at least not to my knowledge
16:54:19 <hrybacki> 'two nets catch more fish' or something
16:54:49 <hrybacki> not sure if that would be confusing or step on someone's toes though. cmurphy probably has best insights to that end
16:55:10 <lbragstad> in the past i was trying to be conscious of adding keystone to the tc list because i didn't want to take the opportunity from another project that needs more help
16:55:15 <cmurphy> my main concern right now was just with turning drive-by contributions into something constructive
16:55:42 <hrybacki> ack. cmurphy we could spend some time grooming that list today during OO
16:55:54 <cmurphy> if we added keystone to the tc's help wanted list that would be more focused on larger-scoped needs
16:56:08 <cmurphy> our specs backlog etc
16:56:10 <hrybacki> okay, that makes sense
16:56:15 <lbragstad> that makes sense
16:56:32 * lbragstad thinks unified limits and policy stuff should go on there
16:56:42 <cmurphy> exactly
16:57:23 <lbragstad> we'll need to make sure we keep the list fresh
16:57:43 <lbragstad> maybe review it during retrospectives or something like that
16:57:46 <hrybacki> lbragstad: we can refresh it on a weekly basis as part of a regular meeting
16:57:53 <hrybacki> or that
16:57:54 <lbragstad> that too
16:58:07 <lbragstad> I don't have a preference
16:58:18 <cmurphy> the things i have in mind are sort of ongoing tasks, like fixing up deprecated things
16:59:07 <hrybacki> ack. Maintaining a high level list of ongoing areas like ^^ and then creating bugs for specific, actionable items (that would obviously change as we progress) could be nice?
16:59:17 <cmurphy> ++
16:59:21 <lbragstad> i think so
16:59:28 <lbragstad> i'm all for it
16:59:28 <hrybacki> I'm thinking bugs for smaller actionables to help entice folks
16:59:46 <lbragstad> < 1 minute left
17:00:01 <lbragstad> we can pick things up in office hours
17:00:08 <lbragstad> thank all
17:00:12 <lbragstad> #endmeeting