16:00:38 <lbragstad> #startmeeting keystone
16:00:39 <openstack> Meeting started Tue Feb 12 16:00:38 2019 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:43 <openstack> The meeting name has been set to 'keystone'
16:00:53 <vishakha> o/
16:00:57 <gagehugo> o/
16:01:14 <cmurphy> o/
16:01:24 <wxy|> o/
16:01:31 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:01:36 <lbragstad> agenda ^
16:01:55 <lbragstad> we'll give folks a minute to join
16:02:40 <knikolla> o/
16:03:55 <lbragstad> #topic user survey questions
16:04:11 <lbragstad> the foundation emailed me asking about the upcoming user survey
16:04:28 <lbragstad> they usually check in each release and ask if we want to adjust the questions we have
16:06:12 <lbragstad> i put the current questions/suggestions we have in etherpad
16:06:12 <kmalloc> o/
16:06:25 <lbragstad> which - i don't think have been updated since stevemar was ptl
16:06:31 <lbragstad> so about 2+ years
16:06:34 <lbragstad> ago
16:07:24 <lbragstad> the foundation needs to know if we want to change any of those answers by friday
16:07:27 <cmurphy> would be nice if the survey could let people add specific comments, the multiple choice question is a little too generic to get really good feedback
16:07:46 <lbragstad> cmurphy i agree - but i don't think that's an option
16:07:52 <cmurphy> yeah
16:08:20 <knikolla> i would love to ask whether they're using sql backend or smth else
16:08:32 <knikolla> to see adoption of federation
16:08:33 <cmurphy> ++
16:08:36 <lbragstad> for which subsystems?
16:08:43 <lbragstad> identity?
16:08:46 <knikolla> yup
16:08:53 <cmurphy> a "what features and drivers are you using" in general would be nice
16:09:32 <lbragstad> with a text box for input?
16:09:59 <knikolla> a multiple selection checkbox would work
16:10:00 <cmurphy> we could probably enumerate it
16:10:02 <hrybacki> o/
16:10:10 <knikolla> as I don't thin there'll be many with non-standard drivers.
16:10:14 <knikolla> thnk*
16:10:36 <lbragstad> feel free to add thoughts to the etherpad, too
16:10:44 <gagehugo> ok
16:10:46 <lbragstad> in case i'm not capturing this properly
16:11:02 <lbragstad> i'm for dropping the per domain configuration question
16:11:05 <kmalloc> SQL, LDAP, Other (in-house developed)
16:11:18 <lbragstad> that one has been low on the survey response for a long time
16:11:32 <knikolla> lbragstad: ++
16:12:08 <kmalloc> per domain config is used some places, enough to warrant continued top level support/development but not enough to warrant an endless place on the survey
16:12:20 <knikolla> ++
16:12:49 <lbragstad> enhancing policy is also pretty vague
16:12:59 <cmurphy> heh
16:13:02 <lbragstad> ideas on how we can better gauge that area?
16:13:16 <kmalloc> assume policy is something we don't need to ask about until system scope and default roles land
16:13:18 <lbragstad> outside of "yes, make better plskthx"
16:13:20 <kmalloc> like... the T cycle or so
16:13:29 <cmurphy> "make policy unbad plz"
16:13:32 <hrybacki> lbragstad: we could ask people what areas of policy they want enhanced?
16:13:35 <hrybacki> lol cmurphy
16:13:37 <kmalloc> right now it is enough in flux to not ask folks right now
16:13:52 <knikolla> yup
16:13:58 <knikolla> i think policy is moving in the right direction
16:13:59 <kmalloc> cmurphy: you forgot "k thnx bye"
16:14:04 <cmurphy> lol
16:14:04 <lbragstad> so omit it from the survey completely?
16:14:14 <kmalloc> lbragstad: yes
16:14:20 <knikolla> i'm with kmalloc on this one.
16:14:32 <kmalloc> add it back in the cycle AFTER we have stabilized default roles and system scope
16:14:47 <kmalloc> and we can be more directed about it
16:15:04 * lbragstad feels like we're missing an opportunity to establish a feedback loop
16:15:08 <kmalloc> "does X meet your needs"... "is y sufficient" ... "enhancements for z"
16:15:23 <lbragstad> but i do see it as a turbulent area of keystone currently
16:15:33 <kmalloc> i don't think so, this is so much in flux you're going to get not-super-useful data
16:15:59 <kmalloc> i think the answers will be: "yeah, it might be better, but uhm... we aren't using it cause it's not usable yet"
16:16:06 <cmurphy> i disagree a little, it's still useful to compare it to past years on whether this is a top concern
16:16:20 * hrybacki nods
16:16:22 <cmurphy> which it most likely will be but if we omit the question the data gets skewed
16:16:28 <lbragstad> ++
16:16:33 <kmalloc> I'd probably ask for a direct question about top concerns/areas needing most work
16:16:42 <hrybacki> this allowed us to see Federation re-raised in priority
16:16:45 <kmalloc> rather than "is policy good/bad/something"
16:16:58 <lbragstad> ok - so what would those direct questions be?
16:17:20 <kmalloc> I'd go for something like: What part of keystone needs the most improvement for your deployment?
16:17:22 <lbragstad> i've always been curious how many deployments roll custom policy and do what extent, but that's a tough one
16:17:23 <knikolla> "Would you like to use your corporate identity provider with OpenStack but unable to do so?"
16:17:52 <kmalloc> if we can do a ranked choice vs multi choice and list out what we think the components are it would be good
16:18:00 <hrybacki> kmalloc++
16:18:18 <ayoung> "Do you put a  layer in front of OpenStack to prevent users having direct access due to access control concerns."
16:18:37 <lbragstad> e.g., do you deploy adjutant
16:19:07 <knikolla> lbragstad: i think i'm the minority in asnwering yes to that.
16:19:15 <kmalloc> if we can't do a ranked choice, i totally get keeping policy question(s) in.
16:19:15 <ayoung> I'm thinking more like in front of Nova
16:19:37 <knikolla> ayoung: "do you stock up on alcohol before dealing with keystone?"
16:19:41 <kmalloc> a multi-selection checkbox (check 3 of X) would also be fine.
16:19:49 <ayoung> "do you allow end users access to Openstack directly, or do you make them go through a portal."
16:20:47 <cmurphy> "do you modify default policy" might be interesting
16:20:51 <ayoung> its not something people see in keystone, but rather policy across the board.  Just, we are the ones driving it.
16:21:25 <ayoung> cmurphy, yeah.  Or :"Would you like to have a different policy but can't"
16:22:34 <lbragstad> this is good
16:22:38 <lbragstad> what else?
16:23:15 * kmalloc avoids really snarky questions.
16:23:18 * kmalloc is pre-coffee.
16:23:26 <lbragstad> fwiw - aprice and jamesmcarthur are going to be around to answer questions about the survey format in 40 minutes
16:23:31 <ayoung> Probably something about "what IdM features of public clouds would you mosty like  to see in OpenStack"
16:23:47 <lbragstad> does public cloud have to be a part of the question?
16:23:55 <lbragstad> or can that apply to private/hybrid?
16:24:54 <kmalloc> i would avoid asking specifically "what IdM features of other clouds" and ask more about generic Identity Management features (not cloud specific)
16:25:11 <kmalloc> you can say "including public cloud providers"
16:25:27 <kmalloc> but i wouldn't strictly limit in that way.
16:26:19 <lbragstad> ok - keep thinking of topics, i'll be visiting with the foundation about the format for questions soon if anyone is interested in helping out there
16:26:38 <lbragstad> i'll revise everything and send it off before friday
16:26:43 <ayoung> it should be public cloud explicitly.  Otherwise, we will never be forced to learn
16:26:51 <ayoung> For example:
16:27:09 <ayoung> in Azure,. if you delete a project, you delete all of the resources of that project.
16:27:28 <kmalloc> ayoung: ok that isn't really IdM specific
16:27:50 <kmalloc> i'd phrase that in another way. we've (in openstack) cross IdM with other types of management.
16:27:58 <ayoung> Good point.  We put it under the Id project, but THey don't
16:28:04 <kmalloc> yes.
16:28:28 <kmalloc> it's a great question, but we need to be sure we put it in the right context
16:28:41 <lbragstad> are we good to move? we can circle back to this after?
16:28:55 <ayoung> sure
16:28:58 <lbragstad> #topic features in flight
16:29:17 <lbragstad> just a quick check point on the things we said we were going to deliver for this release
16:29:25 <lbragstad> since we have 4 weeks until feature freeze
16:29:34 <lbragstad> it's going to likely be a race with the gate
16:29:46 <lbragstad> the MFA auth receipt work is done
16:30:19 <lbragstad> the JWT provider work needs reviews - in addition to some careful eyes from wxy| about the performance concerns
16:30:44 <lbragstad> (i spent a bunch of time last week trying to performance test loading keys from disk - but i might need more information)
16:31:07 <kmalloc> lbragstad: i can take a pass at trying to make it not-on-disk-specific as followups to your code
16:31:16 <kmalloc> it is fine to land as-is imo
16:31:18 <lbragstad> i was going to write up a summary on the mailing list about it, too
16:31:20 <kmalloc> on the performance front
16:31:32 <kmalloc> we can enhance past FF.
16:31:39 <kmalloc> or in Train.
16:31:46 <kmalloc> lets not spin too hard on this right now.
16:31:57 <lbragstad> i'm fine with it being iterative,
16:31:57 <kmalloc> fernet had iterations, JWT will too
16:32:24 <wxy|> kmalloc: ++, we can revisit it later.
16:32:25 <lbragstad> but if we can nail down how to recreate the issues wxy| mentioned for public cloud, i'll get something fixed before RC
16:32:34 <kmalloc> yes.
16:32:54 <lbragstad> wxy| if i start a thread on the mailing list, would you be able to update it?
16:33:10 <lbragstad> or just share/double check my process for recreating the issue?
16:33:13 <kmalloc> it'll be easier to do that once JWT is landed. IT is not bad code nor something we should hold up. make sure we mark the release note that iterations on performance are expected to occur
16:33:15 <kmalloc> or something.
16:33:42 <wxy|> lbragstad: Sure
16:33:53 <lbragstad> #action lbragstad to summarize key loading performance notes on the openstack-discuss mailing list
16:33:56 <wxy|> I can try to get more information (like performance test data) from downstream team as well.
16:34:00 <kmalloc> I fully expect you'll need to run some kind of io-contention running process to force it to duplicate the read-from-disk issues with low disk-cache / low ram available for disk caching
16:34:03 <lbragstad> that'd be great
16:34:10 <kmalloc> it's hard to replicate a real-world environment on that front.
16:34:36 <kmalloc> especially with repos being deployed ${wherever} and shared with ${other_processes}
16:34:50 <lbragstad> sounds good
16:34:56 <hrybacki> I would like to say that we already have a big performance hit from uuid->fernet so it's worth paying close attention to for jwt (especially if we aim for it to be default)
16:34:56 <kmalloc> heck, i wouldn't be surprised if folks deploy keys via NFS and have performance issues that way as well.
16:35:25 <kmalloc> hrybacki: ++ and i think we can be better with JWT, fernet is hard to be a ton better with.,
16:35:47 <kmalloc> asym crypto (signing) vs symmetric crypto (encryption)
16:36:00 * hrybacki nods
16:36:21 <lbragstad> so - we have a plan for that it sounds like
16:36:34 <lbragstad> explicit domain ids
16:36:55 <lbragstad> someone was pinging about that last week - and it sounded like they were interested in helping out with the work
16:37:09 <lbragstad> i'm not sure if they got in touch with you ayoung
16:37:20 <lbragstad> optrenko i believe?
16:38:20 <ayoung> Not that I remember seeing
16:38:26 <lbragstad> ok
16:39:33 <ayoung> With JWT validated in process, we should not need to go back to Keystone for every token, and performance should improve. It requires fetching and caching of Keystone data,though.
16:39:52 <lbragstad> ok - if i see them i'll try and get an update
16:39:53 <ayoung> The token body itself needs to contain all of the user specific data, not just Ids
16:40:07 <ayoung> but not service catalog
16:40:22 <lbragstad> the default roles work still needs a bunch of reviews - but we're getting there
16:40:28 <kmalloc> so, the concern is token body size there ayoung
16:40:31 <ayoung> roles can be ID only, if the service fetches and caches them.
16:40:47 <ayoung> Yep.  There should be a hard limit in the vicinity of 2K I'd say on token size
16:41:04 <ayoung> Just to draw a line in the sand
16:41:23 <ayoung> we know 8 K is too big, and we know we can get away with 1K
16:41:24 <hrybacki> lbragstad: lets sync this afternoon on the roles stuff. I've managed to sluff off enough responsibilities to aid now
16:41:28 <ayoung> ++
16:41:37 <lbragstad> we still have a bunch to get through on the agenda - mind if we table the jwt stuff til office hours?
16:42:09 <lbragstad> domain level unified limit support is all ready for review - waiting on a patch to fix a sqlite migration
16:42:38 <lbragstad> hrybacki ++
16:42:54 <lbragstad> is there anything i'm missing feature wise?
16:43:03 <cmurphy> i'm making good progress with app cred whitelist, but it is going to be a lot of patches and there might not be enough time to review, if that happens i think it's okay to push it to next cycle
16:43:05 <kmalloc> ayoung: yes, we absolutely need to be less than 4k, but also note significant sizes are a deal breaker for swift on the front of "Recommended" auth methods. when your auth token is larger than the data you are sending to the user.....
16:43:16 <lbragstad> oh - yes cmurphy (sorry!)
16:43:32 <cmurphy> np
16:43:34 <lbragstad> cmurphy those are ready for review?
16:43:41 <cmurphy> lbragstad: not really no
16:43:42 <lbragstad> last i saw you had them WIP'd
16:44:19 <cmurphy> these two ksa patches could be reviewed https://review.openstack.org/636030
16:44:29 <cmurphy> they will need to land before ksm tests will work
16:44:42 <lbragstad> ok
16:45:24 <lbragstad> that brings up our next topic
16:45:28 <cmurphy> wip ksm change if you want to see why those are needed https://review.openstack.org/633369
16:45:31 <lbragstad> does anyone have patches they need eyes on?
16:45:52 <lbragstad> cmurphy cool - i can take a look
16:46:07 <vishakha> a small change https://review.openstack.org/#/c/635444/
16:46:28 <lbragstad> thanks vishakha
16:46:39 <kmalloc> vishakha: +2/+A
16:46:49 <cmurphy> i think this ksm change is ready to go https://review.openstack.org/633695
16:46:58 <vishakha> lbragstad,kmalloc: thanks
16:47:16 <lbragstad> nice
16:47:50 <kmalloc> and we probably want to revisit https://review.openstack.org/#/c/613675/ just to cleanup / make KSM easier to work with.
16:47:54 <kmalloc> PKI[z] is long dead
16:48:16 <kmalloc> it should land *after* a rebase on the one cmurphy just linked.
16:48:24 <lbragstad> yeah - so my only reason for the -1 there was because we socialize a format for deprecation
16:48:28 <kmalloc> so 635444 should land.
16:48:44 <kmalloc> lbragstad: and my response to that stands.
16:49:06 <lbragstad> it's a difference of logging a warning or not i think
16:49:25 <kmalloc> and maintaining dead opts in the code that have zero impact.
16:49:27 <lbragstad> mainly so people can see what they can clean up
16:49:32 <ayoung> kmalloc, I think we should let cmurphy 's work land before we strip out all the PKI stuff.
16:49:49 <kmalloc> it's fine on the order of landing.
16:49:51 <ayoung> or order the two patches explicitly, to keep from rebase hell
16:50:06 <kmalloc> i have no qualms when it lands.
16:50:17 <cmurphy> 10 minutes left
16:50:19 <ayoung> Yeah, just want to not mess up the feature work
16:50:21 <kmalloc> i knwo cmurphy did voice a "pki code" made some things more difficult
16:50:40 <cmurphy> kmalloc: not pki specifically, the whole ksm test suite is a huge mess
16:50:42 <kmalloc> lbragstad: it is communicated via release note that the options are removed.
16:50:46 <kmalloc> cmurphy: fair.
16:50:54 <kmalloc> cmurphy: and yes. it is.
16:51:00 <cmurphy> cleaning up unecessary crap is a good start but would be good to do a full reorg
16:51:01 <lbragstad> i'll re-review it kmalloc
16:51:15 <kmalloc> lbragstad: it can land at anypoint
16:52:00 <kmalloc> cmurphy: i think if we can strip out (do removals) of dead code it'll make the reorg easier too.
16:52:10 <kmalloc> cmurphy: and yeah it def. needs to be reworked.
16:52:11 <cmurphy> kmalloc: ++
16:52:16 <lbragstad> ok - anything else for reviews?
16:52:36 <lbragstad> #topic cleaning up stale blueprints
16:52:52 <lbragstad> the state of blueprints in launchpad has been rough for a while
16:53:01 <lbragstad> i'm going to put some time into removing cruft and updating things
16:53:10 <lbragstad> if anyone is interested in learning about that process, just ping me
16:53:18 <lbragstad> #topic ops meetup in berlin
16:53:21 <kmalloc> fwiw, I still recommend dropping blueprints and just using RFE bugs.
16:53:33 * kmalloc has a change to the spec template to communicate that
16:53:36 <kmalloc> proposed*
16:53:38 <cmurphy> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002614.html call for topics
16:53:40 <hrybacki> would that be verbose enough?
16:53:59 <kmalloc> hrybacki: we can chat more in -keystone post meeting.
16:54:12 <cmurphy> I'll be at the berlin ops meetup in march
16:54:22 <cmurphy> they are asking for topics that need more input from operators
16:54:30 <cmurphy> so if there are deas follow up on the links in that email
16:54:36 <cmurphy> and/or let me know and i can bring them up
16:54:43 <ayoung> cmurphy, kmalloc we have the policy lab.  If that gets the ax, I want to move it to the official keystone topics list.  Maybe do so anyway?
16:54:47 <lbragstad> thanks cmurphy
16:55:03 <kmalloc> sure
16:55:07 <hrybacki> ayoung: at the berlin meetup?
16:55:16 <lbragstad> #topic open discussion
16:55:20 <kmalloc> fwiw, i will not be at the berlin meetup.
16:55:34 <lbragstad> aprice and jamesmcarthur are here to help answer questions about the format of the user survey
16:55:37 <cmurphy> lbragstad: re lp blueprints count me in
16:55:38 <kmalloc> and i will not be at the shanghai summit.
16:55:56 <jamesmcarthur> o/
16:56:08 <lbragstad> aprice jamesmcarthur i think the biggest piece of information we're curious about is what format we're limited to with questions
16:56:21 * kmalloc rolls the piano in... realizes this is not the right time, and rolls the piano back out.
16:56:35 <aprice> o/
16:56:37 <lbragstad> we have some examples of the questions we'd like to ask starting at line 33 here - https://etherpad.openstack.org/p/keystone-weekly-meeting
16:56:37 <jamesmcarthur> You can select pretty much any format you see on the survey.
16:57:14 <kmalloc> is ranked choice for a question possible?
16:57:25 <kmalloc> or is it better to just do a "select 3 of X" optioins
16:57:26 <jamesmcarthur> There is a ranked choice option.
16:57:31 <kmalloc> cool. :)
16:58:02 <aprice> lbragstad: because of the volume of projects, each project is limited to two questions so we would want to select which ones out of that list that you would like to include.
16:58:24 <kmalloc> hrybacki, lbragstad: ^ that could make the "what needs work" question more general and keep a pulse on it survey-to-survey
16:58:37 <lbragstad> sure
16:58:50 <hrybacki> yeah, we should think hard if we are limited to two
16:58:54 <ayoung> hrybacki, ah, misread.  I meant under the Denver summit/PTG umbrella.
16:59:06 <hrybacki> ayoung: ack, thought so but wanted to clarify
16:59:24 <aprice> if you do want to do more, we could link to a survey monkey that we could facilitate that could also be shared on the ML
16:59:41 <hrybacki> gotta run o/ folks
16:59:41 <aprice> but within the user survey specifically, there would be that limit
16:59:44 <lbragstad> that's a good idea
17:00:25 <lbragstad> we're out of time, but we can continue in -keystone if folks are still curious about the survey
17:00:32 <lbragstad> i appreciate the time, everyone
17:00:38 <lbragstad> #endmeeting