17:01:42 #startmeeting keystone-office-hours 17:01:43 Meeting started Tue Apr 3 17:01:42 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:46 The meeting name has been set to 'keystone_office_hours' 17:03:00 just fyi - i have a few meetings to be in the next couple hours, but i'll try and check in here/multitask 17:12:51 for those who are familiar with ldap - i took a shot at documenting some how-tos for ldap backed development environments https://review.openstack.org/#/c/557997/ 17:16:15 looks great lbragstad 17:32:24 * gagehugo steps out for lunch 17:40:46 eandersson: thanks for looking :) 18:36:08 hello 18:36:31 doc/keystone-install-ubuntu.rst says: 18:36:42 "Before the Queens release, keystone needed to be run on two separate ports to 18:36:42 accomodate the Identity v2 API which ran a separate admin-only service 18:36:42 commonly on port 35357. With the removal of the v2 API, keystone can be run 18:36:42 on the same port for all interfaces." 18:37:21 does that mean the glance installation instructions that refer to "auth_url=http://controller:35357" should be modified to refer to :5000? 18:37:42 in other words, there is a discrepancy between the two installation documents 18:57:10 tmcm: yeah - that's likely the case 19:13:14 so, we SHOULD or SHOULD NOT use the admin wsgi in queens? 19:16:26 on ubuntu specifically 20:06:04 using the ldap driver, is there a way to have it fallback to sql for e.g., the service users like glance, neutron, etc? 20:13:23 tmcm: you can have different drivers for different domains 20:13:24 https://docs.openstack.org/keystone/latest/admin/identity-domain-specific-config.html 20:43:32 tmcm: it is also recommended that keystone be run on HTTP[S] instead of port 5000 or 35357. 20:43:51 standard HTTP[S] ports* 20:52:29 kmalloc: another bootstrap question for you 20:52:37 yeah 20:53:09 the argument parser for bootstrap has defaults, but if i want to pull the bootstrap logic out into it's own class so that it's easier to hook into the tests, should the defaults move with it? 20:53:23 i'd say no 20:53:34 so - keep the new object really generic 20:53:37 yeah 20:53:39 and unopinionated 20:53:48 mostly because bootstrap is opinionated to get an install running 20:53:56 tests do not adhere to those concepts 20:54:07 don't do acrobatics to make the test look like you want it to 20:54:53 tests should be explicit - and defaults can be bundled into the same mechanism we use to do the setup vs. encoding "real world standup" defaults into the core object 20:55:08 s/same// 20:55:27 fwiw, i've learned a lot about SR-IOV today 20:55:43 it's cool tech, it's a bit weird how it's implemented. 20:56:38 hmm - ok, i think i can make that work 22:53:25 #endmeeting 12:32:57 lbragstad: so i did a comparison of the tokens issued before and after explicitly adding that federated user into the relevant group 12:33:13 they both contain the right group and project 12:33:24 yankcrime: hmm 12:33:27 however, when it fails i do see: 12:33:29 {"error": {"message": "Could not find token 12:34:00 and 2018-04-04 10:20:54.373 18 DEBUG keystone.token.provider [req-720a8b5d-8686-4b56-89b5-7ab2f5900a8f - - - - -] Unable to validate token: User 4d1c38716d394e6097cf20d050f9d81e has no access to project 90fb2e3278344060a4b29008c30f1bc2 12:34:13 that's basically the first bit in the log where it starts to go awry 12:34:49 hmm 12:35:00 which token provider are you using? 12:35:16 uuid 12:36:00 oh - i have a bug report for you 12:36:32 https://bugs.launchpad.net/keystone/+bug/1758460 12:36:33 Launchpad bug 1758460 in OpenStack Identity (keystone) "UUID (or any persistent) token providers unable to validate federation token" [Low,New] 12:36:58 yankcrime: are you able to switch to fernet and test with that? 12:37:42 damn, that looks exactly like it - i'd started to trawl the various bugs on launchpad but missed that one! 12:38:11 yeah, it needs doing anyway so i'll press on with switching to fernet first 12:38:39 yankcrime: let me know if you have any questions about fernet 12:38:53 i can help 12:39:43 lbragstad: thanks, much appreciated - been banging my head against a brick wall with this one for a couple of days now, good to know it's not me that's directly at fault ;) 12:40:02 yeah.. it was just reported not too long ago 12:40:06 and no worries, i should be ok - i have other deployments already on fernet 12:40:52 but uuid support has been waning 12:41:25 yup, surprised this particular instance was built with uuid tbh - probably an oversight 12:41:45 i was just about ask if there was a particular reason it was being used 12:52:17 this particular instance was deployed via kolla-ansible which still defaults to uuid 12:55:52 ahh - gotcha 13:01:44 https://review.openstack.org/#/c/549861/ fwiw 14:39:40 o/ 15:03:18 o/ 15:07:21 o/ 15:17:05 Gage Hugo proposed openstack/keystone master: Fix mispelling of accommodate in install docs https://review.openstack.org/558849 15:17:15 easy change ^ 15:30:36 Harry Rybacki proposed openstack/keystone master: Update install guides https://review.openstack.org/558079 15:43:57 Harry Rybacki proposed openstack/keystone master: Update install guides https://review.openstack.org/558079 16:31:02 woops, forgot about policy meeting - I don't have rights on that project, looks like that honor belongs to these people https://review.openstack.org/#/admin/groups/1372,members 16:32:21 oh - interesting 16:33:53 there were a bunch of people in the session in dublin 16:34:09 and i remember smcginnis being interested in it from a TC perspective 16:34:34 i might do a drive by in the TC room just to see if it jars anyone's attention 18:10:02 I think this looks better lbragstad https://review.openstack.org/#/c/523973/ 18:10:13 cool - i'll take another pass 18:33:42 Merged openstack/keystone master: Fix mispelling of accommodate in install docs https://review.openstack.org/558849 18:34:27 Merged openstack/keystone master: Update install guides https://review.openstack.org/558079 18:50:34 Gage Hugo proposed openstack/keystone master: Add functional testing gate https://review.openstack.org/531014 19:05:58 Merged openstack/keystonemiddleware master: Remove kwargs_to_fetch_token https://review.openstack.org/513273 19:07:55 Gage Hugo proposed openstack/keystone master: Move fernet doctor checks into tokens checks https://review.openstack.org/527527 19:09:00 Gage Hugo proposed openstack/keystone master: Move fernet doctor checks into tokens checks https://review.openstack.org/527527 19:22:42 Lance Bragstad proposed openstack/keystone master: Decouple bootstrap from cli module https://review.openstack.org/558903 19:22:51 kmalloc: just got done beating my head against ^ 19:23:26 that was a fun scenic detour 19:23:43 i should be able to get a patch up that bases the testing of the new keystone token model on that 19:24:21 lbragstad that rips bootstrap out into it's own thing? 19:24:27 yeah 19:24:51 interesting 19:27:33 yeah - i've been in the middle of a couple refactors where i need testing taht just gives me a base model to work from 19:27:45 base model = admin user, project, system role assignments, default domain, etc... 19:27:55 and bootstrap was written to do that for operators 19:28:01 so i figured it might be useful to reuse for testing 19:28:16 but the dependency injection stuff was kind of a pain for figure out 19:32:10 s/for/to/ 19:56:40 hrybacki: took another pass 19:56:52 just a few nits, otherwise i feel comfortable +1'ing it 20:33:17 Gage Hugo proposed openstack/keystone master: Add new config option and setup for token keys https://review.openstack.org/558918 21:37:55 Gage Hugo proposed openstack/keystone master: WIP - Add LDAP-backed functional testing gate https://review.openstack.org/558940 21:39:35 Gage Hugo proposed openstack/keystone master: Add new config option and setup for token keys https://review.openstack.org/558918 22:54:03 Gage Hugo proposed openstack/keystone master: WIP - Add LDAP-backed functional testing gate https://review.openstack.org/558940 04:07:38 Lance Bragstad proposed openstack/keystone master: Decouple bootstrap from cli module https://review.openstack.org/558903 07:41:26 do we have support in keystone to add periodic tasks? like we do have support in nova & other components 11:59:47 o/ 12:58:44 o/ 13:00:21 mornin' 14:01:21 A 14:02:46 hello, is it possible to specity a port when enabling ldap backend? 14:03:07 I have ldap running behind haproxy and is running a different port than the default ones 14:05:54 root_743: i think it should just be part of the url 14:06:07 Merged openstack/keystone master: Expose a bug that list_limit doesn't work correctly https://review.openstack.org/558150 14:06:10 Merged openstack/keystone master: Fix list_limit doesn't work correctly for domain https://review.openstack.org/558151 14:06:26 cmurphy: thanks 14:31:32 thanks lbragstad -- got some really good comments from Mel too! Misconceptions still exist :( system scope == global/god mode 14:31:45 !=* 14:31:46 oh - nice! 14:31:47 hrybacki: Error: "=*" is not a valid command. 14:32:00 heh openstack 14:32:10 I just wanted a kiss, jeez 14:32:29 lol 15:28:29 lbragstad, cmurphy: so - if someone wants to get the complete version discovery picuture for a given cloud, they basically have to do this: http://paste.openstack.org/show/718491 15:28:50 which uses a private method - and is also a bit yuck 15:29:56 I'm going to poke at some options for exposing something a little better ... 15:31:02 oh - sure 15:31:06 that's handy 15:31:46 mordred: fun 15:33:20 I also need to finish the work on getting os-service-types integrated - so fair warning - there may be some keystoneauth patches coming from me :) 15:34:02 my favorite 15:37:56 cmurphy: I know how much you enjoy them 15:38:00 that'd make a good doc contribution 15:40:15 ++ 16:11:59 Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 16:12:00 Colleen Murphy proposed openstack/keystoneauth master: Fix lower-constraints dependencies https://review.openstack.org/559118 16:12:14 crap, i only meant to submit one of those 16:14:27 heh 16:38:49 Monty Taylor proposed openstack/keystoneauth master: Expose version status in EndpointData https://review.openstack.org/559125 16:39:03 cmurphy, lbragstad: ^^ there's step one 16:51:08 cmurphy, lbragstad: OOH. I may suck a little bit - it looks like we have a method that may do mostof this already \o/ 16:53:36 Lance Bragstad proposed openstack/keystone master: Introduce new TokenModel object https://review.openstack.org/559129 16:54:03 kmalloc: ^ i'm hitting a couple transients with dependency inject :( but that's what i have so far 17:03:10 lbragstad, cmurphy: http://paste.openstack.org/show/718507/ and http://paste.openstack.org/show/718508/ (with that first ksa patch applied) 17:29:51 mordred: wow - nice 18:10:36 lbragstad: cool, will looks shortly 18:15:33 Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 18:19:19 mordred: hey ksa's queens branch is still borked http://logs.openstack.org/84/543684/1/check/openstacksdk-functional-devstack-tips/5c38f3a/job-output.txt.gz#_2018-04-04_16_55_29_473944 do you know why? 19:13:11 cmurphy: the revision_number is different: http://logs.openstack.org/84/543684/1/check/openstacksdk-functional-devstack-tips/5c38f3a/job-output.txt.gz#_2018-04-04_16_55_29_476576 19:14:52 cmurphy: I think that's something we fixed already in master branch of sdk ... https://review.openstack.org/#/c/544995/ 19:15:02 cmurphy: I think we just need to cherry-pick back to queens 19:15:24 cmurphy: https://review.openstack.org/#/c/559150/ 19:15:31 cmurphy: cherry-pick submitted 19:18:54 Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data https://review.openstack.org/559154 19:31:52 lbragstad, kmalloc, cmurphy: ^^ that needs tests, but it works against vexxhost public cloud - I've pushed it up for any initial feedback before I go writing unittests 19:32:10 there's also some scrollback discussing it a little bit in #openstack-sdks 19:32:17 cool - checking 20:53:29 even with the uuid provide and sql driver gone, refactoring the token provider api is going to be difficult 20:53:46 provider* 21:09:04 yeah... 21:11:54 i've tried slicing this refactor up about 3 different ways 21:12:19 and 60% of the time, it's messy 100% of the time 21:43:30 heh 06:07:02 Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build https://review.openstack.org/555196 08:05:38 Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 11:24:43 Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data https://review.openstack.org/559154 11:25:11 cmurphy: ^^ that should be ready for review now - and I even added tests 11:25:52 mordred: fantastic 11:35:01 Doug Hellmann proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 12:21:09 ö/ 12:37:39 fried_rice: Hi 12:37:48 Hello 12:38:10 i want dicuss with you regarding keystoneauth session 12:39:41 pooja_jadhav: Is this in reference to https://review.openstack.org/#/c/505764/ ? 12:40:01 correct 12:40:18 Okay. I remember seeing that go by, but I didn't actually review it. 12:40:32 Let's just heads-up the folks who did, cause they're more likely to be able to help... 12:40:51 kmalloc, cmurphy, mordred, cdent 12:40:59 pooja_jadhav: Okay, proceed with your question please :) 12:41:15 fried_rice: Actually, i want use that split logger parameter in nova while call is going to cinder client.[1]https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L77 12:42:23 but how to use not getting still 12:42:39 :( 12:44:12 pooja_jadhav: Okay, I'm reading over that patch, stand by... 12:44:34 fried_rice: Sure 12:48:25 pooja_jadhav: Okay, it looks to me like there's no way to do this via ksa loading. 12:49:47 fried_rice: Yeah, but if we want to do.. then how can we do then? 12:50:32 pooja_jadhav: If you want to try it out just to see if it will work the way you want it to, you can add: 12:50:33 _SESSION._split_loggers = True 12:50:33 after https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L82 12:51:16 ohk.. i will try and let u know 12:52:03 pooja_jadhav: That's not going to be a real solution. But if it does what you want, you could probably submit a patch to openstack/keystone to expose that via a conf option. 12:52:31 pooja_jadhav: Then you wouldn't need to do anything to the nova code - you could just add the option in your conf file and restart the service. 12:56:45 ok 13:02:42 Doug Hellmann proposed openstack/ldappool master: add lower-constraints job https://review.openstack.org/555757 13:20:40 Merged openstack/ldappool master: add lower-constraints job https://review.openstack.org/555757 13:36:40 Merged openstack/keystone master: Removal of deprecated direct driver loading https://review.openstack.org/350815 13:36:55 Nguyen Hai proposed openstack/keystone master: Fix incompatible requirement in lower-constraints https://review.openstack.org/559334 13:38:22 Nguyen Hai proposed openstack/keystone master: Fix incompatible requirement in lower-constraints https://review.openstack.org/559334 13:43:41 Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 13:49:14 Merged openstack/keystonemiddleware master: Update links in README https://review.openstack.org/557189 14:23:07 cmurphy: an application credential token can't be used to change a user's password can it? 14:25:53 lbragstad: it could if it has the user's original password https://developer.openstack.org/api-ref/identity/v3/index.html#change-password-for-user 14:26:28 ahh 14:26:32 ok - nevermind 14:26:56 :) 14:27:01 i thought i remember a restriction in there somewhere that might help with https://bugs.launchpad.net/keystone/+bug/1755874/ 14:27:02 Launchpad bug 1755874 in OpenStack Identity (keystone) "Ability to block users from changing passwords is missing in Kesystone v3" [Undecided,In progress] - Assigned to Pavlo Shchelokovskyy (pshchelo) 14:27:27 i just read the use case they described... 14:29:12 yeah we didn't any restrictions on that for app creds 14:29:58 having a policy that users can't change their own passwords seems really weird and anti-security to me but i guess it's a real world use case we should allow 14:30:31 mhmm 14:31:37 unless there is a different workflow we can support somehow that doesn't require us to open that back up 14:32:20 we can enforce password strength 14:32:47 yeah 14:33:02 that seems like the main thing they want 14:33:09 sounds like the layer that sits on top of keystone does that too 14:33:24 but i assume that's been around for a while if they implemented that for v2.0 14:34:14 so - sure... some system creates a new user for some set of operations and a user *could* change the password directly using keystone 14:34:45 but it won't buy them much because keystone can be configured to match the same password strength requirements that the layer on top of keystone requires? 14:35:37 Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build https://review.openstack.org/555196 14:36:13 auditability i guess, if they're tracking password changes through this other layer and don't want to track them through keystone 14:37:26 that could be true 14:38:41 sounds like they have a system in place and we broke them, so we could either enable the change that unbreaks their system or we could encourage them to use our system 14:38:44 ¯\_(ツ)_/¯ 14:39:27 sure - i'll leave a comment 14:40:02 Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data https://review.openstack.org/559154 14:41:36 lbragstad: fyi i'll be on vacation all next week and hopefully not looking at my computer 14:41:49 cmurphy: ack - thanks for the heads up 14:41:53 cmurphy: i'm jealous ;) 14:42:09 doing anything fun? 14:43:36 meeting up with some friends to go camping in Iceland :D 14:44:08 oh... wow 14:44:25 * lbragstad gives cmurphy his camera 14:44:30 please take some pictures 14:44:38 i plan to 14:44:40 s/some/lots of/ 14:44:45 :) 14:44:47 that's going to be amazing 14:45:12 also - pretty hard to get onto irc while camping 15:03:16 cmurphy: have fun! 15:09:45 Matthew Thode proposed openstack/keystone master: Fix incompatible requirement in lower-constraints https://review.openstack.org/559334 15:09:45 Matthew Thode proposed openstack/keystone master: Use the new pysaml2 constraints https://review.openstack.org/558217 15:23:07 Nguyen Hai proposed openstack/keystone master: Follow the new PTI for document build https://review.openstack.org/555196 15:55:47 o/ 16:24:36 lbragstad, cmurphy: so... there is a minor issue to fix the password-change API blocking bit 16:24:51 and it is because @protected is wonky 16:25:02 * lbragstad dreads that refactor too 16:26:05 the most immediate mechanism to block in that bug is use ninx/apache and put a block rule into http[s]://identity/v3/users/*/password 16:37:58 lbragstad: oh man, i know how to fix the bug w/o code on our end 16:38:05 we have minimum password change times. 16:38:44 oh! 16:38:57 right?! 16:39:06 * lbragstad checks the implementation 16:39:12 yeah i am looking at that now 16:39:39 oh. 16:39:46 maybe we don't have that 16:39:51 we might need to add that. 16:40:48 yeah... 16:41:00 we have unique last pass count 16:41:56 lets just add minimum password change time 16:42:19 rather than implement policy due to issues with @protected 16:42:24 until that refactor lands 16:42:36 what's the status of that refactor? 16:42:43 i haven't had a chance to dig into it yet 16:43:01 ... i don't know what the status is 16:43:18 oh - no worries, i was just curious 16:43:48 i've buried myself in the token provider refactor, but i think i need a break from that for a while 16:44:46 i don't think much yeah 16:44:52 s/don't think much 16:44:57 annnnyway 16:45:05 i don't think much has been done on the refactor 16:45:16 i can try and dig in some, but, it's a beast of a refactor 16:45:29 the issue is that it touches soooooo very much 16:45:40 yeah :( 16:45:57 let me start my NAS [old] -> NAS [new] 16:46:01 transfer 16:46:08 need to move ~4TB today 16:46:14 and i'll start poking at the refactor 16:47:18 sweet 16:47:37 the refactors we have on our plate this release are _massive_ 16:48:08 yeah 16:48:12 i started breaking the "rewrite keystone" patch into a series 16:48:16 but it's all VERY good stuff that makes keystnoe better 16:48:18 i failed, like 4 times 16:48:24 honestly, i want to re-write a ton of keystone. 16:48:41 once we break @protected, the flask re-write will be easy 16:49:06 yesterday i pulled the entire new model into a separate change, which is cool.. but then i attempted to remove the KeystoneToken model 16:49:22 so s/KeystoneToken/TokenModel/ everywhere in keystone 16:50:01 and then went over like a kicking a hornets nest 16:50:35 the problem is that we need to validate the token, then we pass it to the KeystoneTOken model to get an object 16:50:44 but with the new model, we use composition 16:50:47 right 16:51:09 so - we validate the token and then handpick values to build a token model using TokenModel? 16:51:22 which just defeats the purpose 16:51:31 well, we know what the values from the fernet payload mean 16:51:42 and we should be able to do composition with a "hey this is issued" 16:51:55 vs "this is new" 16:52:01 composition should work the same 16:52:05 oh - yeah.. that'd mean building the model generation into the validation path right? 16:52:06 it's a big change to the internals 16:52:08 yeah 16:52:14 right.. i didn't do that 16:52:19 but that is the way to do it and how we discussed it 16:52:39 all i did was introduce the new model and attempt to replace all usage of the old model with the new one 16:52:42 which kinda backfired 16:52:44 yeah 16:52:47 and it got really messy 16:52:57 i think we need to wait until validate_token returns an instance of TokenModel 16:53:00 if anything do it inverse, compose validation 1st 16:53:04 THEN everything else 16:53:15 instead of making all the different places in keystone do composition on blank token models 16:53:23 ++ 16:53:24 yeah 16:53:30 i think that's what i learned yesterday 16:53:35 and maybe just make a wrapper interface for the tokenmodel (new) 16:53:43 so we can interface the token the same way elsewhere 16:53:46 then drop the interface 16:54:15 it's transitional code, but it would make it easy 16:54:29 ok - so what if i do this 16:54:32 and we can just drop the magic methods to see what all still references the old style 16:54:36 1.) propose the new token model 16:54:54 2.) rework the authentication API to construct token models and whatnot 16:55:07 3.) rework the validation path to construct token models 16:55:11 1a. implement interface for tokenmodel to work like current dict-model. 16:55:23 how do you do that? 16:55:27 basically some magic __getitem__ __setitem__ 16:55:34 one model accepts a dictionary and the other doesn't accept anything? 16:55:44 s/?// 16:56:06 just implement __getitem__ __setitem__ that knows the token dict format 16:56:09 kt = token_model.KeystoneToken(token_data=token_data) 16:56:09 and sets the values 16:56:22 mmm 16:56:23 then you can just use the KeystoneToken directly 16:56:29 everywhere 16:56:33 simple search/replace 16:56:36 then rework bits to compose 16:56:39 and direct access 16:56:47 so - under the hood KeystoneToken proxies to TokenModel? 16:56:51 no 16:57:08 implement on KeystoneToken __getitem__ that knows what the format should be 16:57:15 its the dict magic get method 16:57:52 so KeystoneToken()['user'] etc returns dicts of the keystonetoken values 16:58:07 and KeystoneToken()['user']['id' 16:58:11 and KeystoneToken()['user']['id'] = XXXXX 16:58:15 would set the ritght thin 16:58:26 now that i think about it 16:58:31 might be a massive amount of work 16:58:35 yeah 16:58:39 that's how i have things now 16:58:40 maybe just a .to_dict() 16:58:42 with the new model 16:58:49 or _to_dict() 16:58:56 it all @property methods 16:59:05 and just render a token from the @propertys 16:59:24 so keystonetoken.to_dict()[ since we already need the code to render the dicts 16:59:49 for controller bits 17:00:01 for exmple - https://review.openstack.org/#/c/555931/1/keystone/models/token_model.py@869 17:00:35 eh, i think your proposed steps work fine 17:00:44 so 17:00:47 1.) introduce new model 17:00:56 2.) make authentication path use new model 17:01:03 3.) make validation path use new model 17:01:15 yep 17:01:36 4.) convert instances of KeystoneToken to use TokenModel (which is returned from PROVIDERS.token_provider_api.validate_token(token_id)) 17:01:55 5.) remove duplicate model 17:02:04 yep 17:02:13 6.) profit 17:02:29 because everyone loves a good refactor, amiright? 17:12:42 ok - i'm going to step away for lunch quick 17:18:21 Matthew Thode proposed openstack/keystone master: Fix incompatible requirement in lower-constraints https://review.openstack.org/559334 17:18:22 Matthew Thode proposed openstack/keystone master: Use the new pysaml2 constraints https://review.openstack.org/558217 17:22:43 lbragstad: i'll propose the "minimum password change time" thing shortly 17:23:08 lbragstad: and make it so -1 is a "never allowed", 18:10:52 Lance Bragstad proposed openstack/keystone master: Introduce new TokenModel object https://review.openstack.org/559129 18:21:08 #openstack-security 19:20:38 lbragstad: almost have the password opt override added for min_password_age 19:21:14 lbragstad: i am also implementing the case where if min_password_age is -1 in config, it makes password changes impossible. 19:21:39 cool 19:22:07 so, you will now have a useropt "min_password_age" which overrides the global conf only if it is greater than the global conf 19:22:15 (basically, we only take the highest of the two values) 19:22:21 EXCEPT if the value is -1 for either 19:22:32 which means passwords may not be changed via the change_password API 19:24:54 that makes se 19:24:56 sense* 19:25:24 knikolla: did you have the patch to replace non-existant users with @ while listing role assignments? 19:25:56 * lbragstad thinks something in our ldap implementation regressed 19:26:28 i'm noticing something pretty strange 19:26:54 if i have a user in ldap, i can create a role assignment for them, and everything is fine and dandy 19:27:16 if i remove the user from ldap directly, i still see the role assignment 19:27:46 if i attempt to remove the role assignment, i get an error saying the user can't be found, which makes sense 19:27:55 but the role assignment doesn't go away 19:28:13 and then after some period of time... the user name in the assignment list switches to @? 19:28:44 lbragstad: that was a long time ago, yeah i think i did a patch for smth like that. 19:29:03 Changed names with empty string though 19:29:14 Not sure about the @ 19:29:35 http://paste.openstack.org/show/718621/ 19:30:10 i had a developers@Users group 19:30:16 Oh, because @ divides the username and domain 19:30:16 and an lbragstad@Users user 19:30:23 Which both are empty strings 19:30:28 yeah 19:31:31