Friday, 2017-01-27

*** rcernin has joined #openstack-keystone00:00
*** stingaci has joined #openstack-keystone00:00
*** lamt has quit IRC00:03
*** lamt has joined #openstack-keystone00:04
*** lamt has quit IRC00:04
*** harlowja has quit IRC00:04
*** stingaci has quit IRC00:04
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550700:05
*** chris_hultin|AWA is now known as chris_hultin00:08
*** chris_hultin is now known as chris_hultin|AWA00:11
rderosemorgan stevemar lbragstad dstanek browne knikolla: PCI patch is ready ^ Thanks for the reviews!00:16
*** spzala has joined #openstack-keystone00:37
*** MasterOfBugs has quit IRC00:42
*** PramodJ has joined #openstack-keystone00:42
*** pramodrj07 has quit IRC00:42
*** MasterOfBugs has joined #openstack-keystone00:42
*** jose-phillips has quit IRC00:43
*** thorst_ has joined #openstack-keystone00:45
*** agrebennikov__ has quit IRC00:48
*** stingaci has joined #openstack-keystone00:49
*** rcernin has quit IRC00:51
*** stingaci has quit IRC00:53
*** rcernin has joined #openstack-keystone00:54
*** martinlopes is now known as martinlopes|busy00:54
*** thorst_ has quit IRC00:55
*** rcernin has quit IRC00:55
*** rcernin has joined #openstack-keystone00:55
*** adrian_otto has quit IRC01:03
*** spotz_zzz is now known as spotz01:06
*** browne has quit IRC01:10
openstackgerritSteve Martinelli proposed openstack/keystone: add additional deprecation warnings for KVS options  https://review.openstack.org/42600901:15
stevemarmorgan: i added https://review.openstack.org/#/c/426009/ for posterity01:15
*** spotz is now known as spotz_zzz01:16
Adobemanhttps://bugs.launchpad.net/keystone/+bug/1063858 <- is this still in effect?01:18
openstackLaunchpad bug 1063858 in OpenStack Identity (keystone) "LDAP identity driver does not support 'enabled'" [Wishlist,Fix released] - Assigned to Yuriy Taraday (yorik-sar)01:18
Adobemanwith newton01:18
Adobemanuhm should've been fixed by grizzly..01:19
*** stingaci has joined #openstack-keystone01:21
*** stingaci has quit IRC01:26
*** thorst_ has joined #openstack-keystone01:27
*** edmondsw has joined #openstack-keystone01:31
*** edmondsw has quit IRC01:43
samueldmqayoung: you around ?01:44
samueldmqayoung: I thought it wasn't possible to create implied roles with domain-specific roles from different domains.01:45
samueldmqfor me, domain-specific roles were isolated inside its owning domain01:45
*** chris_hultin|AWA is now known as chris_hultin01:46
*** v1k0d3n has quit IRC01:51
*** v1k0d3n has joined #openstack-keystone01:53
*** stingaci has joined #openstack-keystone01:53
*** edmondsw has joined #openstack-keystone01:54
*** stingaci has quit IRC01:58
*** spotz_zzz is now known as spotz02:00
openstackgerritSamuel de Medeiros Queiroz proposed openstack/python-keystoneclient: Fix boto version strip regex  https://review.openstack.org/42470002:01
*** spzala has quit IRC02:02
*** chris_hultin is now known as chris_hultin|AWA02:05
openstackgerritMerged openstack/keystone: Code-Defined Resource-specific Options  https://review.openstack.org/42433402:08
samueldmqayoung: see my comment in https://review.openstack.org/#/c/422819/02:08
openstackgerritMerged openstack/keystone: Add 'options' as an explicit user schema validation  https://review.openstack.org/42553602:09
*** spotz is now known as spotz_zzz02:10
*** MasterOfBugs has quit IRC02:11
*** dims_ has joined #openstack-keystone02:14
*** PramodJ has quit IRC02:14
*** dims has quit IRC02:14
*** thorst_ has quit IRC02:18
samueldmqjamielennox: hey, you around ?02:20
*** thorst_ has joined #openstack-keystone02:20
samueldmqjamielennox: would like to discuss bp/return-request-id-to-caller with you02:20
*** stingaci has joined #openstack-keystone02:26
*** stingaci has quit IRC02:30
*** spotz_zzz is now known as spotz02:37
*** edmondsw has quit IRC02:42
*** edmondsw has joined #openstack-keystone02:43
*** edmondsw has quit IRC02:43
*** edmondsw has joined #openstack-keystone02:43
*** spotz is now known as spotz_zzz02:46
*** dims_ has quit IRC02:47
*** d-bark has joined #openstack-keystone02:47
lbragstadgagehugo even though samueldmq and stevemar beat me to it, i +2'd it02:49
lbragstadgagehugo thanks for submitting the follow up patch!02:49
*** dims has joined #openstack-keystone02:50
*** edmondsw has quit IRC02:52
*** stingaci has joined #openstack-keystone02:57
dstaneksamueldmq: i hate that review02:59
dstanekAdobeman: still no luck?03:00
*** edmondsw has joined #openstack-keystone03:01
*** stingaci has quit IRC03:02
*** edmondsw has quit IRC03:09
*** edmondsw has joined #openstack-keystone03:11
stevemardstanek: samueldmq, agreed bp/return-request-id-to-caller stinks :(03:13
*** edmondsw has quit IRC03:14
*** edmondsw has joined #openstack-keystone03:14
*** edmondsw has quit IRC03:14
*** edmondsw has joined #openstack-keystone03:15
stevemarif someone is interested, this should be an easy review https://review.openstack.org/#/c/426009/03:20
openstackgerritSteve Martinelli proposed openstack/keystone: add additional deprecation warnings for KVS options  https://review.openstack.org/42600903:21
*** severion has joined #openstack-keystone03:27
*** stingaci has joined #openstack-keystone03:30
*** spotz_zzz is now known as spotz03:31
*** yarkot has joined #openstack-keystone03:31
*** stingaci has quit IRC03:35
*** thorst_ has quit IRC03:40
*** spotz is now known as spotz_zzz03:40
ayoungsamueldmq, nope03:51
*** tqtran has quit IRC03:55
*** stingaci has joined #openstack-keystone04:02
*** spotz_zzz is now known as spotz04:06
*** stingaci has quit IRC04:07
openstackgerritMerged openstack/python-keystoneclient: Fix boto version strip regex  https://review.openstack.org/42470004:13
*** spotz is now known as spotz_zzz04:16
*** edmondsw has quit IRC04:17
*** edmondsw has joined #openstack-keystone04:17
*** nicolasbock has quit IRC04:17
*** stingaci has joined #openstack-keystone04:19
*** edmondsw has quit IRC04:21
*** mtreinish has quit IRC04:22
*** mtreinish has joined #openstack-keystone04:22
*** stingaci has quit IRC04:23
*** diazjf has joined #openstack-keystone04:41
*** spotz_zzz is now known as spotz04:57
rderosestevemar that's a weak -105:06
stevemarrderose: the -1 was for rel note and docs05:07
stevemarprevious patch had them05:07
rderose:)05:07
rderosewas planning to do that in a separate patch05:07
*** spotz is now known as spotz_zzz05:07
rderoseyou want it all in one?05:07
rderosestevemar: btw where do you want the constants?05:08
rderosestevemar: it's mostly being used in the backend, so I thought I'd keep with resource_options.py05:08
stevemarrderose: all in one doesn't bug me05:09
stevemarrderose: the constant thing was more of a general observation, my spidey sense went off05:10
rderose:)05:10
stevemarjust felt weird to have it there, but i won't hold it against ya05:10
rderosealright05:10
rderoselet me add the release notes05:10
rderosestevemar: okay for docs update to be separate?05:10
rderosedocs update not so important now, as this is only impacts passwords going forward05:13
stevemarsure, that one is less important05:13
rderosecool05:13
stevemarit was more "hey, this patch had other stuff before"05:13
rderosestevemar: by the way, I love single line functions. but no worries, I'll change this one just for you my friend.05:14
stevemarrderose: bknudson just rolled off his bed in disgust at that05:15
rderosehaha05:15
stevemarsingle-line is OK05:15
stevemarsingle use is my issue05:15
stevemari'd rather just short-circuit if you're worried about readability05:15
rderoseyou learned that "short-circuit" from dolphm05:16
stevemari'm actually trying to find some theory of programming to backup my claim, no luck yet!05:16
rderoseI've heard that before :)05:16
stevemardolphm and bknudson have beat certain things into me05:16
rderosehaha05:16
rderose:)05:17
bretonmorning, keystone05:17
rderosemorning ;)05:17
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550705:28
*** richm has joined #openstack-keystone05:29
*** richm has quit IRC05:41
*** spotz_zzz is now known as spotz05:44
*** david-lyle has quit IRC05:46
*** spotz is now known as spotz_zzz05:48
bretonsooo, that trusts for federated user patch is sad.05:51
*** Jack_V has joined #openstack-keystone05:56
*** thorst_ has joined #openstack-keystone05:56
bretonfederated users, when not in context, don't have any non-direct role assignments. And the code checks that they have. And while i could work around that in trust creation, there is similar check in trust usage.05:58
*** thorst_ has quit IRC06:01
openstackgerritNishant Kumar proposed openstack/keystone: Reuse already existing groups from upstream tempest config  https://review.openstack.org/42607806:08
bretonwhich cannot be worked around, because the only one who knows what groups they had at the moment is that user.06:08
morganhey breton =:)06:12
morganhow goes?06:12
morganstevemar: wait you don't like single line functions?!06:13
morganstevemar: LAMBDAS WANT A WORD WITH YOU ;)06:13
bretonhey06:14
bretonmorgan: how do we make trusts work with federated users? what do you think about adding shadow federated users to groups when they authenticate?06:15
bretonmaybe we should switch murano and heat and others who use trusts to ?allow_expired06:17
morganshouldn't shadow federated users already get some groups?06:18
morganbased upon the user object itelse?06:18
morganbasically, shouldn't trusts just work with the shadow user code (if it doesn't, that is how i'd manage that)06:18
bretonnope, they don't have any groups06:18
morganeh, they should support groups06:19
morganjust like everything else, a shadow user should be a near mirror of a real user06:19
morgan(near, just some auth like things aren't there)06:19
morgani'd actually go a step further...06:19
bretonbut if the mapping changes, the user will still be in the groups they shouldn't be in06:19
morganuse shadow users as a mechanism and make the created user a fully realized user object (doable based upon my convos w/ rderose )06:20
morganif mapping changes we're getting something wonky06:20
bretonor if remote groups change06:20
morganit's not really the same user if you change the mapping rules unless it is to change the attributes mapped ot the same local ones (aka name moves from X to Y on the federated side... though that should *never* happen)06:20
morgani don't see an issue with using local groups explicitly06:21
morganthe implicit groups shouldn't ever be used in trusts06:21
bretonsame thing -- the user will still be in the wrong groups06:21
morganif you add user X to group Y, it shouldn't matter if they are federated or not (since shadow user landed)06:21
morganif you're leaning on group information from the federated source, that is exclusive for that login06:22
morganvs a local-in-keystone-defined-group06:22
morganthat the user has explicitly been added to06:22
morganhold on06:22
morganok working through this in my head06:22
morganso 2 options06:23
morgan1) allow federated users to be added ot a local group06:23
morganin keystone06:23
morgan2) populate groups (visibly) for federated users within keystone06:23
morganthese options are not mutally exclusive06:23
morganwe could do both06:23
morgani'd need to think over the stuff (not 2 whiskeys in) for security implications of both06:24
morganoff the cuff, i am not opposed to either.06:24
breton1 is easy, i think we can already do it now06:24
morgan1 might be the way to support what you need.06:24
morgantoday*06:24
morgan2... might be a bit more of an issue06:24
bretonyep. But it required adding user to group manually06:25
morganlike i said i need to think through security implications when not trying to read/write code based on rderose's PCI patches (and a few whiskeys and late night)06:25
morgani don't have a real issue with that for the moment.06:25
bretoni proposed this https://review.openstack.org/#/c/415545/3/keystone/auth/plugins/mapped.py06:25
morgandirect, manual, adding isn't terrible06:25
*** martinlopes|busy has quit IRC06:25
morganto start06:25
morganwe can improve the UX as we move forward06:25
bretonbut it has 2 issues. 1. mapping changes. 2. type: OIDC_GROUPS06:27
morgani'll ponder this a bit more06:29
morgani can't answer concretely atm. sorry :(06:29
openstackgerritSteve Martinelli proposed openstack/keystone: clean up release notes for ocata  https://review.openstack.org/42609506:35
stevemari really need to start enforcing better release ntoes :(06:36
*** spotz_zzz is now known as spotz06:39
bretonstevemar: we've lost one here: https://review.openstack.org/#/c/415545/306:41
*** diazjf has quit IRC06:42
morganstevemar: shhhhhh. it's almost over06:44
morganstevemar: :P06:44
morganstevemar: did rderose respin to only set expired on admin set automatically?06:44
morganstevemar: because if he did... a lot of strings/commit message/help messages are wrong06:45
morganand option names06:45
morganit shouldn'tbe "after first use" anything06:45
morganrderose: ^ sorry *wince*06:45
*** spotz is now known as spotz_zzz06:49
*** adriant has quit IRC07:11
*** spotz_zzz is now known as spotz07:15
*** stingaci has joined #openstack-keystone07:17
*** stingaci has quit IRC07:21
*** rcernin has quit IRC07:24
*** spotz is now known as spotz_zzz07:24
*** richm has joined #openstack-keystone07:25
*** stingaci has joined #openstack-keystone07:49
*** stingaci has quit IRC07:54
*** thorst_ has joined #openstack-keystone07:57
*** thorst_ has quit IRC08:01
*** spotz_zzz is now known as spotz08:09
*** gitudaniel has joined #openstack-keystone08:14
*** spotz is now known as spotz_zzz08:19
*** spotz_zzz is now known as spotz08:45
*** spotz is now known as spotz_zzz08:55
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:01
gitudanielI'm trying to set up a keystone development environment. I'm currently folloing the Best Practices documentation http://docs.openstack.org/developer/keystone/devref/development_best_practices.html In the section on Running Keystone, on running the command uwsgi --http 127.0.0.1:35357 --wsgi-file $(which keystone-wsgi-admin)09:04
gitudanielI get the error uwsgi: option '--wsgi-file' requires an argument09:05
gitudanielgetopt_long() error09:05
bretongitudaniel: what is output of $(which keystone-wsgi-admin) ?09:07
gitudanielbreton: it returns no output09:09
gitudanielI tried editing the configurations with the keystone-manage bootstrap command but got "The program 'keystone-manage' is currently not installed. You can install it by typing: sudo apt install keystone09:11
*** richm has quit IRC09:21
*** richm has joined #openstack-keystone09:37
*** spotz_zzz is now known as spotz09:39
bretongitudaniel: probably some virtualenv is not activated or keystone is not installed. http://docs.openstack.org/developer/keystone/devref/development.environment.html -- this describes virtualenv09:49
*** spotz is now known as spotz_zzz09:49
samueldmqmorning all09:49
bretongitudaniel: or you can just google about virtualenv in python09:49
bretongitudaniel: it will work too09:49
bretonsamueldmq: \o09:50
samueldmqbreton: hey09:50
gitudanielsamueldmq o/09:52
samueldmqgitudaniel: hello!09:54
gitudanielbreton: I did create a virtualenv before cloning into keystone. I followed the Setting up a Development environment then moved to the Python Project Guide and onto the Best Practices. Did I miss something?09:54
*** tqtran has joined #openstack-keystone09:58
*** thorst_ has joined #openstack-keystone09:58
*** tqtran has quit IRC10:02
*** thorst_ has quit IRC10:02
*** richm has quit IRC10:06
*** richm has joined #openstack-keystone10:09
*** richm has quit IRC10:14
*** d-bark has quit IRC10:17
*** spotz_zzz is now known as spotz10:33
*** spotz is now known as spotz_zzz10:43
*** mvk has quit IRC11:06
*** spotz_zzz is now known as spotz11:09
*** stingaci has joined #openstack-keystone11:09
*** spotz is now known as spotz_zzz11:19
*** chlong has joined #openstack-keystone11:24
*** stingaci has quit IRC11:27
*** stingaci has joined #openstack-keystone11:28
*** stingaci has quit IRC11:32
bretongitudaniel: have you activated it?11:45
bretongitudaniel: `source /path/to/venv/bin/activate`11:46
gitudanielbreton: yes I have. It is active11:48
*** stingaci has joined #openstack-keystone11:55
*** thorst_ has joined #openstack-keystone11:59
*** stingaci has quit IRC12:00
*** richm has joined #openstack-keystone12:00
*** thorst_ has quit IRC12:03
*** spotz_zzz is now known as spotz12:03
*** catintheroof has joined #openstack-keystone12:04
*** mvk has joined #openstack-keystone12:04
*** nicolasbock has joined #openstack-keystone12:04
*** richm has quit IRC12:05
*** severion has quit IRC12:11
*** spotz is now known as spotz_zzz12:13
*** stingaci has joined #openstack-keystone12:26
*** thorst__ has joined #openstack-keystone12:43
*** richm has joined #openstack-keystone12:50
*** spotz_zzz is now known as spotz12:54
dstanekgitudaniel: what is in you virtualenv's bin directory?12:56
gitudanieldstanek: activate           mdexport.pyc                      parse_xsd2.py12:58
gitudanielactivate.csh       merge_metadata.py                 parse_xsd2.pyc12:59
gitudanielactivate.fish      merge_metadata.pyc                pbr12:59
gitudanielactivate_this.py   migrate                           pip12:59
gitudanielalembic            migrate-repository                pip212:59
gitudanielbindep             netaddr                           pip2.712:59
gitudanielconvert-json       oslo-config-generator             pybabel12:59
gitudanieleasy_install       oslo-messaging-send-notification  python12:59
gitudanieleasy_install-2.7   oslo-messaging-zmq-broker         python212:59
gitudanieljsonschema         oslo-messaging-zmq-proxy          python2.712:59
gitudaniellockutils-wrapper  oslopolicy-checker                python-config12:59
gitudanielmake_metadata.py   oslopolicy-list-redundant         sqlformat12:59
gitudanielmake_metadata.pyc  oslopolicy-policy-generator       uwsgi12:59
gitudanielmako-render        oslopolicy-sample-generator       wheel12:59
gitudanielmdexport.py        osprofiler12:59
*** tqtran has joined #openstack-keystone13:00
dstanekgitudaniel: it doesn't look like keystone is installed in the virtual env13:01
dstanekdo we really delete users from the database when we delete a federation protocol?13:01
dstaneksamueldmq: you need to be a little more liberal with the -1s :-D13:02
ayounggitudaniel, are you using the uwsgi from the venv pip install, and not the package provided by the distro?13:03
ayoungthe distro uwsgi for Fedora at least was out of data13:03
ayoungfate13:03
ayoungdate13:04
ayoungdinnerplate13:04
ayounggah13:04
*** tqtran has quit IRC13:04
*** spotz is now known as spotz_zzz13:04
gitudanieldstanek: thank you. I created a folder then activated a virtual env before cloning into keystone. In the dependencies it installs virtual env should I have first cloned the repo cd into it and then activate the virtual env?13:04
*** catintheroof has quit IRC13:05
gitudanielayoung: to install uwsgi I ran sudo apt install uwsgi13:05
ayounggitudaniel, yeah don't do that13:05
ayounggitudaniel, get rid of that, and instead activate the venv and pip install13:05
ayounggitudaniel, I usually run tox on a checkout, to make sure the tests run, and it also builds the venv13:06
ayoungso then13:06
ayoung. .tox/py27/bin/activate13:06
ayoungor 34 or whatever python version you want to use13:07
ayoung pip install uwsgi13:07
gitudanielayoung: thank you. So after cloning the repo should I run vitualenv keystone cd keystone then source bin/activate to prevent the dependencies from installing on my host system?13:11
*** catintheroof has joined #openstack-keystone13:16
*** tlbr has joined #openstack-keystone13:16
*** edmondsw has joined #openstack-keystone13:21
*** edmondsw_ has joined #openstack-keystone13:23
*** richm1 has joined #openstack-keystone13:23
*** richm has quit IRC13:24
*** edmondsw has quit IRC13:25
*** raildo has joined #openstack-keystone13:30
dstanekgitudaniel: you still have to install keystone into the virtualenv13:33
dstanek'python setup.py develop' in the activated enironment13:34
gitudanieldstanek: thanks let me do that13:35
*** thorst__ is now known as thorst_13:42
*** spotz_zzz is now known as spotz13:48
rodrigodsstevemar, around? i'm doing some testing here with domain specific roles and the API is returning something like: http://paste.openstack.org/raw/596735/13:52
rodrigodsstevemar, do you know if this is expected?13:53
gitudanieldstanek: ayoung breton thank you for your help i ran python setup.py develop then uwsgi --http 127.0.0.1:35357 --wsgi-file $(which keystone-wsgi-admin) it ran and I got an /etc/keystone/fernet-keys/ does not exist. Hopefully the configuration file covers this as I read up on what fernet keys are. Can we make it such that someone else doesn't run into the same challenges I did. I honestly13:55
gitudanielwouldn't have thought to run python setup.py develop. If it is I'd like to help13:55
ayounggitudaniel, keystone-manage --help13:56
*** lamt has joined #openstack-keystone14:01
*** tqtran has joined #openstack-keystone14:01
*** spilla has joined #openstack-keystone14:01
dstanekgitudaniel: yeah, what ayoung said. look for fernet_setup14:05
*** tqtran has quit IRC14:05
*** spzala has joined #openstack-keystone14:06
rodrigodsstevemar, nvm, "domain" is the "extras"14:07
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550714:09
samueldmqdstanek: hey, too little -1's  ? :)14:09
samueldmqdstanek: sometimes I felt I was doing so many -1s, sometimes I don't want to block because of an easy thing, specially if it's something important to get in14:10
samueldmqeasy/nit14:10
dstaneksamueldmq: :-)14:11
gitudanielayoung, dstanek: thanks I found it let me run it14:11
samueldmqdstanek's +ratio is 43.7%14:12
samueldmqbknudson also used to have that +ratio :-)14:12
*** agrebennikov__ has joined #openstack-keystone14:12
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550714:14
*** markvoelker has joined #openstack-keystone14:16
openstackgerritSteve Martinelli proposed openstack/keystone: clean up release notes for ocata  https://review.openstack.org/42609514:17
*** stingaci has quit IRC14:18
samueldmqstevemar: given your reply in ^ about the PCI options that are being deprecated14:22
samueldmqthen https://review.openstack.org/#/c/423909/ and https://review.openstack.org/#/c/424220/ would not need to deprecate those options14:22
samueldmqjust replace them with the in-code configs instead14:23
*** jperry has joined #openstack-keystone14:24
samueldmqrderose: morgan: dstanek ^ since lockout_ignored_user_ids and ignore_password_expire_user_ids were added this cycle, we don't need to deprecate, just switch to in-code options14:25
samueldmqif we get those replacements in in time14:26
rderosesamueldmq: those were added in newton14:26
dstaneksamueldmq: is that true? those were added in this cycle?14:26
dstanekrderose: that's what i thought14:26
samueldmqrderose: dstanek https://review.openstack.org/#/c/39857114:28
samueldmqbug it's closing is tagged as ocata-214:28
rderosesamueldmq dstanek: hmm... password ignores list was definitely added in newton: https://review.openstack.org/#/c/351749/14:30
rderosesamueldmq: but you are right about lockout ignore list, thought for sure it was newton :)14:32
samueldmqrderose: cool, we should be able to just replace without deprecation in that case14:32
samueldmqif we still get that in this cycle14:32
rderosesamueldmq: yep14:33
samueldmqrderose: dstanek: cool, posted a comment in https://review.openstack.org/#/c/424220/14:34
samueldmqjust to document it14:34
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: clean up release notes for ocata  https://review.openstack.org/42609514:36
*** Dinesh_Bhor has quit IRC14:37
samueldmqdstanek: ^ could you +2 again ? and +A ..14:37
samueldmqdstanek: there was just a nit, closing backsticks were wrong:  `.` rather than ``.14:38
samueldmqI fixed it14:38
lbragstadoffice hours!!14:38
lbragstadtoday I'm going to be working on reviewing https://review.openstack.org/#/c/425507 (it's getting close!)14:38
samueldmqlbragstad: hey14:38
lbragstadsamueldmq o/14:39
dstaneksamueldmq: done14:41
samueldmqdstanek: yt14:41
samueldmqty14:42
rderoselbragstad: ++14:42
*** stingaci has joined #openstack-keystone14:48
rderosedstanek: confused by your last comment. if you change what?14:51
*** stingaci has quit IRC14:52
samueldmqrderose: reviewed and commented, just minor things in tests and doc14:54
samueldmqrderose: that's looking pretty nice14:54
rderosesamueldmq: cool, thanks :)14:55
dstanekrderose: in the future it could be possible to break that code and have the test pass. probably not a huge deal14:55
dstanekrderose: the reason i don't think it's that big of a deal is that the bug would likely be caught in the other password tests14:57
rderosedstanek: but create_user password doesn't have any impact on update_user password. update_user creates a new password and decides if it is expired.14:58
dstanekrderose: if you tooks out the update_user your test would still pass14:59
rderosedstanek: but that is what I'm testing (update_user), so I wouldn't take it out :)14:59
dstanekrderose: that's not the point. the point is that the user will already be in the required state for the test to pass. so that means that you are not proving update_user is doing the right thing. you are proving that it doesn't change the outcome15:01
dstanekrderose: for example, what if we later decide to make admins use a separate api to reset passwords? (maybe for extra security or whatever) you test will not detect an issue15:02
rderosedstanek: then update_user would create a new password and it wouldn't be expired15:03
rderosedstanek: but I see your point15:04
knikollao/ morning15:04
dstanekmorning knikolla15:05
knikollaanything i should be helping out with today?15:09
lbragstadrderose fwiw - i like the new approach in https://review.openstack.org/#/c/425507/1115:17
rderoselbragstad: thanks, yeah it's getting better15:19
rderoselbragstad: less of an impact on operators15:19
lbragstadrderose so - would operators have to go through and update each user in their deployment?15:20
rderoselbragstad: to ignore, yeah15:20
lbragstadrderose got it - and they can do that before they make the config switch15:21
dstaneklikely that's only service users15:21
rderoselbragstad: right15:21
dstanekif you want through them all then you wouldn't flip the switch anyway15:21
lbragstadrderose but after `keystone.conf [security_compliance] change_password_upon_first_use = True`, existing users in the system that don't have options set still need to be updated by an admin in order to change their password15:22
rderoselbragstad: sorry, not following...15:23
lbragstadsay a deployment has 1000 existing users, and 5 of those are service users15:24
rderoseexisting users that don't have options, would now be required to change their password15:24
dstaneklbragstad: no, this will only immediately impact new users and user that have their passwod reset by admin15:24
lbragstaddstanek right15:24
rderosedstanek lbragstad: ah, right. yeah, now it only impact passwords going forward15:25
*** jaosorior has joined #openstack-keystone15:25
lbragstadso if an operator wanted to force everyone in their deployment to reset their password - they would have to manually reset passwords for the other 995 useres15:25
rderosedstanek lbragstad: but as soon as you change a service users password, they will be impacted15:25
rderoselbragstad: or, run a db update script to expire everyone's password15:25
lbragstadso - for a period of time after an operator switches change_password_upon_first_use = True, there will be users in the deployment that can still authenticate with their old password15:29
dstaneklbragstad: possibly forever15:30
lbragstaddstanek right -depends on how the operator goes about doing the "migration"15:30
*** lamt has quit IRC15:33
*** stingaci has joined #openstack-keystone15:40
*** stingaci has quit IRC15:44
*** ravelar has joined #openstack-keystone15:49
*** mvk has quit IRC15:58
*** phalmos has joined #openstack-keystone15:59
*** phalmos has quit IRC15:59
*** adrian_otto has joined #openstack-keystone16:05
*** v1k0d3n has quit IRC16:06
*** adrian_otto has quit IRC16:09
*** adrian_otto has joined #openstack-keystone16:12
*** lamt has joined #openstack-keystone16:12
*** adrian_otto has quit IRC16:13
*** v1k0d3n has joined #openstack-keystone16:16
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550716:20
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550716:20
*** v1k0d3n has quit IRC16:21
*** v1k0d3n has joined #openstack-keystone16:21
morgano/16:25
morgansamueldmq: rderose claims the lockout and the password expiry were newton16:26
*** stingaci has joined #openstack-keystone16:26
gitudanielmorgan: o/16:26
rderosemorgan: password expiry was newton, but I was mistaken about lockout16:26
morgansamueldmq, rderose: i still want to deprecate because (lockout specifically) since people are tracking master and it went out in a tag16:27
morgani don't want to break anyone leaning on that option yet16:27
morganrderose: sorry about the -1 there.16:27
rderosemorgan: apologies, could have sworn lock list was newton, but it was just after the release16:27
morganno worries. still people can be using it because it went in tag-116:27
morganso we'll still deprecate16:27
rderosemorgan: if I set options to empty dict, does it clear out all my options?16:28
morganif you set the option mapper16:28
morganyes16:28
morganthis is why i don't want it exposed as a property and kept as a private attribute16:29
morgani toy with using __ prefix in all these cases16:29
morganbut opt for _ just because ease of use16:29
morganwhere needed/testing16:29
*** david-lyle has joined #openstack-keystone16:29
morganrderose: rebase your change on https://review.openstack.org/#/c/425957/ 425957 was approved and will conflict with your change.16:30
morganrderose: notably here https://review.openstack.org/#/c/425957/1/keystone/identity/backends/resource_options.py16:30
*** stingaci has quit IRC16:30
morgangitudaniel: allo there! :)16:30
morganrderose: also it makes it easier for you to acccess the constant16:31
rderosemorgan: okay16:31
morganrderose: and you don't need identity.backends.resource_contstants16:32
morgan:)16:32
rderosemorgan: oh great!16:32
rderose:)16:32
morganrderose: once you do that i'll finish the deprecation patch rebases16:34
*** thiagolib has joined #openstack-keystone16:34
gitudanielthank you guys for all your help. It's getting late in my part of the world16:37
rderosemorgan: user['options'] = {}16:40
morgangitudaniel: then sleep well.16:40
rderosemorgan: self.identity_api.update_user(user['id'], user)16:40
morganrderose: no16:40
rderosemorgan: doesn't seem to clear out the options16:40
morganrderose: i meant if you did user_ref._resource_option_mapper = {}16:40
morganrderose: if you want to unset options you must set each to None16:40
morganexplicitly in the dict16:40
morganit is designed specifically so not specifying options (or an option) doesn't change the value16:41
rderosemorgan: I don't allow None for ignore_password_expiry16:41
rderose:)16:41
morganso an update to the user that says options['ignore_password_expiry] = None wont affect say lockout16:41
morganrderose: you should.16:41
rderosemorgan: great16:41
morganrderose: None is how you unset / delete options16:41
rderose:)16:41
morganooooor16:41
morganyou don't allow unsetting16:41
*** diazjf has joined #openstack-keystone16:41
morganonly allow setting to False16:41
rderosemorgan: you can set to False16:41
rderoseright16:42
morganonce the option is set... it lives forever in the DB16:42
morganfor that user16:42
morgan(forever = until the user object is deleted)16:42
morgan(from the db itself)16:42
morgani'm ok with that choice16:42
morganthe design is explicitly to allow None on the backend to unset an option/clear it16:42
morganbut both works. MFA Rules for example should be unsettable if you want to dump all of them16:43
morganbut ignore_passworD_expiry is fine to persist in iether true/false16:43
morganrderose: if you think it would help... i could always start populating (minor change) defaults for options in the user's option key and accept a default value16:44
morganbut i kindof think it's better to only display options set16:45
morganstevemar: ^ cc on the defaults for Resource Options16:45
morgan(question)16:45
gitudanielmorgan: thank you. Have a great day16:46
*** gitudaniel has quit IRC16:46
dstanekmorgan: rderose: oh, i didn't even think about that when looking at the schema16:48
morgandstanek: it's not the end of the world.16:49
dstanekmorgan: easily fixable16:49
rderosemorgan: hmm... I don't think we need defaults16:49
rderosemorgan: we can improve it later if needed16:49
morgandstanek: i built the systme so we can unset options... but by no means we need to support that from the API16:50
morgani don't feel strongly that users (or admins) need to unset options if you can set the option to a value that restores default behavior16:50
dstanekrderose: everything has a default, even if it's not explicit16:52
knikollamorgan: in https://bugs.launchpad.net/keystone/+bug/1659053 the warnings are coming from the domain id 'default'16:53
openstackLaunchpad bug 1659053 in OpenStack Identity (keystone) "use uuids with pycadf" [Medium,Triaged] - Assigned to Gage Hugo (gagehugo)16:53
knikollaoh, somebody assigned himself, alright. should have refreshed my page.16:53
morganknikolla: so... we need to figure out what to do about that even if it is adding a logger to pycadf that explicitly exempts that issue16:53
morganit's stupid to warn on it if it's going ot be a real thing16:54
knikollagagehugo: ^^16:54
morganfor a loooong time16:54
morgan:)16:54
gagehugoo/16:54
morganwe may need to fix pycadf16:54
morganbut we can do that (if it isn't something we can fix in keystone)16:54
rderosemorgan: btw why don't I need the constants?16:54
morganthe fact it comes from the default domain tells me we are warning on a known design of keystone and should fix it16:54
morganrderose: look at how keystone.backend.resource_options is built now16:54
morganrderose: you can reference the constants from that module directly16:55
lbragstadwait - so options can't be unset?16:55
morganthe list was move into the register function and the constants defined in the file16:55
morganlbragstad: if you can't send a None for an explicit option you cna't unset it16:55
dstaneklbragstad: they can if you set them to None16:55
morganlbragstad: the way it works is user['options'] = {} doesn't change any options (by design)16:55
morganand setting one option doesn't change the value of others16:56
rderosemorgan: possible circular dependency here if I reference the module: https://review.openstack.org/#/c/425507/13/keystone/identity/backends/sql.py16:56
morganbut if you set an option explicitly to None16:56
rderosemorgan: as this also references the sql_model16:56
morganrderose: should be fine.16:56
morganrderose: resource_options doesn't import anything except keystone.common.resource_options16:57
rderosemorgan: okay, let me rebase16:57
lbragstadso if we set user['options'] = {'ignore_expired_password': True}16:58
lbragstadand then change it to False - that makes sense to me16:58
morganyes16:58
lbragstadbut we can never remove it?16:58
morganif you set it to None, the option would be unset and the row deleted from the DB16:58
lbragstadback to user['options'] = {} ?16:58
lbragstadoh - so ^ that would be possible by setting the option to NOne16:58
morganbut right now the json_schema doesn't allow user['options'] = {'ignore_expired_password': None}16:58
dstaneklbragstad: we'd have to let null through in the schema16:59
morganwhat dstanek said16:59
lbragstadah - so that should be possible but right it isn't because of jsonschema16:59
dstanekwe should totally do that16:59
morganit's designed to allow unsetting. but jsonschema is blocking atm16:59
gagehugoknikolla: were you working on that already? I just grabbed it a bit ago since it was unassigned, currently waiting for tests to finish running16:59
lbragstadaha16:59
*** spotz is now known as spotz_zzz16:59
morganlbragstad: i tried to make the option setting as foolproof as possible and also allow (future) setting of options each with a policy check17:00
knikollagagehugo: i just poked at it for a few minutes to figure out the root cause. which is domain_id 'default' is not a valid uuid so pycadf complains.17:00
gagehugoknikolla: interesting17:00
morganwhich likely means we either need to pass a smart logger to pycadf that explicitly allows defualt (or squashes that message) or patch pycadf17:01
mfischstevemar et al: Is there a way to make only 1 endpoint https?17:03
*** tqtran has joined #openstack-keystone17:03
mfischenabling SSL seems to do all of them17:03
mfischand a gradual switch is far easier than some big bang all openrcs and all services affected one17:03
knikollabiab, grabbing lunch17:03
*** jaugustine has joined #openstack-keystone17:03
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550717:06
rderosehold on ^17:06
*** tqtran has quit IRC17:07
*** stingaci has joined #openstack-keystone17:13
*** spzala has quit IRC17:16
*** stingaci has quit IRC17:17
* morgan holds on to... something...17:18
mfischoh boy ^17:18
mfischI hope thats disableable17:18
samueldmqmfisch: yes it is, change_password_upon_first_use is disabled by default17:20
samueldmq:-)17:20
mfischI checked17:21
*** tqtran has joined #openstack-keystone17:21
*** spzala has joined #openstack-keystone17:22
*** diazjf has quit IRC17:22
lbragstadit's an mfisch!17:23
mfischlol17:23
stevemaro/17:27
stevemarmorgan: re: pycadf change -- at least its just noise in the logger, nothing terribly broken17:30
stevemarmorgan: umm, its because "default" isn't a uuid eh17:30
stevemarmorgan: i also question how many people use the notifications in keystone? either writing to log or message bus17:30
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550717:31
rderoselbragstad samueldmq: rebased off of morgan's cleanup patch ^17:31
mfischstevemar: have you heard of a good process for switching to SSL in keystone, without blowing up the other services17:35
mfischbest idea I have so far is to run 2 containers and 2 endpoints17:35
*** stingaci has joined #openstack-keystone17:37
*** stingaci has quit IRC17:37
*** stingaci has joined #openstack-keystone17:37
dstanekmfisch: why wouldn't you have the same containers running SSL and non-SSL17:39
dstanek?17:39
mfischit would be the same binaries and docker images yes17:40
mfischI need to figure out the right way with puppet to generate 2 config files17:40
dstanekcan the same keystone instance not serve both?17:40
*** diazjf has joined #openstack-keystone17:40
mfischit appears once you set enable_ssl in keystone.conf it makes all endpoints ssl17:41
mfischbut since deployments are not instantaneous all services will break until a new config lands for them too17:41
mfischthis is probably a good question for the ops list17:43
dstanekmfisch: i'm not sure what enable_ssl is. what i would have thought you could do is setup 2 pools in the load balancer and use the same instances. i would hope that when we generate URLs we take HTTP/S into account17:43
stevemarmfisch: yeah, unfortunately you're saying all the right things :P17:43
*** adrian_otto has joined #openstack-keystone17:43
mfisch[ssl]17:43
mfischenable=False17:43
mfischthats the section I was paraphrasing17:43
dstanekmfisch: what does that do? have keystone terminate the SSL?17:44
mfischit seems to configure keystone to read certs in and configure ssl and then nothing works until you make all your keystone endpoints be https:// and reconfigure the authtoken sections for all services17:46
dstanekmfisch: odd. why not terminate in apache?17:46
mfischthat would probably simplify this, we're not using apache currently though17:47
dstanekso just fair warning if you terminate in keystone it'll be much slower and reduce throughput17:48
mfischdstanek: I need to dig more into this, another engineer was leading this investigation17:48
mfischdstanek: yep, that is also a concern17:48
mfischplan on getting some real numbers17:48
dstanekdo you have anything in front of it?17:48
dstanekmfisch: you could also try to put a terminator in front of it17:49
mfischwe have that for our public endpoints17:49
mfischhardware lb17:50
dstanekwhat are you doing this for just testing enironment?17:50
mfischmgmt directive17:50
mfischnow that this plan has gotten this far I'm paying attention to it ;)17:51
dstaneki always like terminating on the app server because then there is no internal traffic unencrypted. i usually use apache for that, but have has some success with stud17:52
dstanekthat was years ago though so there may be new hottness now17:52
dstanektopol: you going to PTG?17:52
topolYES!17:53
topolYou?17:53
mfischdstanek: I'll be at PTG also17:53
topoldstanek17:53
mfischdo board members hang out with regular people or no?17:53
topoldstanek flying in Sunday.17:53
topolThis board member does!!!!17:53
mfisch+117:54
topoljust a regular guy. I put my pants on two legs at a time just like everyone else :-)17:54
mfischI figured you'd say "my dress team puts my pants on one leg at a time"17:54
dstanektopol: yup. whoa that early?17:55
topolbahahaha17:55
mfischI'm flying in on Sat17:55
stevemartopol: it's customary for board members to buy the keystone team (and some operators) dinner17:55
stevemarjust saying17:55
dstanekstevemar: ++17:55
stevemartopol: i should clarify, *new* board members17:55
topoldstanek I have Interop meetings Monday Tuesday17:55
mfischI bet if I called our IBM sales guy and said we wanted a nice dinner with Steve it would be setup ;)17:55
stevemarnew ones from ibm, new ones whose name starts with B17:56
stevemarmfisch: does your sales guy have to come?17:56
topolIm sure I can buy something for a few close friends17:56
mfischstevemar: nah he'll give you his CC number ;)17:56
stevemarmfisch: yessss17:56
mfischnot even sure we have an IBM sales guy but probably somewhere17:56
dstanektopol: i was going to see if you'd be around NC on Tuesday for lunch, but looks like not17:56
stevemarit'll be added to my amazon acct, k thx17:56
mfischgood plan17:56
topoldstanek, sorry. But will I see you at PTG?17:59
dstanektopol: yeah, i'll be there. driving down on Tuesday17:59
topolK18:00
*** harlowja has joined #openstack-keystone18:02
*** chlong has quit IRC18:03
*** diazjf has quit IRC18:06
*** ravelar has quit IRC18:06
*** jose-phillips has joined #openstack-keystone18:08
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550718:08
stevemarrderose: you forgot to commit the rel note!18:10
rderoseoops18:10
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550718:11
rderosestevemar: done18:11
stevemarmorgan / samueldmq did you want to have a last look at https://review.openstack.org/#/c/425507/ ?18:13
* samueldmq looks again18:13
samueldmqstill good to me18:14
*** mvk has joined #openstack-keystone18:16
stevemarrderose: thank you ronald!18:17
rderosestevemar: hey, thanks for the reviews18:17
stevemarrderose: just doing my job18:17
rderosestevemar: love how this one ended up18:17
stevemaraye18:18
stevemarbarely any code18:18
stevemarall tests18:18
rderoseyeah18:18
rderose:)18:18
knikollaayoung: looks like they dropped our class project.18:18
stevemarrderose: hmmm18:19
stevemarrderose: i think we called the option name incorrect18:19
stevemarrderose: the option should be "ignore_change_password"18:19
rderosestevemar: hmm...18:20
stevemarcause: https://review.openstack.org/#/c/424220/ should create the option "ignore_lockout"18:20
stevemarand https://review.openstack.org/#/c/423909/ should create the the option "ignore_password_expiry"18:20
rderosestevemar was sharing this for both password expires and change password...18:21
rderosebut...18:21
ayoungknikolla, no one signed up for it?18:22
stevemarrderose: yeah, we could they are the same, i was thinking of a 1:1 with the config option18:22
dstaneklots o churn18:22
stevemarrderose: cause failure to change passwd every X days, and being exempt from a gloabl passwd reset are two differnt things18:22
knikollaayoung: guess not enough.18:23
knikollaprobably got intimidated or wanted something that sounded cooler.18:23
rderosestevemar: so you could enforce one but not the other18:23
stevemarrderose: i think so, right?18:23
stevemarrderose: 1:1 makes more sense in my head18:24
rderosestevemar: yeah, I'm tending to agree18:24
rderoselet me change it18:24
stevemarbut there could be logical reasons why they would never not be both enabled18:24
stevemaryeah18:24
stevemarif you don't mind, i'll solo +A the fix18:24
stevemarrderose: let me bump it out18:25
rderosesure, fixing it now18:25
stevemarwell, the gate is stupid long anyway18:25
stevemarkk18:25
*** ravelar has joined #openstack-keystone18:26
ayoungknikolla, then I guess is is not going to happen18:26
*** jose-phillips has quit IRC18:26
lbragstadstevemar i updated https://bugs.launchpad.net/keystone/+bug/129115718:27
openstackLaunchpad bug 1291157 in OpenStack Identity (keystone) "idp deletion should trigger token revocation" [Medium,Confirmed]18:27
knikollaayoung: i can pick it up if you don't have time to work on it.18:27
lbragstadstevemar I can retest that later today and close accordingly18:27
stevemarlbragstad: sounds bueno to me18:29
stevemarmorgan: i saw you and breton talking in the morning about https://review.openstack.org/#/c/415545/ -- what the recap there?18:29
ayoungknikolla, I don't have time.  It is yours.  PLease make it happen18:31
morganstevemar: i need to think more18:32
morganthat was the recap18:32
*** stingaci_ has joined #openstack-keystone18:35
*** stingaci has quit IRC18:36
*** david-lyle has quit IRC18:39
stevemarmorgan: good recap :)18:39
*** spzala has quit IRC18:43
openstackgerritRon De Rose proposed openstack/keystone: PCI-DSS Force users to change password upon first use  https://review.openstack.org/42550718:47
rderosestevemar: ^18:47
rderosestevemar: wait, for got the release notes...18:48
rderosestevemar: nevermind, it should be good18:48
morganstevemar:  I targeted  bug 1659053 for ocata-RC118:48
openstackbug 1659053 in OpenStack Identity (keystone) "use uuids with pycadf" [Medium,Triaged] https://launchpad.net/bugs/1659053 - Assigned to Gage Hugo (gagehugo)18:48
morganstevemar: we can bump it if it doesn'tland18:48
morganbut...18:48
morganjust FYI18:48
*** spzala has joined #openstack-keystone19:00
morganrderose: nit on your patch (can be a followup) I don't like the use of UTCnow19:09
morganrderose: for an expiration, I like an explicit date such as epoch 0-19:09
morganrderose: i wouldn't aks for a change, but in theory utcnow could be wonky based upon NTP / manual clock updates, etc19:10
morgansetting an explicit "there is no way this is valid" expiration is better19:10
morganit could be a followup19:10
morganstevemar: ^ cc19:10
*** richm1 has quit IRC19:13
rderosemorgan: I thought UTC as our standard; not clear why utcnow would be wonky19:16
*** stingaci_ has quit IRC19:17
morganrderose: it's tied to local clock for evaluation19:17
rderosemorgan: hmm... so we can't trust it to be utc accurate?19:18
morganand not centralized. so edge nodes are responsible for timing. it's one of those general things.19:18
morganwe can to be within 5m19:18
morganor so19:18
morganwhich is acceptable drift19:18
morganwhat we've said is our threshold for token validtity +/- 300s19:18
morganif you look at many systems when they do this and lean on the expiry setting for forcing a password change (vs an explicit attr)19:19
morganthey set to like EPOCH start19:19
morganjust to be sure there is no reason it *could* be valid due to drive19:19
morgandrift*19:19
morganetc19:19
morgan+2 on your patch19:19
morgancomment is added for potential followup19:19
rderoseokay, cool19:19
rderosethx19:19
*** tqtran has quit IRC19:20
morgannot a requirement, just one of those things that you don't think about... and then you do..and then someone's password works when it shouldn't :P19:20
rderoseright :)19:20
stevemarrderose: looking now!19:26
stevemarrderose: ah you went for the option name = ignore + config_option, nice19:27
*** spzala has quit IRC19:29
stevemarrderose: approved !19:29
rderosestevemar: sweet!19:30
stevemarrderose: you going to pick up https://review.openstack.org/#/c/423909/ ?19:32
stevemarrderose: i'll try rebasing https://review.openstack.org/#/c/424220/1 for you19:32
*** stingaci has joined #openstack-keystone19:32
rderosestevemar: sounds good19:34
*** stingaci has quit IRC19:37
dstanekwhat's left?19:37
* morgan will be doing the deprecations now19:38
morganand the MFA thing19:38
morgantoday19:38
dstanekmorgan: ping me if you need a review19:39
morgandstanek: will do19:42
*** richm has joined #openstack-keystone19:42
openstackgerritSteve Martinelli proposed openstack/keystone: Deprecate `lockout_ignored_user_ids` conf option  https://review.openstack.org/42422019:44
*** jose-phillips has joined #openstack-keystone19:48
*** d-bark has joined #openstack-keystone19:53
*** david-lyle has joined #openstack-keystone19:53
*** david-lyle has quit IRC19:53
*** david-lyle has joined #openstack-keystone19:54
*** Jack_V has quit IRC19:58
dstanekstevemar: do we still need that ^?19:59
morganROFL... i was wondering why my new opt wasn't showing up... because it wasn't registered!20:00
*** david-lyle has quit IRC20:01
*** david-lyle has joined #openstack-keystone20:01
openstackgerritSteve Martinelli proposed openstack/keystone: Create user option `ignore_lockout_failure_attempts`  https://review.openstack.org/42422020:01
stevemardstanek: you refering to the deprecation?20:02
stevemardstanek: no, i forgot to adjust the commit message20:02
stevemardstanek: i think i migrated that patch to the new option format, just the tests need to be cleaned up20:02
stevemardstanek: give it a cursory glance :)20:02
stevemarmorgan: rderose let's all base our patches on 42550720:03
stevemarfirst one to get approved doesn't have to rebase :D20:03
*** stingaci has joined #openstack-keystone20:04
morganhah20:04
dstanekstevemar: got it, thanks20:04
rderosestevemar: it sounded like morgan was working on the deprecation patches.20:05
rderosemorgan: did you want me to take over?20:05
stevemarrderose: oh ja?20:05
rderosestevemar: "morgan will be doing the deprecations now" ^20:06
morgani am working on deprecations20:06
morganalmost have the first one working20:06
rderose:)20:07
morgandebugging a small oddity20:07
*** stingaci has quit IRC20:08
openstackgerritSteve Martinelli proposed openstack/keystone: Create user option `ignore_lockout_failure_attempts`  https://review.openstack.org/42422020:10
morganLOL oh man. ... i think the context cache is biting me for this test20:10
stevemarrderose: hehe20:11
stevemarrderose: whoops, missed that20:12
stevemarrderose: you take a well deserved break then lol20:12
morganso.. i am setting the option for ignores_password_expiry and testing the passwor din expired20:12
morganand it passes20:12
rderosestevemar: :)20:12
morganthen i set the option to false.. and i re-auth and it still succeeds20:12
*** MasterOfBugs has joined #openstack-keystone20:12
morganchecking user['options']['ignore_password_expiry'] says "false"20:12
morganbut the option_value from the resource_mapper says it's "true"20:13
morganw.t.f20:13
morgan.20:13
rderosemorgan: looking20:13
morganlet me post the code.20:13
*** pramodrj07 has joined #openstack-keystone20:15
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate [security_compliance]\password_expires_ignore_user_ids  https://review.openstack.org/42638420:15
morganrderose: ^20:15
stevemarmorgan: i've been udpating the lockout one fyi20:15
stevemarshould just need tests at this point20:15
morganso i added debugger lines, and in the latest test... if i update the user['options']['ignore_password_expiry'] to be false20:15
morganthe user_ref says it is false20:16
morganbut when i hit the SQL model's check expired, the mapper says the option value is true20:16
morgan*w.t.f*20:16
openstackgerritRichard Avelar proposed openstack/keystone: WIP update_user  https://review.openstack.org/42638620:18
dstanekugg...looks like i have to give up on lxc on fedora and maybe move to docker20:18
*** MasterOfBugs has quit IRC20:18
morgan=/20:18
dstanekunprivileged containers == all fail20:19
*** portdirect_travl is now known as portdirect20:21
*** diazjf has joined #openstack-keystone20:23
morganrderose: i figured it out.20:25
morganwell. crap on a stick20:25
rderose:)20:25
morganrderose: *rolls eyes820:25
morgansec i'll show you20:25
morganoh wait. no this shouldn't be hitting the cache20:25
rderosesql_model and condition?20:25
rderosein list and option?20:26
rderose((self.id not in ignore_list) and (20:26
rderose                ignore_pw_expiry and not ignore_pw_expiry.option_value)):20:26
morganno, the actual value from the resource manager is showing as True there20:26
morganevne though the options_dict says it's false20:26
rderoseno, that's right20:26
morganhere is an updated version20:26
morgansec20:26
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate [security_compliance]\password_expires_ignore_user_ids  https://review.openstack.org/42638420:27
morgana little more direct20:27
morganbut the issue is option_value is showing as True20:27
morganeven though the user dict says ['options']['ignore_password_expiry'] is False20:27
morgansee the result20:28
morgansec20:28
morganhttps://www.irccloud.com/pastebin/UoHnntZQ/20:28
morganrderose: ^20:28
morganas you can see, it's not rasing PassworDexpired20:28
morganbut returning the auth dict... and ignore_password_expiry is in-fact false20:29
*** jose-phillips has quit IRC20:29
rderosehmm...20:29
morganif i add an addition layer of debugging, model._resouce_option_mapper[password_expiry_opt.option_id] == True20:29
morganin the _get_password_expires_at method20:29
morganwondering if the resource_option_manager is somehow stale in the authenticate call?20:30
rderoseor, it's calling _get_password_expires_at before the options are set?20:31
morganshouldn't be possible20:31
morganhttps://www.irccloud.com/pastebin/t98QLGyL/20:31
morgan^20:31
rderosehmm...20:32
morganinverting the set/update of the option20:34
morganjust to be sure20:34
morganwell fu...20:34
morganit passes when i invert it20:34
morganso create sets the value to false, but the update sets the value to true20:34
morgan... whaaaaat the hell20:34
*** stingaci has joined #openstack-keystone20:35
dstanek:-)20:35
*** stingaci has quit IRC20:40
morgandstanek, rderose: can you see why this change would make it work?20:41
morganhttps://www.irccloud.com/pastebin/lRdJhOap/20:41
morganthat is all i changed... and the test now passes20:42
rderosehmm...20:45
rderosemorgan: commit the latest and let me play with it20:46
rderoseI'm not seeing why at the moment20:46
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate [security_compliance]\password_expires_ignore_user_ids  https://review.openstack.org/42638420:47
morganposted20:47
rderosemorgan: so when you create a user with the option, the tests fail, password is expired20:49
rderoseright?20:50
dstanekmorgan: what wasnt' working?20:51
*** jose-phillips has joined #openstack-keystone20:52
*** raildo has quit IRC20:56
*** jose-phillips has quit IRC20:58
openstackgerritSteve Martinelli proposed openstack/keystone: Create user option `ignore_lockout_failure_attempts`  https://review.openstack.org/42422021:00
stevemarstill needs a few more tests ^ morgan rderose21:00
openstackgerritKristi Nikolla proposed openstack/keystone: WIP: Install shibboleth-idp with Devstack plugin  https://review.openstack.org/40142121:01
rderoseokay morgan: now I'm baffled, it seems to be working for me, in either case (create/update)21:02
rderosemorgan: and I haven't changed anything21:03
knikollarodrigods: i think I'm not too far from having shibboleth-idp running. just need to debug why the container is throwing errors when launched with the configuration i created.21:05
*** haplo37_ has quit IRC21:05
*** stingaci has joined #openstack-keystone21:07
dstanekrderose: which review are you guys working on?21:08
*** thiagolib has quit IRC21:08
rderosedstanek: https://review.openstack.org/#/c/426384/21:08
dstanekrderose: and that is failing morgan as-is?21:09
rderosedstanek: it's not failing for me21:10
*** stingaci has quit IRC21:11
dstanektest_backend_sql work fine for me. running the full tests now21:12
rderosemorgan dstanek: even when I take the ignore list out of the picture (test above), and replace it with ignore option, it passes21:13
rderosemorgan: what's the issue?21:13
rderoseseems to be working21:13
*** haplo37_ has joined #openstack-keystone21:16
knikollafull tests pass for me21:19
openstackgerritMerged openstack/keystone: Adds tests showing how mapping locals are handled  https://review.openstack.org/41846021:22
dstanekfull tests work for me as well21:23
harlowjahey guys, so jamielennox i think if i'm correct made a bunch of changes in oslo.context that are now spewing depreciations (which afaik are critical/gate stopping in keystone) and causing keystone to die21:26
dimsstevemar : hey, latest oslo.context release can't get into u-c because of a problem...21:26
harlowjacan we get those prioritized high to get fixed21:26
harlowjahttp://logs.openstack.org/34/421934/2/check/gate-cross-keystone-python27-db-ubuntu-xenial/b0c971f/testr_results.html.gz21:26
dimswhat harlowja said :) ^21:27
harlowjaor turn off the critical 'test' until thats fixed21:27
harlowja(such critical depreciation thing imho shouldn't be a gate-blocker but that's a different story, lol)21:27
dimsdstanek : morgan : stevemar : thoughts please ^21:27
dstanekdims: that from using the latest oslo.context?21:34
dimsyep21:34
dimsdstanek : off this review - https://review.openstack.org/#/c/421934/21:34
dstanekdims: is this a chicken/egg problem where i can fix it to pass your tests, but it will fail gerrit with what is currently installed?21:35
harlowjahmmm21:38
harlowjai'd say turn off that depreciations are critical first21:38
harlowjafix it in keystone21:38
harlowjaturn it back on21:38
harlowjai think u can though fix it in the tests first21:38
*** stingaci has joined #openstack-keystone21:39
harlowjawith what's currently installed21:39
harlowjabut not 100% on that21:39
dimsis this the trigger? http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/core.py#n49621:40
harlowjai d o believe so dims21:40
harlowjaturns them all into critical exceptions21:41
harlowjawhich well, ya, was going to cause this to happen one day21:41
dstaneki vote for turning that off and fixing later. will be a quick patch is spawn21:41
knikolla++21:42
harlowjak21:42
*** edtubill has joined #openstack-keystone21:42
*** stingaci has quit IRC21:43
*** catintheroof has quit IRC21:44
dimssounds good dstanek21:45
dimsso who is going to file one? :)21:45
*** catintheroof has joined #openstack-keystone21:45
dstaneki just created a patch now.21:45
dstaneki'm going to submit two actually :-) see which one wins21:46
openstackgerritDavid Stanek proposed openstack/keystone: Turn off deprecation -> critical in tests  https://review.openstack.org/42640721:46
dims:)21:46
openstackgerritJohn Perkins proposed openstack/keystone: Integrate oslo.config validator  https://review.openstack.org/42640821:47
dimsdhellmann : working a plan with keystone folks about oslo.context. in their test suite they trigger failure on any deprecation - http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/core.py#n49621:48
dimsoops wrong channel :)21:48
harlowjathx dstanek21:49
*** catintheroof has quit IRC21:49
openstackgerritMerged openstack/keystone: Cleanup for resource-specific options  https://review.openstack.org/42595721:50
morganrderose: when i did "ignore = True" then set to false, it wouldn't pass21:51
morganrderose: but inverting it to False first then True, passes21:52
dstanekharlowja: np21:53
dstanekdims: harlowja: i'm testing out a change now that fixes the errors at the source too21:53
*** adrian_otto has quit IRC21:54
openstackgerritGage Hugo proposed openstack/keystone: WIP Fix multiple uuid warnings with pycadf  https://review.openstack.org/42641121:57
gagehugomorgan knikolla ^^22:01
morganuh22:02
morganwe're copy/pasting code into tools/ ?22:02
morgandims: ^ config validator?22:02
dstanekmorgan: dims: :-( we worked so hard to reduce those kinds of things22:04
stevemarharlowja: dhellmann dims -- we have the fail on deprecation so we don't end up using them in our code ... IIRC :)22:05
stevemardstanek: yeah :(22:05
dhellmannstevemar : well, you're now blocking anyone else from using this new version of the lib22:05
stevemardhellmann: yeah, we will unblock, that wasn't the intention22:05
morgandstanek: i feel strong enough on that that it's getting a -222:05
dhellmannstevemar : thanks22:06
morgandstanek: no copy/paste/additions to tools/ (the limited shell scripts make sense)22:06
dstanekstevemar: i have another patch that i'm testing locally that fixes our context object22:06
dhellmannstevemar : maybe we can find another way to test that, by not using a job that's also running against the requirements repo22:06
stevemardhellmann: yeah, probably, but this is the first time i think its happened in at least 18 months, just mostly horrible timing22:07
morgandhellmann: it is important we're not leaning on deprecated things imo. so, i'd like to keep this kind of stuff somehow22:07
morgandhellmann: i get it blocks things, but once in 18mo is not really bad imo22:08
stevemardstanek: the tests are failing with your patch22:08
dhellmannmorgan: I don't think it's fair for you to block progress elsewhere, on principle, so I would appreciate it if you would find another way to do this test.22:08
dstanekstevemar: which patch?22:08
dstanekstevemar: the deprecate->critical one?22:09
stevemardstanek: yes, that one22:09
stevemardstanek: http://logs.openstack.org/07/426407/1/check/gate-keystone-python27-db-ubuntu-xenial/a1b3e98/testr_results.html.gz22:09
stevemardstanek: it also fails pep8 :)22:09
morgandhellmann: i said i'd like to keep it somehow. i wasn't saying we should block everything here. though to be fair, it would be good if we had a way to run things that show how massive a headache deprecations are going to be for the projects22:09
dstanekstevemar: lol, ok. i didn't realize we had a test to make sure that happens22:09
morgandhellmann: i am VERY against releasing code that has deprecation warnings emitted (on principal across openstack and any project) that the operator cannot fix/deal with22:10
dhellmannmorgan : I agree, generally.22:10
*** stingaci has joined #openstack-keystone22:10
dhellmannI would also have preferred for this change to land months ago so we had time to deal with it22:11
morganso, i'd like to keep this somehow somewhere... and/or make it easier to identify before requirements update22:11
dhellmannthat's fine. I just don't think it should gate requirements, since it's not a global policy.22:11
morganthat makes me sad.22:11
*** jose-phillips has joined #openstack-keystone22:11
stevemardstanek: https://github.com/openstack/keystone/blob/master/keystone/tests/unit/tests/test_core.py#L85-L88 is the one that's failing22:11
morganthat other folks don't as strongly feel this way.22:12
dhellmannwe could work to make it a global policy, but in that case we would either freeze out all oslo api changes or we would have to have some sort of assurance that project teams would not block oslo work.22:12
dstanekstevemar: fixed locally...pusing in a sec22:12
dhellmannthe bottom of the stack is a hard place to work22:12
morgandhellmann: well. 2 things, if it's deprecated with no plans for removal... i'd give it a pass and make it a policy this needs to be prioritized prior to release(s)22:13
dhellmannif there were no plans for removal, a deprecation warning wouldn't be appropriate22:13
dhellmannso we could confirm those plans with the oslo team, but I assume they intend to remove the shims at some point22:14
morgandhellmann: if it s deprecated with plans for removal... i have other words and thoughts about that for libraries. and strongly disagree with the g-r methodologies and not capping at major revisions.22:14
dhellmannit's too late on a friday to start that conversation22:14
morgandhellmann: my complaints all stem from policies i really disagree with across how g-r works22:14
*** stingaci has quit IRC22:15
dhellmannI welcome your contributions to the requirements team in pike. :-)22:15
stevemarhehe22:15
morganand how we use major/minor revisions without explicit caps... but i'm far more of a stickler for these things than most of the community22:15
dhellmannwe tried caps, and they introduced so many gate wedges we had to drop them22:15
morgani've lost this argument enough times i wont block any changes on these fronts (but I would like some kind of clear way to identify the deprecations when the migrate into g-r)22:15
*** thorst_ has quit IRC22:16
stevemardhellmann: we'll ignore the warnings for now, i'll bug prometheanfire when the patch has merged22:16
dhellmannk22:16
dhellmanndo talk to harlowja and gcb about the plans for removing the deprecated things, though. because if they don't plan to, maybe we can just not warn.22:16
morgandhellmann: i was here for that time period and of the caps and wedges.  i think we could have resolved it in a different way. i don't think we could reasonable change course now without another horrible/long discussion22:16
openstackgerritDavid Stanek proposed openstack/keystone: Fixes deprecations caused by latest oslo.context  https://review.openstack.org/42641822:17
openstackgerritGage Hugo proposed openstack/keystone: Fix multiple uuid warnings with pycadf  https://review.openstack.org/42641122:17
morgandhellmann: i actually think deprecation is healthy, even without plans for removal and warning22:17
morganthis is the old way, use the new way22:17
morganplease, use the new way, it's better and better supported. this is to make sure we don't break things"22:17
morgan(quote/unquote)22:17
dhellmannmorgan : I was one of the people pushing caps before, fwiw. I like the constraints system a lot better.22:17
* dhellmann nods22:18
stevemardstanek: abandon https://review.openstack.org/#/c/426407/1 ? looks like you pushed 2 different patches22:18
stevemardstanek: keep the newer one22:18
morganmy complaint with constraints is it doesn't accurately show that a future revision will break us. but that is because we are mis-using major/minor version imo. again. more philisophical discussion than I plan to try and sheppherd in a massive change back to caps22:18
dstanekstevemar: sounds good to me22:19
* morgan wouldn't block these bits and changes to keystone in either case.22:19
dstaneki wanted to see both options22:19
stevemardstanek: whoa https://review.openstack.org/#/c/426418/1/keystone/common/context.py22:19
morgandhellmann: i think i'll noodle over how we can build something that'll highlight deprecations used that should be cleaned up... maybe some auto-created bugs on a periodic job (or post g-r update)22:19
morgandhellmann: something so we can make sure projects are aware of/able to identify things to get fixed :)22:20
dhellmannmorgan : I would support that work. Will you be at the ptg? Maybe we can discuss there?22:20
morganyeah i'll be there22:20
morganfrom tuesday ->22:20
morganmissing monday because i'm at a funeral that weekend befotre22:20
dhellmannI'm sure the whole oslo team would be happy to have something like that, because it would make it easier for us to clean up the legacy code we have22:20
dhellmannah, sorry to hear that22:20
dhellmannmention it to gcb, I think he's leading up the ptg organizing22:20
morganit was a long time coming and a very delayed (months delayed) funeral22:21
dhellmannmake sure it's on the oslo agenda22:21
* morgan will see about getting it on the agenda22:21
morganuntil then... i has things to finish up in keystone ASAP :P22:21
dhellmanncool22:21
dhellmann++22:22
*** edmondsw_ has quit IRC22:23
dstanekstevemar: ? the _gone i assume?22:23
*** edmondsw has joined #openstack-keystone22:23
stevemardstanek: yes22:23
dstanekstevemar: i wanted to make sure nothing would be using the old properties and i'm not sure how to do that22:24
morganrderose: passes tests: https://review.openstack.org/#/c/426384/22:24
dstanekit shouldn't be possible for non-keystone code to use them, but i wasnt sure about keystone code22:25
dstaneki don't trust that the unit tests exercise everythig22:25
*** edmondsw has quit IRC22:28
dstanekdoes oslo.context return the value of ctx.user_id if you access it as ctx.user?22:29
*** PramodJ has joined #openstack-keystone22:31
*** pramodrj07 has quit IRC22:34
openstackgerritDavid Stanek proposed openstack/keystone: Fixes deprecations caused by latest oslo.context  https://review.openstack.org/42641822:37
*** richm has quit IRC22:39
openstackgerritDavid Stanek proposed openstack/keystone: Turn off deprecation -> critical in tests  https://review.openstack.org/42640722:41
*** jaosorior has quit IRC22:42
*** stingaci has joined #openstack-keystone22:42
*** edtubill has quit IRC22:45
*** stingaci has quit IRC22:46
*** jaugustine has quit IRC22:47
*** spotz_zzz is now known as spotz22:48
stevemardstanek: almost done the tests for user lockout as option22:57
stevemardstanek: probably? oslo is pretty good about that22:57
stevemardstanek: https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L25722:58
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate [security_compliance]\password_expires_ignore_user_ids  https://review.openstack.org/42638422:59
morganstevemar: ^ fixed comments23:00
openstackgerritSteve Martinelli proposed openstack/keystone: Create user option `ignore_lockout_failure_attempts`  https://review.openstack.org/42422023:00
dstanekstevemar: yep, already saw that and pushed an update23:00
stevemarmorgan: fixed comments ^23:00
stevemarhehe23:00
stevemar*high five*23:00
*** jperry has quit IRC23:01
*** spilla has quit IRC23:01
morganexcept i messed up pep823:01
morgandamn23:01
stevemarmorgan: i think you need a schema change too23:01
morgani can do that as a followup. i want to make it a two-fold change.23:02
stevemara test in test_v3_identity would have caught that :D23:02
stevemarah23:02
morganeasier to do what i want to do in a followup or two23:04
openstackgerritMorgan Fainberg proposed openstack/keystone: Deprecate [security_compliance]\password_expires_ignore_user_ids  https://review.openstack.org/42638423:04
morganthere we go23:04
morgannot broken pep823:04
openstackgerritMerged openstack/keystone: clean up release notes for ocata  https://review.openstack.org/42609523:06
lbragstadmorgan yes one for you https://review.openstack.org/#/c/426418/223:07
rderosemorgan: back...23:08
harlowjamorgan +1 to ' i think i'll noodle over how we can build something that'll highlight deprecations used'23:08
rderosemorgan: ah good, you got it working23:08
harlowjai think that would be super23:08
harlowjamake a mailing list for deprecations23:08
harlowjathat this thing sends to23:08
harlowjaper-project email highlighting depreciations used (inside or outside of oslo)23:09
harlowja(because depreciations can be done by libraries consumed outside of openstack)23:09
dstanekit would be nice to have something that tests against master of all of our own stuff23:09
dstaneki have to get going in a few to go to a family thing. won't be back for about 90 minutes23:10
harlowjayup, agreed23:12
*** stingaci has joined #openstack-keystone23:13
*** stingaci has quit IRC23:18
*** tqtran has joined #openstack-keystone23:28
morganrderose, stevemar: is there a way to say "this attribute" can be any-type in json-schema?23:30
rderosemorgan: seems reasonable, but haven't done that23:32
morganrderose: looks like not specifying type is sufficient to make that happen23:38
rderosemorgan: nice23:38
rderosemorgan: you'll adding a new patch to add the attribute to the schema23:38
rderose* you'll be23:38
openstackgerritMorgan Fainberg proposed openstack/keystone: Implement better validation for resource options  https://review.openstack.org/42643123:39
morganrderose: ^23:39
morganrderose: i think i need some help building a test case for that.23:40
morganrderose: but ... in short...23:40
morganstevemar: ^ cc see new patch23:40
morganrderose: for the schema stuff covered in the previous patch23:42
*** edmondsw has joined #openstack-keystone23:43
rderosemorgan: ah, cool23:44
*** pramodrj07 has joined #openstack-keystone23:44
*** stingaci has joined #openstack-keystone23:45
*** PramodJ has quit IRC23:48
*** lamt has quit IRC23:49
*** lamt has joined #openstack-keystone23:49
*** stingaci has quit IRC23:50
*** lamt has quit IRC23:54

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!