| bknudson | should have had the mid-cycle in australia | 00:03 |
|---|---|---|
| bknudson | it wasn't on the poll as an option | 00:03 |
| morganfainberg | jamielennox, well crap. it's due to an ancient version of the LDAP lib in OS X | 00:15 |
| morganfainberg | jamielennox, 2.2 | 00:15 |
| morganfainberg | jamielennox, in fact is it the *same* issue as http://projects.skurfer.com/posts/2011/python_ldap_lion/ | 00:15 |
| morganfainberg | which means -- we can't install python-ldap in venvs w/o massive amounts of special manual work. | 00:15 |
| morganfainberg | needs custom include dirs added to setup.cfg | 00:16 |
| morganfainberg | so... i think this is where keystone no longer will run (at least w/ anything LDAP) on OS X | 00:16 |
| jamielennox | bknudson: i have offered that in the past | 00:17 |
| morganfainberg | jamielennox, i'd be for it, but honestly i think you'd have like 3 or 4 people there total | 00:17 |
| jamielennox | bknudson: everyone seemed to think it was too far to travel - which feels somewhat ironic :) | 00:17 |
| morganfainberg | dstanek, ^ but in short, http://projects.skurfer.com/posts/2011/python_ldap_lion/ that issue has resurfaced but worse with later versions of python-ldap | 00:18 |
| jamielennox | morganfainberg: that seems like a bug on there behalf, they should fix that right? if not can't you update the system libs? | 00:18 |
| morganfainberg | dstanek, i would expect LDAP-related tests to become increasingly hard to fix | 00:18 |
| morganfainberg | jamielennox, you can, but it gets harder and harder to maintain. | 00:19 |
| jamielennox | though i try not to mess with the system libraries myself, always breaks things unexpectedly later | 00:19 |
| morganfainberg | jamielennox, exactly | 00:19 |
| jamielennox | you can build them in home and LD_LIBRARY_PATH (i think - wow it's been a while), but yea it might not be worth it | 00:20 |
| morganfainberg | jamielennox, it's DYLD_LIBRARY_PATH on OS X and it gets really wonky | 00:20 |
| morganfainberg | and... | 00:20 |
| morganfainberg | [_ldap] | 00:21 |
| morganfainberg | library_dirs = /usr/local/lib | 00:21 |
| morganfainberg | is in the setup.cfg | 00:21 |
| morganfainberg | well, the fixed one | 00:21 |
| morganfainberg | which means i am skeptical that DYLD_LIBRARY_PATH would even work right | 00:21 |
| morganfainberg | the worst part is the OpenLDAP includes for OS X have been the same since like 2010. never updated - WHAT COULD BE WRONG WITH THAT?! | 00:22 |
| jamielennox | yep, i guess file the bug with apple (no idea how or if they'll respond) but if they fixed it before then this is a regression, surely there are people on an enterprise login scheme that need a newer ldap librray than that | 00:22 |
| morganfainberg | jamielennox, i don't think they fixed it. | 00:23 |
| jamielennox | morganfainberg: right - the other side is to find a security problem in the old library and start exploiting it | 00:23 |
| dstanek | just upgrade to Linux | 00:23 |
| morganfainberg | i think new versions of python-ldap require libs that are newer than ~2009. | 00:23 |
| jamielennox | dstanek: i thought you were a mac user as well? | 00:23 |
| * morganfainberg goes and works to setup vagrant again. | 00:24 | |
| morganfainberg | or some such. | 00:24 |
| dstanek | jamielennox: i was, but Yosemite has tilted me towards hating apple | 00:24 |
| morganfainberg | dstanek, jamielennox - oh this is the *same* issue as OpenSSL w/ apple | 00:24 |
| morganfainberg | dstanek, jamielennox, they have their own OpenDirectory implementation | 00:24 |
| morganfainberg | "use that instead" | 00:24 |
| * morganfainberg facepalms. | 00:24 | |
| jamielennox | apple did there own security libraries? that's hilarious - i never knew that | 00:25 |
| morganfainberg | jamielennox, yeah. | 00:25 |
| morganfainberg | jamielennox, GOTO FAIL - look that one up. the was the SSL bug in their x509 lib this year... | 00:25 |
| morganfainberg | or last year | 00:25 |
| jamielennox | oh yea, i remember that | 00:26 |
| morganfainberg | jamielennox, part of it is because IOS doesn't have the same framework/libs, they want to make OS X and IOS development similar | 00:26 |
| morganfainberg | unfortunately, Objective-C is the answer there | 00:26 |
| jamielennox | and openssl and nss are terrible to work with | 00:27 |
| morganfainberg | and OpenSSL doesn't exactly inspire confidence at this point either | 00:27 |
| dstanek | morganfainberg: Objective-C is never the answer. you must be asking the wrong question :-) | 00:29 |
| morganfainberg | dstanek, or asking Apple. | 00:29 |
| morganfainberg | dstanek, i agree with you. Apple doesn't :P | 00:29 |
| bknudson | Looks like keystoneclient / keystonemiddleware are broken because of some issue in icehouse tests | 00:32 |
| *** dimsum__ has joined #openstack-keystone | 00:35 | |
| jamielennox | bknudson: yea, i thought they had fixed it | 00:35 |
| jamielennox | bknudson: i put a recheck on the most recent failure - i hvaen't seen the result | 00:36 |
| jamielennox | bknudson: would appreciate reviews on https://review.openstack.org/#/c/130532/ anyway - it's essentially the same as i had you reviewing before but i squashed the subsequent patch into it | 00:37 |
| jamielennox | bknudson: some of the changes that were being asked for were going to be immediately changed again anyway | 00:37 |
| bknudson | no real point to reviewing anything if it can't be merged. | 00:37 |
| jamielennox | bknudson: these patches have been around for weeks - if that bug is the only thing preventing it being merged i'll be overjoyed | 00:38 |
| boris-42 | morganfainberg: ping | 00:54 |
| *** ncoghlan has joined #openstack-keystone | 01:14 | |
| *** lhcheng has quit IRC | 01:24 | |
| *** dimsum__ has quit IRC | 01:31 | |
| *** dimsum__ has joined #openstack-keystone | 01:31 | |
| *** NM has joined #openstack-keystone | 01:34 | |
| *** dimsum__ has quit IRC | 01:36 | |
| *** diegows has quit IRC | 01:36 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Correct typos in man page https://review.openstack.org/127685 | 01:39 |
| *** stevemar has joined #openstack-keystone | 01:44 | |
| *** ChanServ sets mode: +v stevemar | 01:44 | |
| openstackgerrit | Merged openstack/keystone: Remove duplicate setup logic in federation tests https://review.openstack.org/133158 | 01:44 |
| *** dimsum__ has joined #openstack-keystone | 01:54 | |
| *** stevemar has quit IRC | 02:10 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 02:12 | |
| *** tellesnobrega_ has joined #openstack-keystone | 02:20 | |
| *** lhcheng has joined #openstack-keystone | 02:24 | |
| *** lhcheng has quit IRC | 02:28 | |
| *** erkules_ has joined #openstack-keystone | 02:30 | |
| *** erkules has quit IRC | 02:33 | |
| *** NM has quit IRC | 02:42 | |
| *** KanagarajM has joined #openstack-keystone | 03:04 | |
| *** fifieldt has joined #openstack-keystone | 03:19 | |
| *** dimsum__ has quit IRC | 03:27 | |
| *** erkules_ is now known as erkules | 03:30 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 03:45 | |
| *** boris-42 has quit IRC | 03:57 | |
| morganfainberg | dstanek, ping - some metaprogramming for you to eyeball | 03:57 |
| morganfainberg | dstanek: http://paste.openstack.org/show/137154/ | 03:57 |
| morganfainberg | dstanek, here would be some quick testing of it (interactive): | 03:58 |
| morganfainberg | dstanek, http://paste.openstack.org/show/137155/ | 03:58 |
| dstanek | morganfainberg: trying to match signatures along with method names? | 03:59 |
| morganfainberg | dstanek, yeah | 03:59 |
| dstanek | does that break with decorators? | 04:00 |
| morganfainberg | dstanek, hm. good question | 04:00 |
| morganfainberg | dstanek, i think i need to dig into the decorator underpinnings in that case. | 04:00 |
| morganfainberg | dstanek, this is my first pass of how to handle "is this token provider actually going to work" | 04:01 |
| morganfainberg | the other thing i was contemplating was using the .register for the ABC for the driver | 04:01 |
| morganfainberg | make this instead of strict_abstract a special metaclass for the provider... | 04:01 |
| morganfainberg | s/provider/driver | 04:01 |
| morganfainberg | ah .register wont actually force __new__ to be called. | 04:03 |
| morganfainberg | dstanek, yep, fails with decorators atm. | 04:06 |
| morganfainberg | but it shouldn't if functools.wraps is used. | 04:13 |
| morganfainberg | (properly) | 04:13 |
| morganfainberg | i think | 04:13 |
| morganfainberg | *this* might be the solution: https://pypi.python.org/pypi/decorator | 04:19 |
| jamielennox | morganfainberg: if you're doing down that route use wrapt | 04:26 |
| *** dimsum__ has joined #openstack-keystone | 04:27 | |
| morganfainberg | jamielennox, same concept, a little less friendly UX, a lot more functionality | 04:28 |
| jamielennox | morganfainberg: well i know that he didn't start off to write a decorator module, he wanted something that would exactly proxy from one object to another, so if you have any issues with wrapt and arg parsing or whatever then that's a wrapt bug | 04:29 |
| *** dimsum__ has quit IRC | 04:32 | |
| jamielennox | also i love the way wrapt handles optional arguments to decorators | 04:35 |
| *** aix has quit IRC | 04:36 | |
| *** ajayaa has joined #openstack-keystone | 04:41 | |
| *** boris-42 has joined #openstack-keystone | 04:42 | |
| *** junhongl has quit IRC | 05:06 | |
| *** junhongl has joined #openstack-keystone | 05:08 | |
| *** ncoghlan is now known as ncoghlan_afk | 05:22 | |
| *** stevemar has joined #openstack-keystone | 05:42 | |
| *** ChanServ sets mode: +v stevemar | 05:42 | |
| *** ncoghlan_afk is now known as ncoghlan | 05:48 | |
| *** k4n0 has joined #openstack-keystone | 06:00 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex https://review.openstack.org/136243 | 06:05 |
| *** ukalifon1 has joined #openstack-keystone | 06:33 | |
| *** tellesnobrega_ has quit IRC | 06:37 | |
| *** raildo has quit IRC | 06:46 | |
| *** boris-42 has quit IRC | 06:47 | |
| openstackgerrit | Sridhar Gaddam proposed openstack/python-keystoneclient: Curl statements to include globoff for IPv6 URLs https://review.openstack.org/136327 | 06:48 |
| *** afazekas has joined #openstack-keystone | 07:01 | |
| *** raildo has joined #openstack-keystone | 07:03 | |
| *** stevemar has quit IRC | 07:16 | |
| *** bjornar has quit IRC | 07:35 | |
| openstackgerrit | Marek Denis proposed openstack/keystone-specs: Yet another WebSSO spec https://review.openstack.org/136610 | 07:35 |
| marekd|away | dolphm: and how was you moka? | 07:37 |
| *** marekd|away is now known as marekd | 07:37 | |
| *** kobtea has joined #openstack-keystone | 07:43 | |
| *** ncoghlan has quit IRC | 07:59 | |
| *** KanagarajM has quit IRC | 08:19 | |
| *** bjornar has joined #openstack-keystone | 08:22 | |
| *** ukalifon1 has quit IRC | 08:24 | |
| *** jistr has joined #openstack-keystone | 08:55 | |
| *** ukalifon has joined #openstack-keystone | 09:04 | |
| *** viktors has joined #openstack-keystone | 09:06 | |
| *** lhcheng has joined #openstack-keystone | 09:34 | |
| *** kobtea has quit IRC | 09:38 | |
| *** lhcheng_ has joined #openstack-keystone | 09:54 | |
| *** dimsum__ has joined #openstack-keystone | 09:54 | |
| *** lhcheng has quit IRC | 09:56 | |
| *** dimsum__ has quit IRC | 09:59 | |
| *** boris-42 has joined #openstack-keystone | 10:01 | |
| *** aix has joined #openstack-keystone | 10:13 | |
| openstackgerrit | Marek Denis proposed openstack/keystone-specs: Service Provider for K2K https://review.openstack.org/135604 | 10:16 |
| *** f13o has quit IRC | 10:26 | |
| *** f13o has joined #openstack-keystone | 10:31 | |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Split the assignments manager/driver. https://review.openstack.org/130954 | 10:50 |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend https://review.openstack.org/102244 | 10:50 |
| *** bdossant has joined #openstack-keystone | 11:01 | |
| *** viktors is now known as viktors|afk | 11:09 | |
| *** amakarov_away is now known as amakarov | 11:13 | |
| openstackgerrit | Lin Hua Cheng proposed openstack/keystone: Always return the service name in the catalog https://review.openstack.org/135808 | 11:26 |
| *** NM has joined #openstack-keystone | 11:33 | |
| *** dimsum__ has joined #openstack-keystone | 12:03 | |
| afaranha | Hello, I submitted a spec proposing to change the policy, could you read and give comments? https://review.openstack.org/#/c/135408/ | 12:13 |
| afaranha | Haneef, bknudson, morganfainberg could you review? | 12:13 |
| openstackgerrit | Boris Pavlovic proposed openstack/keystone: Test authenticate (DO NOT MERGE) https://review.openstack.org/136485 | 12:14 |
| *** kobtea has joined #openstack-keystone | 12:39 | |
| *** kobtea has quit IRC | 12:44 | |
| ekarlso- | jamielennox: you around ? :) | 12:53 |
| *** k4n0 has quit IRC | 13:00 | |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: Speed up memcache lock https://review.openstack.org/136749 | 13:06 |
| *** elynn has joined #openstack-keystone | 13:21 | |
| *** kobtea has joined #openstack-keystone | 13:23 | |
| *** jraim has quit IRC | 13:24 | |
| *** serverascode___ has quit IRC | 13:24 | |
| *** zhiyan has quit IRC | 13:24 | |
| *** jraim has joined #openstack-keystone | 13:25 | |
| *** boris-42 has quit IRC | 13:25 | |
| *** boris-42 has joined #openstack-keystone | 13:26 | |
| *** serverascode___ has joined #openstack-keystone | 13:27 | |
| *** zhiyan has joined #openstack-keystone | 13:27 | |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Correct token flush logging https://review.openstack.org/131003 | 13:27 |
| *** joesavak has joined #openstack-keystone | 13:35 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:38 | |
| boris-42 | bknudson: hi there | 13:41 |
| *** thiagop has quit IRC | 13:41 | |
| *** ayoung has joined #openstack-keystone | 13:41 | |
| *** ChanServ sets mode: +v ayoung | 13:41 | |
| *** diegows has joined #openstack-keystone | 13:46 | |
| *** elynn has left #openstack-keystone | 13:49 | |
| *** pc-m has joined #openstack-keystone | 13:54 | |
| *** gordc has joined #openstack-keystone | 13:54 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Scope federated token with 'token' identity method https://review.openstack.org/130593 | 14:00 |
| *** dimsum__ has quit IRC | 14:01 | |
| *** dimsum__ has joined #openstack-keystone | 14:02 | |
| *** ukalifon has quit IRC | 14:06 | |
| *** ukalifon2 has joined #openstack-keystone | 14:06 | |
| *** nkinder has quit IRC | 14:10 | |
| *** diegows has quit IRC | 14:11 | |
| *** richm has joined #openstack-keystone | 14:15 | |
| *** richm has quit IRC | 14:17 | |
| *** tellesnobrega has quit IRC | 14:19 | |
| *** tellesnobrega has joined #openstack-keystone | 14:19 | |
| *** lhcheng_ is now known as lhcheng | 14:24 | |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend https://review.openstack.org/102244 | 14:26 |
| boris-42 | ayoung: around? | 14:28 |
| ayoung | boris-42, nah, I'm more oblong | 14:28 |
| ayoung | Fairly squarish | 14:28 |
| boris-42 | ayoung: I am really worried about this stuff http://logs.openstack.org/85/136485/3/check/gate-rally-dsvm-keystone/93012ee/rally-plot/results.html.gz#/Authenticate.keystone#overview | 14:28 |
| boris-42 | ayoung: I mean you can't run 50 authentication per second | 14:29 |
| ayoung | boris-42, any idea what the bottleneck is? | 14:29 |
| boris-42 | ayoung: as far as I know we are using sql backend in dsvm jobs? | 14:30 |
| ayoung | and> | 14:30 |
| ayoung | and? | 14:30 |
| boris-42 | ayoung: I think that bottlneck is issue | 14:30 |
| boris-42 | ayoung: we were getting in our Mirantis scale lab issues with memchaced backend | 14:30 |
| boris-42 | ayoung: without this patch https://review.openstack.org/136749 | 14:30 |
| boris-42 | ayoung: I need to integrate osprofiler & rally finally, so I'll get traces under load | 14:31 |
| ayoung | boris-42, so the problem is storing tokens to the database? | 14:31 |
| boris-42 | ayoung: or some lock* inside keystone backend | 14:32 |
| ayoung | boris-42, then the real issue is getting us off the SQL backend. Which means revocation events | 14:32 |
| *** bdossant has quit IRC | 14:33 | |
| ayoung | boris-42, Here's the deal. Only the SQL backend survives a reboot. Which means that only the SQL backend is viable right now | 14:35 |
| ayoung | with UUID tokens, memcached would be fine | 14:35 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Authenticated Encryption Tokens https://review.openstack.org/130050 | 14:35 |
| ayoung | its only PKIZ tokens that require explicit revocation | 14:35 |
| ayoung | UUID tokens, if you dump the memcache backend, are just all invalidated | 14:35 |
| ayoung | so, for now, when UUID tokens are enabled, use memcached, and you are OK | 14:36 |
| ayoung | meanwhile, we are trying to get tokens ephemeral, PKIZ, AE, whatever the approach. In order to do that, we need a persisted store we can trust for revocation events | 14:36 |
| boris-42 | ayoung: nope | 14:38 |
| boris-42 | ayoung: you are not OK without https://review.openstack.org/136749 | 14:38 |
| boris-42 | ayoung: keystone is DDOSed by other projects | 14:38 |
| boris-42 | ayoung: this is one of bottlencks | 14:38 |
| ayoung | boris-42, Ah, so the issue is memcached locking as well? | 14:39 |
| ayoung | boris-42, so instead of catastrophic failback, use random.... | 14:39 |
| boris-42 | ayoung: it's separated issue* But in FUEL we are deploying with memchaced. And testing at middle-scale (200 servers installation) | 14:39 |
| *** htruta has quit IRC | 14:40 | |
| amakarov | ayoung, boris-42 hi! Let me explain this: in concurrent environment if memcache lock attempt hits 8 subsequent a collisions then overall waiting time ~108sec => 504 Time out | 14:40 |
| boris-42 | ayoung: so we tested this fix in more or less real life situation. But sseems like SQL backend has much lower perf | 14:40 |
| ayoung | amakarov, I get it | 14:41 |
| ayoung | the failures happen in lockstep | 14:41 |
| ayoung | the random timeout makes more sense | 14:41 |
| ayoung | reminds me of flow control issues in TCP | 14:41 |
| boris-42 | ayoung: but SQL backend is different story. I'll try during Kilo release cycle to get Rally & OSprofiler integrated so we will be able to analyze in more details | 14:41 |
| ayoung | boris-42, thanks. | 14:42 |
| ayoung | boris-42, I'd like to get rid of the SQL backend. The more justification you can give me for that, the better | 14:42 |
| boris-42 | ayoung: ya seems like it's quite useless for any non dev installtion | 14:42 |
| amakarov | ayoung, https://blueprints.launchpad.net/keystone/+spec/redis-storage-backend :) | 14:43 |
| amakarov | A question: does it need a spec? | 14:43 |
| ayoung | lbragstad, So what do you think of an implementation that merges AE tokens with PKI? PKI-AE-Z. Usese the compressed formate instead of JSON for the inner document? | 14:43 |
| ayoung | amakarov, I thought redis was already supported | 14:43 |
| amakarov | ayoung, not everywhere | 14:44 |
| ayoung | amakarov, for the token backend it is. I wouldn't use it for a caching mechanism, but we have other issues there | 14:44 |
| amakarov | ayoung, as a cache - yes, as a storage - no | 14:44 |
| ayoung | amakarov, where do you want to use redis? I thought tokens in redis was a done deal? | 14:45 |
| amakarov | ayoung, actually, I haven't find Token persistence backend. Generic kvs only | 14:46 |
| ayoung | amakarov, nah, the Dogpile stuff works for multiple stores. We inherited redis up front. ask morganfainberg once he's awake and gotten coffee | 14:47 |
| amakarov | ayoung, btw, why trusts don't use kvs? | 14:47 |
| amakarov | ayoung, there are sql backend only | 14:48 |
| ayoung | amakarov, trusts need to be persisted. I guess you would just have invalid trusts without....I didn't implement, but I wouldn't object if someone else did. | 14:48 |
| ayoung | Just time constraint | 14:48 |
| amakarov | ayoung, I see, so it's ok if I make a redis backend for trusts too? | 14:49 |
| *** htruta has joined #openstack-keystone | 14:49 | |
| ayoung | really didn't expect them to be a scalability constraint, but if they are starting to become one, a KVS impl should be trivial | 14:49 |
| ayoung | yes. I think that makes sense, but make sure they don't time out | 14:49 |
| ayoung | trusts are inherently long lived | 14:49 |
| ayoung | memcached style "dump old records if you are full" will not cut it for trusts | 14:50 |
| *** thedodd has joined #openstack-keystone | 14:50 | |
| amakarov | ayoung, thanks, and what about that extra LDAP attributes issue? AFAIK we want separate rw LDAP, right? | 14:51 |
| lbragstad | ayoung: I'm not sure, I guess I'd have to think about that one for a bit | 14:51 |
| lbragstad | to work everything out | 14:52 |
| lbragstad | dstanek: around? | 14:52 |
| *** ukalifon2 has quit IRC | 14:53 | |
| *** Ctina has joined #openstack-keystone | 14:53 | |
| amakarov | ayoung, https://review.openstack.org/#/c/118590/ - it was -1'ed long ago, can we reanimate it somehow? :) | 14:54 |
| *** nkinder has joined #openstack-keystone | 14:54 | |
| marekd | dstanek: lbragstad any news on functional testing and federation testsuite in Jenkins ? | 14:59 |
| lbragstad | marekd: I've been meaning to respond to you note | 14:59 |
| lbragstad | s/you/your/ | 15:00 |
| marekd | note == e-mail? | 15:00 |
| lbragstad | yes | 15:00 |
| marekd | lbragstad: please, do | 15:00 |
| lbragstad | I apologize that it's taking me a bit | 15:00 |
| marekd | lbragstad: no worries. | 15:01 |
| *** ukalifon has joined #openstack-keystone | 15:01 | |
| ayoung | amakarov, I don;t think bknudson 's concerns have been met. It needs a rework to avoid breaking existing deployments | 15:01 |
| marekd | joesavak: i need your opinion on 'alternatives' section in https://review.openstack.org/#/c/135604/ | 15:02 |
| ayoung | lbragstad, one of the things you are doing is coming up with a minimal, non-json format for the token data. That is viable for any transportation mechanism, not just AE | 15:02 |
| marekd | rodrigods: https://review.openstack.org/#/c/135604/ | 15:02 |
| lbragstad | ayoung: would the entire service catalog be in that format then? | 15:03 |
| ayoung | lbragstad, I don't think so. I think we can find other ways to deal with service catalog, most notably fetching out of band and caching | 15:03 |
| marekd | ayoung: +++ | 15:03 |
| marekd | dstanek: i need some help: https://review.openstack.org/#/c/130593/2/keystone/tests/test_v3_federation.py this new class is 2 levels down from a class that is decorated with dependency.requires('federation_api') yet all the tests regarding this class complain about missing federation_api . Could you take a look and help me resolving this mystery? | 15:06 |
| marekd | dstanek: the console output is here: https://jenkins05.openstack.org/job/gate-keystone-python27/1916/console | 15:06 |
| marekd | dstanek: the class 1-level down utilizes federation_api successfully | 15:07 |
| zhiyan | ayoung: rodrigods hi folks, hope this one fit all we need on it: https://review.openstack.org/#/c/128881/6 :) when/if you ok, pls let me know your thoughts, thanks! | 15:08 |
| ayoung | zhiyan, OK, so, I was thinking this through over the weekend. I think maybe we are missing a key factor. Is it the policy that should vary *per-object* or attributes from the object that are needed to enforce policy? | 15:10 |
| ayoung | I think the changes alone are probably OK, but I am not certain we are actually solving the problem | 15:11 |
| zhiyan | ayoung: i'm sure think fix could solving the problem which currently i'm handling for glance adoption. | 15:11 |
| zhiyan | ayoung: any thing i missed? | 15:12 |
| ayoung | zhiyan, please answer my question. I am concerned about multi-access cases, which you will probably not see in your testing | 15:12 |
| zhiyan | ayoung: i'm not fully understand your question tbh | 15:13 |
| ayoung | zhiyan, I am not sure I can make it clearer.... | 15:13 |
| zhiyan | ayoung: actually i have some thougths on this as well during my weedend work | 15:13 |
| ayoung | zhiyan, you shouldn't need to reload rules | 15:13 |
| zhiyan | weekend* | 15:13 |
| ayoung | I think that glance is doing it because it has per-object policy | 15:14 |
| zhiyan | ayoung: why we don't need reload logic | 15:14 |
| zhiyan | per-object policy? you mean per-image? or something like that | 15:14 |
| zhiyan | ayoung: under my understanding, under current design, if policy config files got changed, then next enforce() call should reload these new rules from these changed files. | 15:15 |
| ayoung | zhiyan, yes, per image | 15:15 |
| zhiyan | ayoung: no, we haven't pre-image policy | 15:16 |
| zhiyan | we have some in-fly policy which built on code, but when glance get started then rules are not changed | 15:17 |
| ayoung | zhiyan, If I understand what is going on, there are layers of policies here. There is the policy.json file, and something else that dynamically creates policy. Where does that dynamic policy come from? | 15:17 |
| zhiyan | when an image get request in, these rules are applied on that image | 15:17 |
| zhiyan | image are changing by each request, but rules are static (for each req) | 15:17 |
| ayoung | explain to me how the " in-fly policy which built on code" get built | 15:17 |
| zhiyan | ayoung: 1 sec, let me show you some code | 15:18 |
| zhiyan | https://github.com/openstack/glance/blob/master/glance/common/property_utils.py#L67 | 15:18 |
| zhiyan | & L159 | 15:18 |
| zhiyan | ayoung: ^ | 15:18 |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: LDAP additional attribute mappings description https://review.openstack.org/118590 | 15:18 |
| zhiyan | ayoung: that code build these dynamic policies | 15:19 |
| marekd | can i ask for some reviews: https://review.openstack.org/#/c/135604/ ? | 15:19 |
| ayoung | zhiyan, I think it would make more sense to reapply those rules after a reload. | 15:19 |
| ayoung | If you reload the file from disk, dump all the old rules, then reapply the file based ones, and the code ones afterwards | 15:20 |
| zhiyan | ayoung: we could applied these before or after, but i think from policy module's POV, it would be better to support both | 15:20 |
| zhiyan | ayoung: and imo, currently glance domain design is good to me | 15:21 |
| ayoung | zhiyan, maybe. I'd also have to think what kind of conflict resolution we should have if the policy.json and the auto-rules don't agree. | 15:21 |
| ayoung | I'll give you review another look in a bit. Got to step away for a moment. | 15:22 |
| *** ayoung is now known as ayoung-afk | 15:22 | |
| *** r-daneel has joined #openstack-keystone | 15:22 | |
| *** thedodd has quit IRC | 15:22 | |
| *** aix has quit IRC | 15:22 | |
| zhiyan | ayoung-afk: ok, looking forward to see, thanks again | 15:22 |
| *** stevemar has joined #openstack-keystone | 15:25 | |
| *** ChanServ sets mode: +v stevemar | 15:25 | |
| *** Ctina has quit IRC | 15:26 | |
| *** Ctina has joined #openstack-keystone | 15:27 | |
| *** joesavak has quit IRC | 15:30 | |
| *** dimsum__ is now known as dims | 15:32 | |
| *** NM has quit IRC | 15:37 | |
| *** NM has joined #openstack-keystone | 15:40 | |
| dstanek | marekd: still having that issue? | 15:41 |
| dstanek | marekd: ah, you need an empty __init__ or the deps won't get injected | 15:42 |
| marekd | dstanek: i will try | 15:43 |
| marekd | thanks. | 15:43 |
| marekd | dstanek: how was not happening in classes 1-level down ? | 15:43 |
| bknudson | which review? | 15:43 |
| marekd | bknudson: 1 sec | 15:43 |
| marekd | bknudson: https://review.openstack.org/#/c/130593/ | 15:43 |
| dstanek | marekd: what class does it work for? | 15:44 |
| bknudson | I've got some fixes to the tests that might fix this... | 15:45 |
| bknudson | marekd: See https://review.openstack.org/#/c/124603/ ( dstanek ) | 15:46 |
| bknudson | I got rid of all the @dependency.requires in the tests. | 15:46 |
| bknudson | tests shouldn't be using dependency.requires. | 15:47 |
| marekd | dstanek: FederatedTokenTests | 15:47 |
| marekd | line 770 | 15:47 |
| dstanek | bknudson: ++, DI is runtine and not test time | 15:47 |
| bknudson | marekd: I bet if you rebase on https://review.openstack.org/#/c/124603/ it will work. | 15:47 |
| marekd | bknudson: i will do so | 15:47 |
| *** ukalifon has quit IRC | 15:48 | |
| *** ayoung-afk is now known as ayoung | 15:53 | |
| *** zzzeek has joined #openstack-keystone | 15:56 | |
| *** kobtea has quit IRC | 16:10 | |
| *** kobtea has joined #openstack-keystone | 16:10 | |
| *** chrisshattuck has joined #openstack-keystone | 16:12 | |
| *** kobtea has quit IRC | 16:15 | |
| morganfainberg | dstanek: so we would need to move to wrapt or decorator to use that sig validating metaclass | 16:21 |
| morganfainberg | Otherwise it does what I'm looking for. I have an alternative, that would error at runtime instead of at compile time as well. | 16:22 |
| dstanek | morganfainberg: we could get rid of decorators! | 16:35 |
| morganfainberg | dstanek: where we can't I like the idea of using something like wrapt | 16:36 |
| morganfainberg | ;) | 16:37 |
| dstanek | wrapt is interesting, but i've never used it | 16:37 |
| bknudson | any other openstack projs using wrapt? | 16:38 |
| bknudson | must be, it's in global-requirements | 16:38 |
| morganfainberg | So if we do something like this, that is enforce the method signature for certain plugin interfaces... Do we want at compile time or runtime? | 16:38 |
| morganfainberg | Runtime is a bit less spooky / metaclass Magic. | 16:39 |
| morganfainberg | Runtime = object instantistion. | 16:40 |
| morganfainberg | bknudson: I think we should probably look at wrapt in general for our decorators if it's already in global reqs. | 16:40 |
| *** NM has quit IRC | 16:41 | |
| *** david-lyle_afk is now known as david-lyle | 16:41 | |
| *** _cjones_ has joined #openstack-keystone | 16:48 | |
| *** afazekas has quit IRC | 16:54 | |
| *** NM has joined #openstack-keystone | 16:55 | |
| afaranha | Hello, I submitted a spec proposing to change the policy, could you read and give comments? https://review.openstack.org/#/c/135408/ | 16:56 |
| afaranha | Haneef, bknudson, morganfainberg, ayoung could you review? | 16:56 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Fix tests using extension drivers https://review.openstack.org/124603 | 16:56 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Avoid multiple instances for a provider https://review.openstack.org/124599 | 16:56 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Add missing translation marker for depenency https://review.openstack.org/136824 | 16:56 |
| bknudson | I'd never heard of wrapt before today and now it's everywhere: https://review.openstack.org/#/c/135903/ -- "recheck wrapt failure should be resolved" | 16:59 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Add missing translation marker for dependency https://review.openstack.org/136824 | 17:03 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Fix tests using extension drivers https://review.openstack.org/124603 | 17:03 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Avoid multiple instances for a provider https://review.openstack.org/124599 | 17:03 |
| *** kobtea has joined #openstack-keystone | 17:12 | |
| stevemar | bknudson, oh took me a while to figure out that what you linked in https://review.openstack.org/#/c/131663/ wasn't what was merged | 17:12 |
| *** spligak has quit IRC | 17:13 | |
| bknudson | stevemar: dolphm didn't like it | 17:13 |
| *** radez_g0n3 is now known as radez | 17:13 | |
| bknudson | I thought it was super clever | 17:13 |
| stevemar | dstanek, bknudson so lack of id's in the templated catalog - server's problem or clients/consumers should be smarter? | 17:13 |
| bknudson | stevemar: what does the spec say? | 17:14 |
| stevemar | bknudson, making id the be region_name-service_name would address dstanek's concern | 17:14 |
| dstanek | stevemar: bknudson: i think it's a server problem; | 17:14 |
| stevemar | bknudson, doesn't say anything specifically about templated | 17:14 |
| bknudson | they <region_name>-<service_name> might not be unique either | 17:14 |
| stevemar | region_id would be | 17:15 |
| bknudson | can I put the ID in the template? | 17:15 |
| dstanek | can we force people to add IDs in the template? | 17:15 |
| bknudson | get out of my brain. | 17:15 |
| dstanek | get out of mine! | 17:16 |
| stevemar | we're all a part of the collective now anyway | 17:16 |
| *** edmondsw has joined #openstack-keystone | 17:16 | |
| stevemar | so ID's in templates works, that actually how are test data is | 17:16 |
| *** kobtea has quit IRC | 17:16 | |
| stevemar | https://github.com/openstack/keystone/blob/c4c8d0b99a0404f4dcdb2f87c48fe15ee1526197/keystone/tests/default_catalog.templates | 17:17 |
| stevemar | but the one we advertise does not contain that ... https://github.com/openstack/keystone/blob/c4c8d0b99a0404f4dcdb2f87c48fe15ee1526197/etc/default_catalog.templates | 17:17 |
| bknudson | that's not the endpoint id? | 17:17 |
| bknudson | that's the service id | 17:18 |
| stevemar | it's the service id | 17:18 |
| ayoung | "Dear Glance, What are you doing. Sincerly, Adam Young." https://github.com/openstack/glance/blob/master/glance/common/property_utils.py#L67 and https://github.com/openstack/glance/blob/master/etc/property-protections-policies.conf.sample | 17:18 |
| stevemar | bknudson, i think the lack of a service id is still an issue | 17:18 |
| ayoung | zhiyan, why are the two patterns: [^x_.*] and [.*] | 17:19 |
| bknudson | maybe we could support catalog.RegionOne.identity.publicURL.id , too? | 17:19 |
| ayoung | It looks to me like you are doing regular expressions inside Oslo config headers. "That might be the worst thing I've ever heard. How marvelous." | 17:20 |
| ayoung | order of processing matters, too | 17:20 |
| ayoung | [.*] actually will match anything matched by [^x_.*] | 17:21 |
| ayoung | If I read that correctly, Glance is using Python code to read in regular expresssions from an oslo-config managed file that has regular expressions as the section headers. It then generates policy to protect individual properties on glance images. | 17:22 |
| afaranha | ayoung: As I understood if the rules match [^x_.*] it will stop without looking the [.*] | 17:23 |
| afaranha | I still didn't understand this feature though | 17:23 |
| ayoung | afaranha, I think they got lucky | 17:23 |
| ayoung | afaranha, it only works because of ASCII ording | 17:24 |
| ayoung | quick, which has a lower ascii values . or ^ ? | 17:24 |
| afaranha | I think ^ | 17:24 |
| ayoung | afaranha, I would not bet against you | 17:25 |
| ayoung | But then, I don't take bets that I think I am not going to win | 17:25 |
| afaranha | I don't know, I just searching now :P | 17:25 |
| *** joesavak has joined #openstack-keystone | 17:25 | |
| ayoung | http://www.asciitable.com/ | 17:25 |
| afaranha | ayoung: . | 17:25 |
| ayoung | . =46 | 17:25 |
| ayoung | ^ = 94 | 17:26 |
| ayoung | afaranha, then maybe order from the file is maintained | 17:26 |
| ayoung | I thought it was put into a dictionary. Which means it might be the hash value of the string that determines the ordering | 17:26 |
| openstackgerrit | Alexander Makarov proposed openstack/keystone: LDAP additional attribute mappings description https://review.openstack.org/118590 | 17:26 |
| afaranha | ayoung: So, If I put [.*] first and [^x_.*] next, then this order will not be respected | 17:27 |
| stevemar | bknudson, i think that would be the simplest fix | 17:27 |
| ayoung | afaranha, I'll say "possibly" | 17:27 |
| ayoung | since I don;t really know | 17:27 |
| ayoung | what they are looking for, IIUC, is for the .* rule to be the deafult | 17:27 |
| ayoung | default | 17:27 |
| stevemar | bknudson, how would that affect existing deployments? | 17:27 |
| afaranha | If it's a hash, then it could be | 17:27 |
| ayoung | and [^x_.*] an explicit match | 17:28 |
| afaranha | ayoung: Let me check the implementation | 17:28 |
| ayoung | afaranha, and let me think about how this should actually work.... | 17:28 |
| ayoung | afaranha, the default rule in glance is also defined outside that file | 17:28 |
| ayoung | "default": "", | 17:29 |
| ayoung | "context_is_admin": "role:admin", | 17:29 |
| stevemar | bknudson, dstanek if we doc it, and tell folks to add id's to their templatedcatalog, they can edit the file, then the next time they restart keystone it'll have the correct data? | 17:29 |
| ayoung | which means that for any policy points that are not defined, no RBAC or other attributes get checked | 17:29 |
| afaranha | but the rules in the property-protections-policies.conf.sample doesn't cover this? | 17:30 |
| ayoung | afaranha, not that it references is_admin and defaul | 17:30 |
| ayoung | t | 17:30 |
| afaranha | ayoung: If I have this file with the rule [.*] it will only apply to those rules not specified on the policy, or for all the rules? | 17:31 |
| ayoung | afaranha, I have no idea | 17:31 |
| *** ajayaa has quit IRC | 17:31 | |
| ayoung | afaranha, this is beyond what normal policy does. I suspect it does not get applied | 17:31 |
| ayoung | rather | 17:31 |
| afaranha | Do you have the spec, or blueprint for this? I didn't get the idea yet | 17:31 |
| ayoung | afaranha, Let me pull it up | 17:32 |
| ayoung | afaranha, https://github.com/openstack/glance/commit/eb87f1fae8f13c7ab09c9fec56bbfa1fdfdf17fc | 17:33 |
| ayoung | https://review.openstack.org/#/c/48076/ | 17:33 |
| ayoung | https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection | 17:35 |
| *** dims has quit IRC | 17:35 | |
| afaranha | So, they want to define rules outside the policy. Say that I want a user to be able to read all information of the cloud without updating it | 17:35 |
| *** dims has joined #openstack-keystone | 17:35 | |
| *** NM has quit IRC | 17:38 | |
| afaranha | ayoung: Oh, it's from 2013. I don't think a good idea to have enforcement information in 2 different places, they might have a good reason for this | 17:38 |
| *** NM has joined #openstack-keystone | 17:39 | |
| *** dims has quit IRC | 17:40 | |
| *** carlosmarin has joined #openstack-keystone | 17:42 | |
| *** mikedillion has joined #openstack-keystone | 17:44 | |
| amakarov | ayoung, about trust redelegation, can you please review the spec? https://review.openstack.org/#/c/131541/ I need it to get redelegation accepted and continue working on it | 17:44 |
| *** DavidHu has quit IRC | 17:46 | |
| *** dims has joined #openstack-keystone | 17:48 | |
| *** ajayaa has joined #openstack-keystone | 17:50 | |
| *** jorge_munoz has joined #openstack-keystone | 17:51 | |
| *** harlowja_away is now known as harlowja | 17:52 | |
| *** mikedillion has quit IRC | 17:54 | |
| morganfainberg | lbragstad, yay! XML No-More! | 17:55 |
| sigmavirus24 | xml-off, your industrial strength xml remover and json polishing agent | 17:57 |
| morganfainberg | amakarov, ayoung, is there a reason to make the redelgation count configurable? | 17:58 |
| morganfainberg | amakarov, ayoung, i'm thinking we should just say "can be re-delegated" and it does redelgation_count = --current_count | 17:59 |
| morganfainberg | amakarov, ayoung, the only reason for a max-depth of redelegation is to help limit the expensive lookups. | 17:59 |
| *** wwriverrat has joined #openstack-keystone | 18:00 | |
| *** wwriverrat has left #openstack-keystone | 18:01 | |
| dstanek | stevemar: will those IDs come out in the right place? | 18:02 |
| ayoung | morganfainberg, it needs to be there | 18:03 |
| ayoung | I want to delegate to solum, which delegates to heat, which delegates to Nova | 18:03 |
| amakarov | morganfainberg, I can imagine the case: I want to restrict redelegation depth to, say, 3 instead of default 5 in fear that my trust may be redelegated to somebody I don't know and I want him to act on my behalf, but further redelegation is not necessary | 18:03 |
| ayoung | Nova should not be able to delegate further | 18:03 |
| morganfainberg | i'm looking at the current UX and it's kindof... bad. | 18:04 |
| ayoung | afaranha, they match property names | 18:04 |
| ayoung | so the rule ^x_.* matches all propertues that start with x_ | 18:04 |
| amakarov | ayoung provided more clear case ) | 18:04 |
| morganfainberg | ayoung, i think the issue here is you can't know solum will delegate to heat then nova and not need to then delegate to cinder | 18:05 |
| ayoung | amakarov, at a quick look it appears correct | 18:05 |
| ayoung | morganfainberg, it is optional, but limiting the number of redelegations will help us avoid a class of attacks | 18:06 |
| morganfainberg | i'm getting the feeling that this is either a "you can redelegate" or you "can't" | 18:06 |
| morganfainberg | ayoung, my issue is the UX is weird. especially that in the middle of a chain i could in theory reduce the amount of redelegation | 18:07 |
| amakarov | morganfainberg, ++ | 18:07 |
| morganfainberg | so 5 -> 4 -> 1 -> not-redelegatable | 18:07 |
| amakarov | morganfainberg, the question is: who makes the decision? | 18:08 |
| morganfainberg | amakarov, i would think the initial delegator says "this can be redelegated, yes/no" and then that has a max depth - which is to limit DOS-type attacks based on expensive lookups | 18:08 |
| morganfainberg | at anypoint you can choose to disable re-delegation | 18:09 |
| morganfainberg | but it's not that you change the depth | 18:09 |
| amakarov | morganfainberg, yes, and this choice is made by unknown app | 18:09 |
| stevemar | dstanek, i believe so, for service name they will at least | 18:10 |
| stevemar | service id* | 18:10 |
| morganfainberg | amakarov, you obviously have trusted the app somewhat because you've handed off a delegation to it already (or at least to something that trusts it) | 18:10 |
| stevemar | have to check the code | 18:10 |
| morganfainberg | amakarov, and let that $something$ redelegate | 18:10 |
| amakarov | morganfainberg, on the other hand, he who trusts may explicitely restrict the depth | 18:10 |
| morganfainberg | amakarov, maybe this value is only settable at the first redelegation point? | 18:11 |
| morganfainberg | but i still think that UX is a bit weird. | 18:11 |
| ayoung | so long as the amount of redelgation cannot be increased, I am prone to support this. Saying "yeah, I know you said it could be redeletated 10 times, but I know that I need to hand it to Nova nad then we are done" is OK | 18:11 |
| morganfainberg | ayoung , ++ never increase | 18:11 |
| ayoung | Why not just say "I am consuming more than one redelegations..." | 18:11 |
| amakarov | morganfainberg, it begins to look like some kind of policy... | 18:12 |
| morganfainberg | ayoung, the only reason i advocated for the max-depth (global) was to circumvent DOS attacks based on an unbounded/expensive lookup | 18:12 |
| amakarov | ayoung, ++ | 18:12 |
| morganfainberg | same concept as a max recursion depth. | 18:13 |
| morganfainberg | amakarov, ayoung, so a cleaner UX [and tell me if this then matches] is you can toggle the boolean at any point in the chain preventing further redelegation. but you can't ever set/change the depth value. | 18:14 |
| ayoung | morganfainberg, so do you really have a problem with the spec as written? So long as they redelegation count can't increase, I can't see how this is a bad feature | 18:14 |
| amakarov | morganfainberg, for now one can do both | 18:14 |
| ayoung | morganfainberg, I think that is just the degenerate case | 18:14 |
| morganfainberg | ayoung, i'm worried about adding in superfluous things that make the UX weird or add surface area for potential issues | 18:14 |
| ayoung | it keeps you from saying " I can delegate to you, but you can't delegate further" | 18:15 |
| morganfainberg | especially because once we mint the API as stable we're stuck with it | 18:15 |
| morganfainberg | ayoung, my only concern is the changing depth on the chain, changing the boolean at anypoint is totally valid (boolean from true -> false that is) | 18:15 |
| ayoung | I'd go with the more flexible API in this case | 18:15 |
| morganfainberg | ayoung, we could always add that bit back in if there is a real case for it (reducing max delegation at any point) | 18:16 |
| amakarov | morganfainberg, you can toggle redelegation off and never back on | 18:16 |
| morganfainberg | ayoung, i'd rather be conservative in the API unless we really have a case for it. | 18:17 |
| ayoung | morganfainberg, we have use cases for it | 18:17 |
| morganfainberg | amakarov, ++ yes. and that should stay. | 18:17 |
| morganfainberg | ayoung, please elaborate | 18:17 |
| ayoung | morganfainberg, when a user creates a trust, they redelegate to solum | 18:17 |
| ayoung | solum uses that trust to talk to several services | 18:17 |
| morganfainberg | ayoung, i'm not sold that handing off to solum and having to know solum will only delegate 2 more times down the chain. | 18:17 |
| morganfainberg | ayoung, you're *already* trusting solum to do what it needs to do. | 18:18 |
| morganfainberg | if you don't trust solum to redelegate twice, or four times, you don't trust it once. | 18:18 |
| ayoung | unless we make the user define different trusts for each redelegation, solum needs to provide the exact same redelegation to heat and to nova | 18:18 |
| ayoung | o...user delegates to solum. solum delegates to two or more services | 18:18 |
| morganfainberg | because it could already do bad things™ with one redelegation | 18:18 |
| ayoung | one gets redeleagation=2, one gets it =1 | 18:19 |
| morganfainberg | ayoung, i think this is over-engineering it. | 18:19 |
| morganfainberg | user wont know how many times solum needs to redelegate... only that it does. | 18:19 |
| ayoung | morganfainberg, David Chadwick brought this up back when I was proposing trusts...redelgation and counts. I deferred for just this reason, and now solum needs the redelegation. Lets engineer it right this time | 18:20 |
| ayoung | But...ask Chadwick. I would argue that he has the perspective on this one. | 18:20 |
| morganfainberg | ayoung, the only bit of it i'm against is mid-stream change of the max-redelegation. | 18:20 |
| morganfainberg | all the rest makes perfect sense. | 18:21 |
| ayoung | Yep | 18:21 |
| morganfainberg | i would *probably* argue that we don't need to change the max-redelegation at anypoint. but i'm willing to leave that | 18:21 |
| morganfainberg | i don't see why Nova would change the max delegation depth | 18:22 |
| morganfainberg | in a chain of user -> solum -> heat -> nova -> glance | 18:22 |
| morganfainberg | it *could* turn off redelegation if it doesn't trust the app for redelegation, that is a boolean and should be able to be turned off | 18:22 |
| morganfainberg | ayoung, so, proposed change to the SPEC: don't allow mid-chain max-depth change (reduction) | 18:23 |
| morganfainberg | once a max depth is set, you're stuck with it. | 18:23 |
| morganfainberg | but you can halt further redelegation via the boolean. | 18:24 |
| amakarov | morganfainberg, so if user just trusts solum for depth 10, and solum knows there shouldn't be anything behind glance, what will it do? | 18:25 |
| morganfainberg | amakarov, how does solum know that | 18:25 |
| morganfainberg | and how does solum know that wont change? | 18:25 |
| morganfainberg | once you hand off to heat solum wont always know - heck heat may not know nova needs to redelegate to glance. heat is asking nova to do things. nova will either say "can't do this without redelegation or can" | 18:26 |
| lbragstad | morganfainberg: yeah, I'm curious to see what the outcome of that thread will be | 18:27 |
| *** richm has joined #openstack-keystone | 18:27 | |
| openstackgerrit | Andrey Pavlov proposed openstack/keystone: Handle SSL termination proxies for version list https://review.openstack.org/132235 | 18:27 |
| morganfainberg | but it's one of those cases you're trusting an service to do the right thing - either you trust it or you don't. If you trust it, you're trusting it's trusted apps. [they could just push the token around and do bad things™ as well) | 18:27 |
| *** viscious is now known as vishy | 18:29 | |
| morganfainberg | vishy, welcome back to non-friday nic day! | 18:29 |
| amakarov | morganfainberg, so we can leave max depth to be "stop-loss" limit and forgen about it in API calls? | 18:29 |
| openstackgerrit | gordon chung proposed openstack/keystonemiddleware: Adding audit middleware to keystonemiddleware https://review.openstack.org/102958 | 18:29 |
| *** NM has quit IRC | 18:30 | |
| morganfainberg | amakarov, thats my general view. but I'm not opposed to the initial trust being able to set a max limit (lower than global), I just don't see a benefit for changing that limit mid-chain artifically | 18:30 |
| amakarov | morganfainberg, 1 less validation :) | 18:32 |
| lbragstad | morganfainberg: or probably, when the XML tempest stuff will be removed :) | 18:33 |
| openstackgerrit | gordon chung proposed openstack/keystonemiddleware: Adding audit middleware to keystonemiddleware https://review.openstack.org/102958 | 18:33 |
| amakarov | morganfainberg, and what harm can this feature bring? | 18:34 |
| *** NM has joined #openstack-keystone | 18:35 | |
| ayoung | morganfainberg, I think you are picking at nits. I really don't think it is an issue. But if you care so strongly, I can abide. | 18:36 |
| *** diegows has joined #openstack-keystone | 18:37 | |
| ayoung | It means that the call for an initial trust creation is different than a redelegation. I'd argue it is the same degree of complication either way. | 18:37 |
| openstackgerrit | gordon chung proposed openstack/keystonemiddleware: documentation for audit middleware https://review.openstack.org/130344 | 18:38 |
| *** aix has joined #openstack-keystone | 18:39 | |
| *** _cjones_ has quit IRC | 18:40 | |
| afaranha | ayoung: Could you read this spec about the policy? https://review.openstack.org/#/c/135408/ | 18:41 |
| ayoung | afaranha, sure | 18:42 |
| ayoung | afaranha, So you've seen the chain of policy related work I've been putting forth, right? | 18:43 |
| afaranha | ayoung: Due to some reviews on the sample policy patch, we prefer to modify the current one to this new | 18:43 |
| ayoung | afaranha, for example, the unified policy file, etc? | 18:43 |
| afaranha | ayoung: Its better to maintain | 18:43 |
| ayoung | https://review.openstack.org/#/c/134656/ | 18:43 |
| afaranha | ayoung: No, I didn't | 18:43 |
| ayoung | and | 18:43 |
| ayoung | afaranha, go to that link, and look at the set of related specs | 18:44 |
| *** ajayaa has quit IRC | 18:44 | |
| afaranha | ayoung: https://review.openstack.org/#/c/133480/ | 18:44 |
| ayoung | afaranha, also: http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ | 18:44 |
| *** NM has quit IRC | 18:44 | |
| *** amcrn has joined #openstack-keystone | 18:44 | |
| ayoung | yep, that one too | 18:44 |
| *** NM has joined #openstack-keystone | 18:45 | |
| ayoung | afaranha, the idea is that we need a progressive approach on policy. I'm not certain if yours is essential. In a vacuum, yes, it would be a good idea | 18:45 |
| ayoung | I think a better one would be to focus at least on the unified policy file | 18:45 |
| ayoung | the old one is a known quantity | 18:45 |
| ayoung | we leave it in place, and do the work to mitigate the effects of going to a dynamic policy approach | 18:46 |
| *** jaosorior has joined #openstack-keystone | 18:46 | |
| afaranha | ayoung: At the spec that I read, I'm don't know how this will work | 18:46 |
| ayoung | so... yeah, the unified policy should pull in the improvements that you want for the base policy file | 18:46 |
| ayoung | afaranha, which spec? | 18:47 |
| afaranha | ayoung: We have a single file in Keystone, and for every service, we change the rules at that file, tight? | 18:47 |
| *** _cjones_ has joined #openstack-keystone | 18:47 | |
| afaranha | right* | 18:47 |
| ayoung | No | 18:47 |
| ayoung | look through the series of specs | 18:47 |
| ayoung | we make it possible for the services to fetch policy from Keystone, and then they all get the same default file | 18:47 |
| ayoung | which has a deconflicted set of rules | 18:47 |
| afaranha | ayoung: Sure | 18:47 |
| ayoung | now, yeah, we could replace etc/policy.json but then we break everyone depending on that (admittedly poor) approach | 18:48 |
| afaranha | I think it's great for common rules, like context_is_admin, user_or_owner, service, etc | 18:48 |
| ayoung | yeah | 18:48 |
| afaranha | ayoung: But, we already discuss this here, and there's the problem that the context of the services aren't the same | 18:48 |
| afaranha | for example, we don't have domain_id in the context of all the services | 18:49 |
| ayoung | so work with samuelms and Henrique rodrigods etc to divvy up the work from the set of specs, and rip them apart, and tell me where things are messed up, and lets unify our efforts | 18:49 |
| afaranha | Sure :) | 18:50 |
| ayoung | afaranha, ah, god point. so we say that projects *are* domains. Hierarchical multitenancy actually gives us some leeway there | 18:50 |
| *** NM has quit IRC | 18:53 | |
| *** jorge_munoz has quit IRC | 18:55 | |
| morganfainberg | ayoung, i'm trying to keep the surface area of our API spec as sane as possible / limit what we're having to carry forward. if there isn't a good case for it i don't want to carry it. | 18:56 |
| morganfainberg | especially if it's a weird UX. | 18:56 |
| *** NM has joined #openstack-keystone | 18:56 | |
| ayoung | morganfainberg, I understand that. Just that "enable" and "set non 0" are the same thing | 18:56 |
| morganfainberg | ayoung, so lets pick one or the other, not both. and "enable" is the better UX | 18:57 |
| ayoung | morganfainberg, the initial was not true or false. It was 0 means fals, >0 means redelgate that many times, < 0 means infiniate times | 18:58 |
| afaranha | ayoung, THIS topic number 1 | 18:58 |
| afaranha | ayoung: We need it to fiz the security issue we are having in the policy we are providing | 18:58 |
| ayoung | afaranha, assume that I never have the context of what you are talking about, and you will not be far off | 18:58 |
| ayoung | afaranha, I wish that were possible | 18:58 |
| ayoung | afaranha, we can't toy with the default policy without breakin a lot of things | 18:59 |
| ayoung | the cloud sample was Henrynash's first take on an improved solution, but we found it doesn't yet work due , as you pointed outk to domain scoped tokens etc | 18:59 |
| ayoung | so we really need HMT before we can improve policy | 19:00 |
| afaranha | ayoung: In a domain context, we want to create an admin that would also be responsible for role assignment on projects | 19:00 |
| ayoung | afaranha, I get it. We just can't do that today | 19:01 |
| ayoung | it breaks horizon | 19:01 |
| ayoung | and...the real question is who assigns what roles...but that is further down my list | 19:01 |
| afaranha | As domain is the container of users and projects, the domain admin should be responsible for assignment, agree? | 19:02 |
| *** NM has quit IRC | 19:04 | |
| *** afazekas has joined #openstack-keystone | 19:05 | |
| * ayoung just got the joke about nose.run | 19:08 | |
| ayoung | right | 19:08 |
| ayoung | afaranha, look at the hierarchical role spec | 19:08 |
| ayoung | https://review.openstack.org/#/c/125704/ | 19:09 |
| *** thiagop has joined #openstack-keystone | 19:09 | |
| *** afazekas has quit IRC | 19:10 | |
| stevemar | ayoung, bknudson is it not advisable to dynamically switch from an SQL backend to an LDAP one? like... just changing the keystone.conf file and restarting? Would anything else break? | 19:12 |
| *** packet has joined #openstack-keystone | 19:12 | |
| *** NM has joined #openstack-keystone | 19:12 | |
| ayoung | stevemar, role assignments would be all wrong | 19:12 |
| ayoung | we see that all the time | 19:12 |
| ayoung | none of the LDAP users have role assignments | 19:12 |
| stevemar | ayoung, yeah thats what I was not hoping for... | 19:12 |
| stevemar | but figure | 19:13 |
| bknudson | stevemar: I manually switched a small devstack from SQL to LDAP for a while but it wasn't easy | 19:13 |
| bknudson | this was before devstack supported LDAP | 19:13 |
| ayoung | stevemar, sorry, I keep my magic wand in my back pocket, and I sat on it. Its in the shop. Miracles will have to wait until I get it fixed. | 19:13 |
| stevemar | bknudson, yeah but I want to use a different LDAP than the one used by devstack | 19:14 |
| ayoung | that is why we want the multi backend storage approch: leave your service users in SQL, new assignments come in for users in LDAP | 19:14 |
| * bknudson wonders if stevemar has been smoking something | 19:14 | |
| bknudson | stevemar: y, that's what the multi-domain backend is for. | 19:15 |
| *** htruta has quit IRC | 19:15 | |
| *** gyee_ has joined #openstack-keystone | 19:15 | |
| stevemar | bknudson, i meant something other than https://github.com/openstack-dev/devstack/blob/master/files/ldap/keystone.ldif.in | 19:15 |
| bknudson | stevemar: you don't need that specific ldif but your directory will need to have places for users and groups. | 19:17 |
| *** gothicmindfood has quit IRC | 19:19 | |
| *** htruta has joined #openstack-keystone | 19:20 | |
| amakarov | morganfainberg, ayoung, so what do I do about redelegation depth? Just forbid modifying by anyone but trustor? | 19:21 |
| morganfainberg | amakarov, sec will be back [had a phone call and am chasing a bug down w/ nova guys] | 19:21 |
| *** gothicmindfood has joined #openstack-keystone | 19:22 | |
| *** dougwig has joined #openstack-keystone | 19:27 | |
| *** Haneef has quit IRC | 19:29 | |
| dougwig | hi keystone. my third-party CI has started spewing this in a tight loop, to the tune of 2GB of compressed logs per run, in the last 2-3 days. ring any bells? "[Sun Aug 24 21:38:25.027602 2014] [:info] [pid 11760:tid 140155513620352] mod_wsgi (pid=11760): Python has shutdown." | 19:29 |
| *** jistr has quit IRC | 19:31 | |
| morganfainberg | dougwig, i have not seen that before. | 19:34 |
| dougwig | morganfainberg: thanks, i'll dig into it. | 19:34 |
| *** carlosmarin has quit IRC | 19:34 | |
| amakarov | dougwig, I'd start with log format: it looks quite specific | 19:35 |
| morganfainberg | lbragstad, https://bugs.launchpad.net/keystone/+bug/1394995 | 19:35 |
| uvirtbot | Launchpad bug 1394995 in keystone "Test allow creation of service without type" [Undecided,New] | 19:35 |
| morganfainberg | lbragstad, also... related | 19:35 |
| *** diegows has quit IRC | 19:35 | |
| lbragstad | lol sweet | 19:35 |
| morganfainberg | i think we're closing that as wont fix | 19:35 |
| * morganfainberg reads. | 19:35 | |
| dstanek | dougwig: are you seeing that same pid in all of the messages? | 19:35 |
| lbragstad | I feel like this was opened *everywhere* | 19:35 |
| morganfainberg | lbragstad, ok this is the *same* bug | 19:35 |
| dougwig | amakarov: it looks like mod_wsgi is recycling the interpreter in a tight loop for some reason. only appears in the keystone log file. | 19:35 |
| dstanek | morganfainberg: do you have any experience using the infra yaml stuff to run the devstack tests in a test environment? | 19:36 |
| morganfainberg | lbragstad, mark that as a dupe of the one you're fixing with validation | 19:36 |
| dstanek | morganfainberg: i have some changes i want to test that setup devstack for functional tests | 19:36 |
| morganfainberg | dstanek, >.> yes. somewhat >> should i deny having that knowledge? | 19:36 |
| morganfainberg | dstanek, so you're looking at devstack-gate changes? | 19:36 |
| morganfainberg | dstanek, or what do you need to change. and i can probably point you at the place to do it | 19:37 |
| dougwig | https://www.irccloud.com/pastebin/fGxp8MCF | 19:37 |
| morganfainberg | dougwig, i've seen that happen if there is a crash in python | 19:37 |
| morganfainberg | dougwig, mod_wsgi keeps trying to spawn. | 19:37 |
| lbragstad | this https://bugs.launchpad.net/keystone/+bug/1394995 is a dup of https://bugs.launchpad.net/keystone/+bug/1259425 | 19:37 |
| uvirtbot | Launchpad bug 1394995 in keystone "Test allow creation of service without type" [Undecided,New] | 19:37 |
| lbragstad | right? | 19:37 |
| morganfainberg | like compile-time crash | 19:37 |
| morganfainberg | lbragstad, yeah | 19:38 |
| dstanek | morganfainberg: i know the place in openstack-infra/project-config/tree/jenkins/jobs to make the change to create a functional just template, but i don't know how to test the changes | 19:38 |
| morganfainberg | dstanek, ah. you make the change, mark the new "job" as expirimental | 19:38 |
| morganfainberg | then you run [i think] "check expirimental" on a patchset | 19:38 |
| morganfainberg | it'll run all expirimental jobs. | 19:39 |
| morganfainberg | work on fixing things that are broken, once it is stable we can move it to "non-vote" or "voting" | 19:39 |
| morganfainberg | broken could be broken in devstack, devstack-gate, or keystone | 19:39 |
| dstanek | morganfainberg: ah, so i can create a patchset and make it run those jobs without a commit? | 19:39 |
| morganfainberg | dstanek, you will also likely need to edit the zuul.yaml file | 19:39 |
| amakarov | dougwig, try to start it manually (keystone-all) | 19:40 |
| morganfainberg | dstanek, or pick any patchset ;) | 19:40 |
| morganfainberg | once infra has merged the new jobs | 19:40 |
| dstanek | morganfainberg: but before i run 'check experimental' my experimental job has to be merged? | 19:41 |
| amakarov | dougwig, I guess if there is a general problem then you'll see something more informative. Also try --debug key | 19:41 |
| dougwig | it looks like somehow debugging logging got enabled. was that an accidental commit maybe? | 19:42 |
| morganfainberg | bknudson, https://bugs.launchpad.net/keystone/+bug/1393920 not sure what we need to do about this. | 19:42 |
| uvirtbot | Launchpad bug 1393920 in keystone "I18n" [Undecided,New] | 19:42 |
| morganfainberg | bknudson, will chase it down, i18n stuff doesn't map anywhere for middleware apparantly | 19:43 |
| dstanek | that's a cool bug | 19:44 |
| rodrigods | marekd, nice, will review it as soon as I have some time | 19:44 |
| bknudson | morganfainberg: document that the client now supports I18n. | 19:44 |
| morganfainberg | bknudson, there is something wrong in the infra config | 19:45 |
| bknudson | I mean the auth_token middleware | 19:45 |
| morganfainberg | bknudson, sure, i meant the error | 19:46 |
| openstackgerrit | Marek Denis proposed openstack/keystone-specs: Service Provider for K2K https://review.openstack.org/135604 | 19:46 |
| *** carlosmarin has joined #openstack-keystone | 19:47 | |
| dougwig | not a keystone issue, something enabled debug. i'll wager devstack or one of the ci repos. i'll check there. thank you! | 19:47 |
| bknudson | morganfainberg: what error? | 19:47 |
| amakarov | morganfainberg, do we have a conclusion about trust API change? | 19:48 |
| bknudson | dougwig: keystone has always had debug enabled in tests. | 19:48 |
| afaranha | ayoung, do you know about other services whats the current status of recognizing keystone v3? | 19:51 |
| ayoung | afaranha, issue aside from Horizon is in keystonemiddleware.auth_token. jamielennox has a series of patches that need review/merging to support | 19:51 |
| *** diegows has joined #openstack-keystone | 19:51 | |
| *** Ctina_ has joined #openstack-keystone | 19:52 | |
| amakarov | morganfainberg, an idea: we can go with "allow_redelegation" flag and max depth in config thus totally excluding redelegation count from API | 19:52 |
| amakarov | morganfainberg, and add it later if needed | 19:52 |
| *** Ctina has quit IRC | 19:55 | |
| morganfainberg | amakarov, i'm thinking we go simple and expand as needed | 19:56 |
| morganfainberg | amakarov, so yeah i'd support that change. and then it's easy to expand on it - we're not exluding the capability down the line | 19:57 |
| morganfainberg | just not out the gate. | 19:57 |
| dougwig | bknudson: thanks. *something* changed about 3 days ago that enabled lots of useless logs. will look further. | 19:57 |
| *** jorge_munoz has joined #openstack-keystone | 19:58 | |
| amakarov | morganfainberg, so we have: max depth in config, allow_redelegation in API? | 19:58 |
| morganfainberg | amakarov, ok so, let me see | 19:58 |
| morganfainberg | we have 2 options: | 19:58 |
| morganfainberg | 1) boolean "allow_redelegation" | 19:59 |
| *** htruta has quit IRC | 19:59 | |
| morganfainberg | or 2) "max depth"[whatever it is called], where 0 = no redelegate, > 0 = that many levels, and [future] -1 could mean unlimited | 19:59 |
| morganfainberg | #2 is more flexible, and not a bad UX. as long as the max depth isn't "changed" by a user when redelegating | 20:00 |
| morganfainberg | amakarov, the first option is a bit more straight forward. | 20:00 |
| morganfainberg | the only issue with #2 is if a user sets max depth to > global max depth, does it just set ot he global or 400? | 20:01 |
| morganfainberg | and how does a user know the max depth | 20:01 |
| amakarov | morganfainberg, for now it's an error | 20:02 |
| morganfainberg | amakarov, then how does a user know the max depth? | 20:02 |
| morganfainberg | they have to try and fail. | 20:02 |
| morganfainberg | ? | 20:02 |
| *** joesavak has quit IRC | 20:02 | |
| amakarov | morganfainberg, no, there are 2 sources | 20:02 |
| amakarov | 1) config itself | 20:02 |
| morganfainberg | assume the user can't read the config | 20:02 |
| *** joesavak has joined #openstack-keystone | 20:02 | |
| amakarov | 2) if user redelegates, it uses trust containing remaining depth | 20:03 |
| morganfainberg | but the user can't know what the max is when creating the original trust | 20:03 |
| morganfainberg | so it's a guessing game | 20:03 |
| amakarov | morganfainberg, and if user omits the depth, the default is used | 20:03 |
| morganfainberg | ok so here i think are the right changes: | 20:04 |
| amakarov | each redelegation decrements remaining depth by default | 20:04 |
| morganfainberg | right | 20:04 |
| amakarov | I handle that case when user passes depth as uncommon | 20:05 |
| morganfainberg | so 1st off, i think a user should opt into redelegation vs opt-out | 20:05 |
| morganfainberg | trusts should *not* be redelegatable by default | 20:06 |
| amakarov | they are not | 20:06 |
| morganfainberg | no change in our current default behavior | 20:06 |
| morganfainberg | you said if redelegate depth is not passed it is set to max? | 20:06 |
| morganfainberg | or it *also* requires the boolean | 20:06 |
| morganfainberg | ? | 20:06 |
| amakarov | one must explicitly set the flag and may even forget about depth | 20:07 |
| morganfainberg | ok | 20:07 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Require `name` when creating Services https://review.openstack.org/136881 | 20:07 |
| morganfainberg | amakarov, so i think the fix is minor | 20:07 |
| lbragstad | morganfainberg: ^ service['name'] required patch | 20:07 |
| morganfainberg | no one can change the max depth later in the chain | 20:07 |
| morganfainberg | everything else can remain the same. | 20:08 |
| morganfainberg | so a redelegate you're stuck with the chain length you started with. | 20:08 |
| amakarov | morganfainberg, so trustor don't set it too? | 20:08 |
| morganfainberg | amakarov, so initial trust creation sets it. | 20:08 |
| morganfainberg | amakarov, if it's a redelegatable trust. after that, it can't be changed in subsequent redelegations | 20:09 |
| morganfainberg | everything else stays the same | 20:09 |
| amakarov | morganfainberg, we may avoid that special case at all since we have default from config | 20:09 |
| amakarov | trustor don't need to specify it | 20:09 |
| morganfainberg | amakarov, right, but to ayoung's point they want to limit redelegation. so it can be specified, but not need to be specified | 20:09 |
| morganfainberg | not specified = use global | 20:09 |
| morganfainberg | if specified it must be <= global | 20:10 |
| amakarov | morganfainberg, understood. I'll do it tomorrow. | 20:10 |
| morganfainberg | so we're just avoiding the special case of "if you are redelegating a trust, you can't change the depth" | 20:10 |
| bknudson | is the number of roles in the token a limit to redelegation? | 20:10 |
| afaranha | ayoung: There's a lot of efforts on these blueprint | 20:10 |
| morganfainberg | minor change, but it keeps the UX cleaner. | 20:10 |
| ayoung | afaranha, which is why I don't want more effort than necessary. | 20:11 |
| morganfainberg | bknudson, right now, you would need to use a trust to limit roles in the token | 20:11 |
| afaranha | ayoung, I didn't understand what's the improvement from usgint he policy for this bp https://review.openstack.org/#/c/123726/4/specs/kilo/token-constraints.rst | 20:11 |
| morganfainberg | bknudson, redelegated or not. | 20:11 |
| amakarov | morganfainberg, this way trustor ability to set it becomes the special case ) | 20:11 |
| morganfainberg | amakarov, ++ | 20:11 |
| morganfainberg | lbragstad, you could just mark the bugs in LP as duplicates | 20:12 |
| morganfainberg | lbragstad, as well vs. needing to do related-bug | 20:12 |
| *** gyee_ has quit IRC | 20:12 | |
| lbragstad | morganfainberg: the ones I marked as related are the dup ones I believe. just double checking that https://launchpad.net/bugs/1259425 is the one that we want to track everything with. | 20:13 |
| uvirtbot | Launchpad bug 1259425 in keystone "service-create allows 2 services with the same name" [Medium,In progress] | 20:13 |
| morganfainberg | lbragstad, yeah | 20:13 |
| lbragstad | sweet, I'll remove | 20:13 |
| lbragstad | the Related tags | 20:13 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Require `name` when creating Services https://review.openstack.org/136881 | 20:13 |
| amakarov | morganfainberg, 1 more: please see HA fix. It's tiny but proved necessary: https://review.openstack.org/#/c/136749/ | 20:15 |
| morganfainberg | lbragstad, we also need a SQL migration for that | 20:15 |
| morganfainberg | lbragstad, or are you doing that as separate? | 20:15 |
| *** thedodd has joined #openstack-keystone | 20:16 | |
| *** amakarov is now known as amakarov_away | 20:16 | |
| lbragstad | I'll do that as a dep of the one above ^ | 20:16 |
| morganfainberg | lbragstad, ok -1 since it doesn't close the bug (partial-bug) | 20:16 |
| morganfainberg | the dep should closes-bug | 20:17 |
| lbragstad | ok | 20:17 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Require `name` when creating Services https://review.openstack.org/136881 | 20:17 |
| morganfainberg | and likely we need KSC / OSC updated to be smarter. | 20:17 |
| morganfainberg | but that is different than this bug. | 20:17 |
| *** kobtea has joined #openstack-keystone | 20:18 | |
| *** htruta has joined #openstack-keystone | 20:18 | |
| lbragstad | morganfainberg: just double checking, but I can use 045_placeholder.py for adding a name column to the service table | 20:21 |
| lbragstad | and it shouldn't be nullable and should be unique | 20:22 |
| morganfainberg | lbragstad, only if it's a backport | 20:22 |
| morganfainberg | lbragstad, don't use the placeholders otherwise | 20:22 |
| lbragstad | ok | 20:22 |
| morganfainberg | lbragstad, if it's a backport the real migration comes after placeholders and is idempotent, then the backport is added to the placeholder in master *then* backported to /stable | 20:22 |
| lbragstad | so does that mean I start at 61 | 20:22 |
| morganfainberg | yeah start at the next non-placeholder | 20:22 |
| lbragstad | ok | 20:23 |
| *** kobtea has quit IRC | 20:23 | |
| *** gyee_ has joined #openstack-keystone | 20:25 | |
| *** carlosmarin has quit IRC | 20:28 | |
| *** carlosmarin has joined #openstack-keystone | 20:43 | |
| *** NM has quit IRC | 20:47 | |
| dolphm | bknudson: the one sound that no one knows, what does the bot say? https://bugs.launchpad.net/keystonemiddleware/+bug/1393920 | 20:50 |
| uvirtbot | Launchpad bug 1393920 in keystonemiddleware "I18n" [Medium,Confirmed] | 20:50 |
| bknudson | foxes make little yipping noises like little dogs. | 20:52 |
| lbragstad | ankle biters? | 20:58 |
| * lbragstad got bit by a little dog running the other day... | 21:00 | |
| bknudson | not running fast enough | 21:00 |
| lbragstad | apparently not | 21:00 |
| stevemar | lbragstad just got burned by bknudson | 21:12 |
| * lbragstad starts shopping on Amazon for aloe vera | 21:13 | |
| stevemar | bknudson, https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L76-L87 | 21:14 |
| stevemar | i think we can just add keys/values there | 21:14 |
| stevemar | i'll try it out soon | 21:15 |
| *** Ctina_ has quit IRC | 21:18 | |
| *** carlosmarin has quit IRC | 21:19 | |
| *** carlosmarin has joined #openstack-keystone | 21:20 | |
| ayoung | dstanek, how do I run unit tests from the command line in the debugger? I can't do python -m pdb since I need to do pythom -m nose .... | 21:23 |
| dstanek | ayoung: if you are using nose then 'python -m nose --pdb' should work | 21:24 |
| *** htruta_ has joined #openstack-keystone | 21:24 | |
| ayoung | dstanek, trying | 21:24 |
| dstanek | ayoung: we also have a debug target in tox that uses testr | 21:24 |
| ayoung | dstanek, I had other issues with that. | 21:25 |
| ayoung | trying to limit it to one degree of frustration at a time | 21:25 |
| lbragstad | ayoung: you can also use https://wiki.openstack.org/wiki/Testr#Debugging_.28pdb.29_Tests | 21:25 |
| stevemar | not sure how that guy works with unit tests, never tried it before with that | 21:25 |
| ayoung | lbragstad, since the whole set of unit tests take so long I want to run just a single named test | 21:25 |
| ayoung | sick of reinventing how I do this | 21:26 |
| lbragstad | ayoung: you can match the tests you want to run with a regex | 21:26 |
| lbragstad | and it generates a list of tests to run | 21:26 |
| dstanek | lbragstad: yeah, but that's stupid :-) | 21:26 |
| lbragstad | lol | 21:26 |
| dstanek | lbragstad: with nose i can tell it what to run and it runs it | 21:26 |
| lbragstad | dstanek: has better solutions I'm sure | 21:27 |
| lbragstad | I just happen to stumble across that one day and I've held on to it since because it worked :) | 21:27 |
| dstanek | lbragstad: i can see the value of testr for CI style testing, but i run my tests on just about every save and it's too slow for that | 21:28 |
| lbragstad | like ayoung, I was frustrated beyond belief and need to debug a test | 21:28 |
| lbragstad | dstanek: so how do you do it? | 21:28 |
| dstanek | lbragstad: i use nose | 21:29 |
| ayoung | seems to be having a problem setting breakpoints | 21:30 |
| ayoung | dstanek, when I run nose that way, it gets through the failing test and then hits a break point in the test_runner | 21:32 |
| dstanek | ayoung: it doesn't stop on your breakpoint? | 21:32 |
| ayoung | this is about as simple a test as can be. Does not inherit from any of the Oslo?keystonetest classes | 21:32 |
| ayoung | dstanek, how do I set one? If I do it using import pdb; pdb.set_trace() it just hangs | 21:33 |
| ayoung | runnning -m pdb will stop before main | 21:33 |
| ayoung | but this way...yeah, debugger is running, but it is kinda useless | 21:33 |
| ayoung | I'm running like this | 21:33 |
| ayoung | /opt/stack/keystone/.tox/py27/bin/python -m nose --pdb keystone.tests.test_access_info | 21:34 |
| ayoung | class AccessTestCase(testtools.TestCase) | 21:34 |
| ayoung | should be straight forward... | 21:35 |
| dstanek | let me give it a try | 21:36 |
| dstanek | ayoung: what patch are you testing? | 21:37 |
| ayoung | dstanek, nothing I've submitted yet | 21:38 |
| ayoung | I can post, but it looks like the issue is how I am running pdb, no? | 21:38 |
| *** topol has joined #openstack-keystone | 21:39 | |
| *** ChanServ sets mode: +v topol | 21:39 | |
| ayoung | dstanek, --pdb Drop into debugger on errors | 21:41 |
| ayoung | I need to be in the debugger up front | 21:41 |
| dstanek | ayoung: lol, just looked at my vim config and i use -s --pdb | 21:43 |
| dstanek | the -s tells nose to string stdout | 21:43 |
| dstanek | i actually use 'nosetests -s --pdb {args}' | 21:43 |
| *** dnalezyt has joined #openstack-keystone | 21:44 | |
| ayoung | dstanek, is there a more intelligent way to do this? It should not be that hard: run python in debug mode and kick off a test runner...anytest runner, that honors the debugger | 21:45 |
| ayoung | So I can step through my code; | 21:46 |
| *** zzzeek has quit IRC | 21:46 | |
| dstanek | ayoung: python -m nose -s --pdb - to run through nose | 21:47 |
| dstanek | ayoung: the link lbragstad posted does the same in testr | 21:47 |
| ayoung | dstanek, that givesme no way to set a breakpoint, just dumps to the debugger on failure | 21:47 |
| dstanek | testr is more complicated because it is multiprocess | 21:47 |
| dstanek | import pdb; pdb.set_trace() drops you into the debugger | 21:48 |
| lbragstad | in the link I posted, you can set "traditional" breakpoints | 21:48 |
| lbragstad | ^^ | 21:48 |
| lbragstad | what dstanek said | 21:48 |
| *** carlosmarin has quit IRC | 21:49 | |
| ayoung | dstanek, not for me...it is hanging. Maybe due to the venv python? | 21:50 |
| dstanek | ayoung: did you add the -s? | 21:50 |
| ayoung | dstanek, ah...missed getting the right combination of args... ok think that worked | 21:51 |
| dstanek | ayoung: try running 'nosetests -s --pdb keystone.tests.test_accessinfo' | 21:51 |
| dstanek | ayoung: k | 21:51 |
| ayoung | dstanek, it was | 21:51 |
| dstanek | ayoung: now create a shell alias! | 21:51 |
| ayoung | /opt/stack/keystone/.tox/py27/bin/python -m nose -s --pdb keystone.tests.test_access_info | 21:52 |
| ayoung | dstanek, well, I am actually doing it from inside of emacs now | 21:52 |
| dstanek | ayoung: ah...i was just going to tell you to add it to your vim snippets :-) | 21:52 |
| ayoung | so I can see what line the debugger stops on without havving to list every time | 21:52 |
| ayoung | :) | 21:52 |
| dstanek | lbragstad: messing with this gate stuff is crazy | 21:55 |
| lbragstad | dstanek: yeah, makes you appreciate the infra guys... | 21:56 |
| lbragstad | that stuff makes my head hurt.. | 21:56 |
| *** packet has quit IRC | 21:57 | |
| lbragstad | dstanek: are you making progress with it? | 21:58 |
| *** zzzeek has joined #openstack-keystone | 21:59 | |
| dstanek | lbragstad: yes, i'm trying to get a barebones federation setup going | 22:02 |
| *** harlowja is now known as harlowja_away | 22:05 | |
| *** jsavak has joined #openstack-keystone | 22:06 | |
| *** mikedillion has joined #openstack-keystone | 22:06 | |
| *** joesavak has quit IRC | 22:09 | |
| *** harlowja_away is now known as harlowja | 22:16 | |
| *** jsavak has quit IRC | 22:17 | |
| *** dims has quit IRC | 22:25 | |
| *** dims has joined #openstack-keystone | 22:26 | |
| *** dims has quit IRC | 22:26 | |
| *** dims_ has joined #openstack-keystone | 22:27 | |
| *** dims_ has quit IRC | 22:28 | |
| *** _cjones_ has quit IRC | 22:33 | |
| stevemar | dstanek, whatcha trying to progress on? | 22:35 |
| dstanek | stevemar: playing with functional testin | 22:36 |
| *** _cjones_ has joined #openstack-keystone | 22:36 | |
| stevemar | dstanek, functional tests and federation stuff? now we're cookin with fire | 22:37 |
| dstanek | stevemar: yessir, fun stuff | 22:37 |
| stevemar | dstanek, i was going to write a spec about that, you have an etherpad or something for ideas? | 22:37 |
| *** dims has joined #openstack-keystone | 22:39 | |
| lbragstad | morganfainberg: if service.name isn't going to be nullable, what should it default to? | 22:40 |
| morganfainberg | Uhh | 22:40 |
| morganfainberg | Required not null? | 22:41 |
| morganfainberg | Don't think we can default it. | 22:41 |
| lbragstad | so don't make it nullable? | 22:41 |
| morganfainberg | Yeah. | 22:41 |
| morganfainberg | I mean we could. | 22:41 |
| morganfainberg | *shrug* | 22:41 |
| morganfainberg | unique constraint would still work iirc | 22:42 |
| lbragstad | so, I think if we make it non-nullable we should default to an '' | 22:42 |
| *** afazekas has joined #openstack-keystone | 22:42 | |
| lbragstad | but, that case would fast fail in the jsonschema validator | 22:42 |
| morganfainberg | Hmm. | 22:43 |
| morganfainberg | It could still be null. I guess so we don't break anyone. | 22:43 |
| *** diegows has quit IRC | 22:43 | |
| lbragstad | morganfainberg: ok, running testing against that | 22:44 |
| morganfainberg | (Null, type-not-null) should be a fine unique constraint. | 22:44 |
| morganfainberg | I think. | 22:44 |
| lbragstad | yeah, type is still required and can't be null | 22:44 |
| *** junhongl has quit IRC | 22:46 | |
| *** afazekas has quit IRC | 22:47 | |
| *** junhongl has joined #openstack-keystone | 22:55 | |
| *** diegows has joined #openstack-keystone | 23:00 | |
| *** topol has quit IRC | 23:01 | |
| *** jaosorior has quit IRC | 23:03 | |
| *** nkinder has quit IRC | 23:06 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Migration script for adding name to service table https://review.openstack.org/136917 | 23:09 |
| *** lhcheng has quit IRC | 23:10 | |
| *** ncoghlan has joined #openstack-keystone | 23:14 | |
| jamielennox | morganfainberg, lbragstad: i don't think we need to make name a unique value | 23:20 |
| jamielennox | i think if it's just a new column with either a default empty string or Null value it's fine | 23:22 |
| *** edmondsw has quit IRC | 23:23 | |
| morganfainberg | jamielennox, name + type = unique constraint | 23:28 |
| jamielennox | morganfainberg: type == unique | 23:29 |
| jamielennox | pretty much the catalog will fail otherwise | 23:30 |
| jamielennox | there was a bug about this opened not long ago | 23:30 |
| morganfainberg | jamielennox, so you can never have type duplicated ever? | 23:30 |
| *** thedodd has quit IRC | 23:31 | |
| jamielennox | trying to find the bug | 23:32 |
| jamielennox | but i can say that OpenStack today just wont work if you do, and i don't see the point in adding the ability | 23:33 |
| jamielennox | damnit i can't find it | 23:35 |
| morganfainberg | i'm fine with it if that is the real limitation | 23:35 |
| jamielennox | but essentially if you have multiple service_types the way the catalog searches if it can't find a suitable endpoint in the service_type it will fail early | 23:35 |
| morganfainberg | ok so type unique and nothing else unique | 23:35 |
| jamielennox | so if you have two 'compute' types it will only ever check one | 23:35 |
| morganfainberg | well not name | 23:36 |
| morganfainberg | maybe in the future we can expand that constraint if we have multiple types | 23:36 |
| morganfainberg | erm support for multiples of a type | 23:36 |
| jamielennox | i can't see a reason to allow multiple types - isn't that what the endpoints should be filtered on? | 23:36 |
| jamielennox | if we had a semi-sane catalog i would have made the service_type the dictionary key | 23:37 |
| jamielennox | so it doesn't work now - and i'm not sure if it's something we should try to make work | 23:37 |
| jamielennox | morganfainberg: might have been https://bugs.launchpad.net/keystone/+bug/1377080 | 23:39 |
| uvirtbot | Launchpad bug 1377080 in python-keystoneclient "Stale endpoint selection logic in keystone client" [Wishlist,Invalid] | 23:39 |
| morganfainberg | sure. | 23:39 |
| morganfainberg | lbragstad, ^ | 23:39 |
| morganfainberg | all makes sense to me | 23:39 |
| morganfainberg | name in this case seems superfluous | 23:39 |
| morganfainberg | fwiw | 23:40 |
| jamielennox | i would agree with keystone putting a unique constraint on type | 23:40 |
| jamielennox | morganfainberg: ++ | 23:40 |
| jamielennox | i'm pretty sure this stuff was never designed, just stuff was thrown in as people thought it might be useful | 23:40 |
| *** jamielennox has left #openstack-keystone | 23:40 | |
| *** jamielennox has joined #openstack-keystone | 23:40 | |
| *** ChanServ sets mode: +v jamielennox | 23:40 | |
| morganfainberg | jamielennox, haha | 23:43 |
| jamielennox | morganfainberg: if it comes to it name + type unique will work i just don't see the point | 23:47 |
| *** oomichi has joined #openstack-keystone | 23:48 | |
| *** kobtea has joined #openstack-keystone | 23:55 | |
| jamielennox | i have found the common factor in all these gate issues that people think are transitive.... me | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!