18:01:57 <dolphm> #startmeeting keystone 18:01:58 <crinkle> o/ 18:01:58 <openstack> Meeting started Tue Aug 23 18:01:57 2016 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:01 <openstack> The meeting name has been set to 'keystone' 18:02:03 <dolphm> #topic fishbowls / work rooms / meetups 18:02:03 <lbragstad> o/ 18:02:28 <amakarov> hi 18:02:30 <dolphm> so, this summit is going to be layed out a bit differently (as i suppose every summit is), but the schedule is also going to be a bit cramped 18:02:42 <dolphm> so, we're being asked to choose the last few details of our schedule 18:02:51 <dolphm> to quote the agenda: In Austin we had 5 fish bowl sessions, 8 work room sessions; 2 half-day meetups 18:03:02 <ayoung> Here we have one 15 minute meeting 18:03:15 <ayoung> Of which 12 minutes are already booked 18:03:28 <bknudson> 3 minutes to get started... 18:03:40 <lbragstad> sounds like my kinda meeting 18:03:45 <samueldmq> hi keystoners! 18:03:51 <dolphm> we don't have a summit planning etherpad yet, do we? 18:04:36 <gagehugo> I haven't seen one yet 18:04:46 <dolphm> without one, does anyone recall us having too many / not enough fish bowls and/or work rooms in austin? 18:05:05 <dolphm> otherwise, i assume we can aim for the same basic schedule regarding bucket topics 18:05:14 <ayoung> Lets blow it off and go rock climbing in the Pyrenees 18:05:35 <dolphm> we know where to find ayoung on monday :) 18:05:42 <jamielennox> i cant' really rock climb, but sangria on the other hand... 18:05:48 <gagehugo> ^ 18:06:03 <dolphm> the biggest outstanding question regarding schedule that we have is whether we want to have a contributor meetup on *friday afternoon* -- it's the only available time slot 18:06:22 <dolphm> typically, a lot of people start flying out sometime after lunch on friday 18:06:31 <bknudson> jamielennox can hold the rope in one hand and sangria in the other. 18:06:34 <lbragstad> ++ 18:06:37 <knikolla> i'll probably leave friday morning, friday afternoon/evening flights were crazy expensive 18:06:45 <gagehugo> same 18:06:46 <dolphm> so this is basically a question for those of you that have already booked travel - will you be available and interested in having a contributor meetup on friday afternoon? 18:06:46 <lbragstad> they are useful if you can make it but it's always subject to travel plans :/ 18:06:49 <ayoung> bknudson, Sangria will go in a Camelback I think. 18:06:57 * breton will stay till Sunday 18:07:13 * rodrigods Monday to Friday 18:07:13 <shaleh> \o 18:07:22 <nishaYadav> o/ 18:07:30 * amakarov will stay for weekend 18:08:01 <samueldmq> dolphm: could Thursday night work? 18:08:12 <samueldmq> looks like everyone will still be there 18:08:29 <ayoung> samueldmq, hard to have a meetup over the sound of Flamenco Guitarres 18:08:35 <dolphm> samueldmq: this is our only wiggle room in the schedule 18:09:10 <dolphm> #callvote FOR THOSE OF YOU WHO HAVE ALREADY BOOKED TRAVEL, will you be available AND interested in a contributor meetup on Friday afternoon (say, 1-5pm)? Yes, No, I didn't read the question, I haven't booked travel, What is a contributor meetup again? 18:09:17 <dolphm> #startvote FOR THOSE OF YOU WHO HAVE ALREADY BOOKED TRAVEL, will you be available AND interested in a contributor meetup on Friday afternoon (say, 1-5pm)? Yes, No, I didn't read the question, I haven't booked travel, What is a contributor meetup again? 18:09:18 <openstack> Begin voting on: FOR THOSE OF YOU WHO HAVE ALREADY BOOKED TRAVEL, will you be available AND interested in a contributor meetup on Friday afternoon (say, 1-5pm)? Yes, No, I didn't read the question, I haven't booked travel, What is a contributor meetup again? Valid vote options are Yes, No. 18:09:19 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 18:09:43 <ayoung> ¡Olé! 18:09:52 <henrynash> #vote Yes 18:09:52 * dolphm has not booked travel so i'll abstain 18:09:52 <amakarov> #vote yes 18:09:59 <rderose> #vote yes 18:10:14 <lbragstad> I haven't booked so I'll abstain as well 18:10:14 * jamielennox will be around friday night regardless 18:10:14 <rderose> I haven't booked travel, but plan to 18:10:17 <ayoung> #vote I haven't booked travel 18:10:31 <samueldmq> #vote I haven't booked travel 18:10:36 <gagehugo> #vote I haven't booked travel 18:10:37 <lbragstad> dolphm when do we have to have an answer? 18:10:41 <ezpz> #vote I haven't booked travel 18:10:45 <henrynash> #vote I haven't booked travel 18:10:47 <dolphm> lbragstad: within a couple days, i think 18:10:57 <dolphm> lbragstad: we had time to take a vote here, and that was about it IIRC 18:11:03 <dolphm> maybe til end of week? 18:11:11 <dolphm> but it sounds like a yes so far 18:11:14 <knikolla> #vote no 18:11:23 <dstanek> #vote I haven't booked travel 18:11:25 <breton> #vote I didn't read the question, I haven't booked travel, What is a contributor meetup again? 18:11:32 <dolphm> #showvote 18:11:39 <lbragstad> i assume that if we commit to a meetup, we would get a room and stuff like that 18:11:46 <dolphm> lbragstad: yes 18:12:19 <dolphm> alright... 18:12:19 <ayoung> This trip is between my Wife's Birthday and Haloween, making it hard for me to extend on either end. 18:12:20 <dolphm> #endvote 18:12:21 <openstack> Voted on "FOR THOSE OF YOU WHO HAVE ALREADY BOOKED TRAVEL, will you be available AND interested in a contributor meetup on Friday afternoon (say, 1-5pm)? Yes, No, I didn't read the question, I haven't booked travel, What is a contributor meetup again?" Results are 18:12:28 <dolphm> haha 18:12:33 <henrynash> #vote Yes 18:12:44 <samueldmq> are the results showing up for you ? 18:12:52 <samueldmq> I can't see them ... is the bot broken? 18:13:10 <ayoung> dolphm killed the votebot dolphm killed the votebot 18:13:10 <breton> lol 18:13:14 <dolphm> samueldmq: the bot is holding us in anticipation 18:13:16 <knikolla> no results, but it looks like a yes 18:13:18 <gagehugo> lol 18:13:21 <dolphm> #showvote 18:13:23 <dolphm> #endvote 18:13:26 <dolphm> whatever, it's a yes 18:13:31 <dolphm> 3 vs 1 IIRC 18:13:40 <samueldmq> c'mmon openstack 18:13:41 <dolphm> now, everybody go book travel :) 18:13:42 <jaugustine> the suspense ! 18:13:43 <samueldmq> yes! 18:13:55 * lbragstad pats votebot on the shoulder 18:14:13 <dolphm> now onto more pressing matters... 18:14:16 <dolphm> #topic Release status 18:14:29 <dolphm> the gate has been rough lately, so please get things gating! 18:14:30 <dolphm> All feature work and high priority bugs should be approved or gating by friday, the gate is crazy backed up 18:14:56 <bknudson> gate backup started early this time. 18:15:33 <dolphm> if you're looking for something to review (and want to get a heads up on using our new rolling upgrades approach), review credential encryption... which has the most outstanding patch sets to be merged of the remaining bps: https://blueprints.launchpad.net/keystone/+spec/credential-encryption 18:16:04 <lbragstad> https://review.openstack.org/#/c/355618/14 is the most indepth review 18:16:11 <lbragstad> the rest are pretty trivial and documentation 18:16:20 <dolphm> #link https://review.openstack.org/#/c/355618/ 18:16:25 <dolphm> (removed the patchset from the link) 18:16:28 <lbragstad> i would be forever grateful for reviews on the database triggers 18:16:37 <lbragstad> dstanek thanks 18:16:50 <lbragstad> s/dstanek/dolphm/ 18:17:07 <dstanek> lbragstad: you're welcome anyway 18:17:07 <dolphm> the mapping_populate patch needs a nudge (last I looked, I +2'd, but the release notes needed a rev) 18:17:08 <dolphm> #link https://review.openstack.org/#/c/343028/ 18:17:40 <dolphm> and while lbragstad is pre-occupied knocking out credential encryption, we could use some hands to performance validate amakarov's patch 18:17:42 <dolphm> #link https://review.openstack.org/#/c/309146/ 18:18:04 <ayoung> I can 18:18:07 <dolphm> and then we have a nasty list of bugs 18:18:22 <ayoung> I'll look at both 18:18:27 <samueldmq> "The patch uses dogpile.cache internal functionality so some calls may look strange" 18:18:28 <samueldmq> lol 18:18:34 <henrynash> on triggers/rolling upgrade, also look at: https://review.openstack.org/#/c/357789/ 18:19:09 <dolphm> henrynash: ++ 18:19:14 <amakarov> samueldmq: say you like it )) 18:19:50 <dstanek> my cache invalidation patch could use some eyes too 18:19:57 <dolphm> #topic steve's list of big bad hairy bugs 18:19:58 <dstanek> #link https://review.openstack.org/349704 Distributed cache namespace to invalidate regions 18:20:13 <dolphm> ^^ 18:20:26 <dolphm> definitely the nastiest, widest impact bug we have right now 18:22:12 <dolphm> and then henry's rolling upgrade fix is on steve's list 18:22:17 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1596500 18:22:17 <openstack> Launchpad bug 1596500 in OpenStack Identity (keystone) "Passwords created_at attribute could remain unset during rolling upgrade" [High,In progress] - Assigned to Henry Nash (henry-nash) 18:22:30 <dolphm> there's some good background there before you dive into the code review 18:22:32 <dolphm> which uses rolling upgrades :) 18:22:41 <amakarov> if for some reason dstanek's patch won't go, here is the old way approach: https://review.openstack.org/#/c/354831/ 18:23:20 <dolphm> rderose got another major bug fixed in https://bugs.launchpad.net/bugs/1615000 (thanks!) 18:23:20 <openstack> Launchpad bug 1615000 in OpenStack Identity (keystone) "Entry to User table creates entries in local_user table for ldap and custom driver users" [High,Fix released] - Assigned to Ron De Rose (ronald-de-rose) 18:23:42 <samueldmq> rderose: nice! 18:23:55 <dolphm> and then, if you're looking for something to work on -- we still have a couple that need to be investigated & debugged further 18:23:59 <dolphm> #link https://launchpad.net/keystone/+milestone/newton-3 18:24:10 <rderose> samueldmq dolphm: thank you :) 18:24:15 <dolphm> they all seem related, but again, the impact could be substantial, so the more eyes the better 18:25:07 <dolphm> has anyone kept up with bugs opened recently? 18:25:32 <lbragstad> I have not :( 18:25:34 <rodrigods> dolphm, latest one i remember was the credential type 18:25:42 <rodrigods> fix was approved already 18:25:54 <lbragstad> fwiw - here is our weekly report - http://openstack-weekly-reports.lbragstad.com/keystone-weekly-bug-report.html 18:26:15 <samueldmq> lbragstad: ++ 18:26:59 <dolphm> i'm going to pick up the fernet key one - that's something i poked at recently anyway 18:27:39 <dolphm> #topic Outreachy program in Keystone ends today 18:27:43 <dolphm> samueldmq: nishaYadav: o/ 18:27:47 <dolphm> floor is yours 18:27:49 <samueldmq> hey 18:27:57 <nishaYadav> hey :) 18:28:01 <samueldmq> so, nishaYadav has been working with us in the last couple of months 18:28:12 <rodrigods> really good work by nishaYadav and samueldmq 18:28:16 <samueldmq> we were participating of the Outreachy round (which ends today) 18:28:17 <rodrigods> congrats 18:28:33 <nishaYadav> thanks rodrigods 18:28:35 <samueldmq> nishaYadav has implemented functional tests in ksclient, now most of v3 managers have tests 18:28:39 <samueldmq> rodrigods: thx 18:28:40 <breton> samueldmq: interesting, GSoC ends today too 18:28:55 <samueldmq> besides the tests, nisha has improved the docs too! 18:29:08 <samueldmq> it's been >30 patches merged! 18:29:15 <dolphm> nishaYadav: your patches were a pleasure to review (and approve!) 18:29:25 <nishaYadav> breton, yeah that's right outreachy and GSoc run in parallel :) 18:29:27 <bknudson> great work. It'll be running multiple times a day keeping keystone working. 18:29:31 <samueldmq> I just would like to tell everyone the round was succcessful for keystone 18:29:37 <dstanek> that's great. looks like a success for keystone then! 18:29:38 <samueldmq> and thanks nishaYadav for her awesome work 18:29:55 <rderose> nishaYadav: thank you! 18:29:55 <lbragstad> ++ 18:29:59 <dstanek> nishaYadav: thanks! 18:30:09 <anteaya> nice work, nishaYadav 18:30:22 <gagehugo> thanks nishaYadav! 18:30:23 <rodrigods> keep contributing nishaYadav ! 18:30:28 <gagehugo> ^ 18:30:33 <nishaYadav> thanks samueldmq for bringing this up in the meeting :) 18:30:42 <samueldmq> thanks to everyone who helped me mentoring her .. and reviewing her work 18:30:55 <dolphm> #info Thank you for all your awesome work, Nisha Yadav! 18:30:56 <nishaYadav> I am glad I worked on this project. 18:31:19 <dolphm> there, now it'll be buried in your google results somewhere :) 18:31:22 <nishaYadav> dolphm, rderose anteaya gagehugo rodrigods thanks a lot 18:31:38 <ayoung> ++ 18:31:42 <ayoung> well done 18:31:50 <dolphm> #topic Open discussion 18:31:59 <anteaya> o/ 18:32:06 <dolphm> that's all on the official agenda - anyone have anything else for today? 18:32:10 <anteaya> o/ 18:32:15 <ayoung> So...got one 18:32:16 <nishaYadav> rodrigods, can't thank you enought :D 18:32:23 <anteaya> <-- has an item 18:32:28 <breton> what do you think about storing quota in keystone? 18:32:37 <ayoung> breton, nope 18:32:41 <ayoung> breton, has come up many times 18:32:47 <ayoung> it is not the right place for it 18:32:54 <ayoung> everytime, we've gone around the same race track 18:32:58 <amakarov> ayoung: separate service? 18:33:00 <dstanek> breton: if it's not identity related we shouldn't we involved 18:33:18 <ayoung> the quotas are service specific items. They don't have enough commonality 18:33:21 <amakarov> dstanek: it's project related ( 18:33:26 <ayoung> you need a way todistribute them 18:33:27 <dolphm> breton: i'd love to see a centralized quota management service, and it could be under the identity umbrella, but i don't think keystone itself is the right service 18:33:36 <nishaYadav> I plan on keep contributing and hopefully meet you all in the upcoming OpenStack summit :) 18:33:45 <dolphm> it's an authorization problem, which is our wheelhouse 18:33:58 <dstanek> amakarov: it's not though. it's maybe a 'foreign key' to a project with serivce specific meaning 18:34:04 <ayoung> Its a billing problem 18:34:24 <dolphm> ayoung: turns out we own the tenants :P i mean projects 18:34:45 <samueldmq> nishaYadav: ++ 18:34:49 <amakarov> dolphm: ++ 18:35:04 <ayoung> Does that make us slumlords? 18:35:20 <dolphm> ayoung: .. yes. 18:35:23 <ayoung> Heh 18:35:39 <amakarov> ayoung: helllords! 18:35:51 <ayoung> OK, so lets discuss at the summit. If we do centralized quota, we need to decide what that means 18:35:58 <breton> agreed 18:36:02 <dolphm> i think it's a complicated, valuable problem with it's own scaling concerns, so it makes sense to me to have it as a standalone service 18:36:09 <dolphm> it's also something i wish someone had built 5 years ago 18:36:29 <shaleh> dolphm: ++ to all of that 18:37:09 <dolphm> anteaya: don't hold back, it's an open floor 18:37:12 <ayoung> OK...I have one, if we are done with that 18:37:16 <dolphm> ayoung: sure 18:37:26 <anteaya> we discussed meetbot in infra 18:37:31 <ayoung> Spec to ignore expiry and revocation on token validation 18:37:33 <dolphm> anteaya: about me breaking it? 18:37:42 <anteaya> it seems that it doesn't like two spaces when expecting one 18:37:47 <anteaya> also it is case sensitive 18:37:55 <ayoung> It would be an incremental step toward what jamielennox was proposing at the midcycle 18:37:57 <anteaya> it didn't feel it got any vote information 18:38:12 <anteaya> we are discussing making it case insensitive in -infra 18:38:12 <ayoung> https://review.openstack.org/#/c/358131/ 18:38:20 <anteaya> feel free to share your thoughts 18:38:22 <anteaya> thank you 18:38:27 <anteaya> EOF 18:38:29 <dolphm> did i double space something? 18:38:42 <anteaya> someone did 18:38:42 <ayoung> the gist is this: 18:38:48 <jamielennox> ayoung: oh - i still was intending to do that, i just had too much on directly after the midcycle to get it done for this release 18:38:50 <anteaya> the only case correct vote 18:39:01 <jamielennox> ayoung: was still planning on it for early next cycle 18:39:16 <ayoung> we would allow, say, glance, to validate the user's token passed along with the service token, but ignore the expiry or revoke status, 18:39:19 <anteaya> the options were Yes and No, most folks used all lover case 18:39:19 <notmorgan> o/ ish 18:39:29 <jamielennox> ayoung: turns out the auth_token middleware is the hard bit, just because of the framework that's built there 18:39:31 <ayoung> so if Nova called Glance, we would have the mechanism 18:39:34 <ayoung> jamielennox, yep 18:39:43 <dolphm> anteaya: ah, i do wish the vote responses were case insensitive, or numbered? (which might also require a direct reply to show you what option you selected) 18:39:54 <breton> can we just sign requests from Nova to Glance? We already have x.509 authn in place 18:39:55 <ayoung> jamielennox, one thing I was thinking was we could first get this part working, and then optimize with bulk token validations. Bulk meaning two here 18:40:05 <anteaya> well it appears that making it case insensitive is on the table 18:40:12 <anteaya> do speak up in -infra 18:40:38 <ayoung> jamielennox, I thought we already had a mechanism to account for service tokens? 18:40:47 <anteaya> but that was why there were no results 18:41:04 <jamielennox> ayoung: we do, but it's just treated as a seperate validation request 18:41:19 <ayoung> breton, so...even if we did, glance still needs to validate that the user has perms to do what nova is asking on behalf of the user 18:41:28 <jamielennox> ayoung: just the way auth_token is setup, and keystone relies on it being set up, there's no way to pass through multiple tokens at once 18:41:29 <ayoung> jamielennox, I think that is fine to start, then 18:41:49 <jamielennox> ayoung: but that should be just some delicate code reshuffling 18:41:52 <dolphm> did we have an argument / alternative to the "Return expired tokens within a grace period" option? 18:42:00 <dolphm> #link https://review.openstack.org/#/c/345092/ 18:42:16 <ayoung> we use service token for Nova, and pass the token as per normal, and glance needs the config to say "validate both, but on user pass this flag." 18:42:37 <dolphm> ayoung: the flag being "ignore expiration on this second token?" 18:42:51 <breton> ayoung: what if we sign a token and skip revocation for the token if it is signed 18:43:05 <ayoung> dolphm, this is essentially the spec for that, but didn't realize we had a review 18:43:16 <dolphm> i didn't realize there was a spec 18:43:17 <ayoung> breton, ++ that is part of it 18:43:56 <jamielennox> dolphm: i had some code i was messing with, but its not up as i wasn't going to get it finished this cycle 18:43:56 <ayoung> dolphm, I think there is a need for an API change, which is why I posted the spec 18:44:20 <ayoung> anyway, pleae hack on the spec, and make the APi code sane. 18:44:23 <jamielennox> the code is pretty easy really, just needs a few different pieces in place 18:44:36 <ayoung> jamielennox, skipping revocation, too, please 18:44:47 <lbragstad> henrynash still around? 18:44:48 <ayoung> deal with the Horizon-log-out problem 18:44:51 <jamielennox> i didn't change that 18:44:56 <henrynash> lbragstad: hi 18:45:04 <ayoung> dolphm, yes, that is the flag. 18:45:09 <jamielennox> i wouldn't have thought we would skip revocation 18:45:18 <ayoung> jamielennox, yeah, I think we need to. 18:45:21 <lbragstad> henrynash dolphm and I were poking at an issue I was having when writing tests for the credential encryption migration 18:45:32 <lbragstad> henrynash wonder if you happen to see this at all? http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2016-08-22.log.html#t2016-08-22T17:49:58 18:45:39 <lbragstad> wondering* 18:45:50 <dolphm> this thread also popped up on the mailing list, but hasn't gotten any love from us yet (there's no [keystone] in the subject line, so i'm assuming a lot of people missed it) 18:45:59 <dolphm> #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/102012.html [openstack-dev] Mitaka: Identity V3 status and observations using domains 18:46:02 <ayoung> jamielennox, if the project or role is revoked, the token should just not show those roles assigned, but an explicit revocation should be ignored, I think. 18:46:10 <notmorgan> jamielennox: we do need to skip revocation because horizon logout is an explicit revoke 18:46:21 <henrynash> lbragstad: so we do run the previous (legacy) migration first... 18:46:24 <notmorgan> which would cause things to fail 18:46:38 <lbragstad> henrynash interesting... 18:46:39 <dolphm> henrynash: but that test suite does not 18:47:00 <lbragstad> henrynash when it gets into my migration that does things to the credential table - it doesn't think it exists 18:47:18 <henrynash> lbragstad: ...at least that was my attempt...in fact, if we didn;t then my patch would also fail (since I refer to the password table)....and this DID fail until I added the code to first migrate the legacy repo 18:47:22 <lbragstad> which wouldn't necessarily be caught because the 001 migration is a noop 18:47:22 <notmorgan> dolphm: i didn't even read that thread because no [<tag>] (emails without a tag get filtered out of my inbox completly 18:47:31 <dolphm> notmorgan: i figured 18:48:01 <lbragstad> henrynash did you add the code to migrate the legacy repo in your password migration patch? 18:48:06 <lbragstad> henrynash or is that somewhere else? 18:48:16 <henrynash> lbragstad: look at https://review.openstack.org/#/c/357789/ ...it would fail if we didn't run the legacy migration first 18:48:18 <lbragstad> henrynash because I'll need to probably rebase my work on taht too 18:49:57 <henrynash> lbragstad: nope it's alreayd in master...see lines 1532/33 of test_sql_upgrade 18:50:16 * dolphm is looking to end the meeting early ... 18:50:25 <lbragstad> henrynash ah - the setUp of SqlExpandSchemaUpgradeTests 18:50:40 <henrynash> as an aside, you should do self.upgrade(self.max_version) in your test, but you should do self.upgrade(2) 18:50:50 <dolphm> lbragstad: henrynash: it's not a broad topic, so take it back to #openstack-keystone :) 18:50:52 <dolphm> #endmeeting