*** amcrn has quit IRC | 00:05 | |
*** cjellick_ has joined #openstack-keystone | 00:13 | |
*** mitz has quit IRC | 00:15 | |
*** cjellick has quit IRC | 00:17 | |
*** mitz_ has joined #openstack-keystone | 00:18 | |
*** bknudson has joined #openstack-keystone | 00:22 | |
*** radez is now known as radez_g0n3 | 00:28 | |
*** zzzeek has quit IRC | 00:29 | |
ayoung | jamielennox, looking now | 00:31 |
---|---|---|
ayoung | rm_work, you are working to lose me when you write things like "LBaaS Hijacks the user's token" | 00:32 |
*** dims has quit IRC | 00:32 | |
jamielennox | ayoung: thanks | 00:35 |
*** dims has joined #openstack-keystone | 00:37 | |
*** saipandi has quit IRC | 00:40 | |
ayoung | jamielennox, +2A all those. I've looked at them all before at least once | 00:42 |
ayoung | well, the first thre | 00:42 |
ayoung | three | 00:42 |
ayoung | let me see the second 3 | 00:42 |
jamielennox | ayoung: excellent, there's more if you're that keen :) | 00:43 |
jamielennox | i need another core to pop there head up and we can really get somewhere today | 00:43 |
ayoung | jamielennox, so you sure about project_id? And not domain_id? | 00:43 |
jamielennox | morganfainberg, gyee, stevemar ^ | 00:43 |
jamielennox | ayoung: not really, i'd prefer to have neither | 00:44 |
jamielennox | but i need a way to construct those old urls that have /v1/{project_id} in them | 00:44 |
ayoung | ah | 00:44 |
jamielennox | domain_id is ignored by pretty much everybody | 00:44 |
ayoung | I wish there were no difference between domains and projects | 00:44 |
*** gokrokve has joined #openstack-keystone | 00:44 | |
ayoung | +2 there | 00:44 |
jamielennox | yea, the path from here to there is hard | 00:45 |
stevemar | ? | 00:45 |
jamielennox | stevemar: excellent. i have some reviews for you | 00:45 |
stevemar | jamielennox, link me! | 00:45 |
jamielennox | https://review.openstack.org/#/c/118520/ | 00:45 |
jamielennox | https://review.openstack.org/#/c/117669/ | 00:46 |
jamielennox | https://review.openstack.org/#/c/112440/ | 00:46 |
jamielennox | those ones are easy | 00:46 |
stevemar | will do | 00:46 |
ayoung | jamielennox, so the Kerberos one is in an interesting spot. | 00:47 |
ayoung | I tried CI and it failed, due to PyKerberos not doing Py33 | 00:47 |
jamielennox | ayoung: i was just looking at that one to see if it was passing now | 00:47 |
ayoung | but...it looks like someone submitted a py33 compatable version back in March. | 00:47 |
ayoung | jamielennox, my RPM is 1.1.4, but the PyPi looks like 1.1.5. I've built it on a VM un 3.3 and it passes | 00:48 |
ayoung | well, it builds | 00:48 |
jamielennox | 1.1.5 is python3 compatible>? | 00:48 |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Make the default cache time more explicit in code https://review.openstack.org/113586 | 00:48 |
jamielennox | easy: https://review.openstack.org/#/c/116757/ | 00:48 |
ayoung | jamielennox, it seems to be | 00:49 |
ayoung | jamielennox, its not in the upstream SVN repo | 00:49 |
ayoung | just the one in PyPi | 00:49 |
jamielennox | .... - that sounds dodgy | 00:49 |
ayoung | yepo | 00:49 |
ayoung | and the PyPi one doesn't have test.py in it, so....was it tested? | 00:49 |
jamielennox | i remember looking at the sources for pykerberos a while ago - i think last time we had this talk | 00:50 |
ayoung | http://logs.openstack.org/74/74974/15/check/gate-python-keystoneclient-python33/b369b17/ the Gate job that failed | 00:50 |
jamielennox | there's a lot of direct c bindings that make it kind of hard | 00:51 |
ayoung | Downloading/unpacking kerberos==1.1.1 (from requests-kerberos>=0.5->-r /home/jenkins/workspace/gate-python-keystoneclient-python33/requirements.txt (line 16)) | 00:51 |
jamielennox | ayoung: is there another python kerberos library? | 00:51 |
jamielennox | ayoung: i can replicate requests-kerberos easily | 00:51 |
ayoung | is it requests_kerberos the failing one? I thought it was python-kerberos, which was broken in the past | 00:52 |
ayoung | but 1.1.1....not 1.1.5? | 00:52 |
ayoung | Is it bound to an older version of python-kerberos? | 00:52 |
jamielennox | the fail is because of the dependency requests_kerberos -> python-kerberos isn't it? | 00:53 |
stevemar | jamielennox, done! | 00:58 |
stevemar | if you guys have time: https://review.openstack.org/#/c/118536/ (ayoung, this one in particular) and https://review.openstack.org/#/c/119159/ | 00:59 |
stevemar | bbl | 00:59 |
ayoung | jamielennox, requests>=1.1.0 | 00:59 |
ayoung | kerberos==1.1.1 | 00:59 |
ayoung | yepo | 00:59 |
*** dims_ has joined #openstack-keystone | 01:03 | |
*** stevemar has quit IRC | 01:04 | |
jamielennox | oh - it's a fixed version | 01:04 |
*** dims has quit IRC | 01:05 | |
jamielennox | yuk | 01:05 |
*** marcoemorais1 has quit IRC | 01:05 | |
ayoung | jamielennox I tried hacking that from github and building py33 | 01:06 |
*** dims_ has quit IRC | 01:06 | |
ayoung | File "./setup.py", line 50, in <module> | 01:06 |
ayoung | version=get_version(), | 01:06 |
ayoung | File "./setup.py", line 39, in get_version | 01:06 |
ayoung | return matches[0].group(1) | 01:06 |
*** dims has joined #openstack-keystone | 01:06 | |
ayoung | I'm guessing this one won't be too bad to deal with | 01:06 |
jamielennox | so it's a mostly 'official' requests library, so we can probably pull in some help from sigmavirus24_awa | 01:06 |
jamielennox | ayoung: looking at the commit history i don't know if there is a consensus on python 3 | 01:07 |
*** wwriverrat has joined #openstack-keystone | 01:08 | |
jamielennox | they've reverted the testing | 01:08 |
ayoung | So long as there is no real resistance to it...guessing that there was a bit of the same bubble we got trapped in: python-kerberos | 01:08 |
jamielennox | wtf is that get_version function doing? | 01:10 |
ayoung | jamielennox, as they say in Madrid NPI | 01:10 |
ayoung | No idea | 01:10 |
*** joesavak has joined #openstack-keystone | 01:10 | |
* jamielennox has never seen so many +As all at once | 01:10 | |
ayoung | :) | 01:11 |
jamielennox | ayoung: https://review.openstack.org/#/c/116757/ needs to happen before release as it's a fix for something that already got merged | 01:12 |
jamielennox | so will it build for py3? | 01:13 |
*** jsavak has joined #openstack-keystone | 01:14 | |
*** dims has quit IRC | 01:16 | |
*** joesavak has quit IRC | 01:18 | |
*** dims has joined #openstack-keystone | 01:19 | |
*** r-daneel has quit IRC | 01:22 | |
*** gokrokve_ has joined #openstack-keystone | 01:23 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Stop skipping LDAP tests https://review.openstack.org/119970 | 01:23 |
*** dims has quit IRC | 01:25 | |
*** dims has joined #openstack-keystone | 01:26 | |
*** gokrokve has quit IRC | 01:26 | |
*** dims_ has joined #openstack-keystone | 01:26 | |
*** gokrokve_ has quit IRC | 01:27 | |
*** nkinder has joined #openstack-keystone | 01:29 | |
*** dims has quit IRC | 01:30 | |
ayoung | jamielennox, I think I recall the requests-kerberos guy was quick to pull the trigger. I'll try to line up a tested version for him in the next couple of days. | 01:36 |
*** dims_ has quit IRC | 01:42 | |
*** bknudson has quit IRC | 01:43 | |
*** dims has joined #openstack-keystone | 01:47 | |
*** dims has quit IRC | 01:50 | |
*** dims has joined #openstack-keystone | 01:50 | |
*** hrybacki has quit IRC | 01:53 | |
*** dims_ has joined #openstack-keystone | 01:53 | |
*** dims has quit IRC | 01:54 | |
*** wanghong has quit IRC | 01:56 | |
ayoung | jamielennox, are these the samething: https://pypi.python.org/pypi/pykerberos https://pypi.python.org/pypi/kerberos ? Cuz the second is locked to 1.1.1 and that is the problem, but if we can go against pykerberos we are in a better place | 02:04 |
*** dims_ has quit IRC | 02:04 | |
*** dims has joined #openstack-keystone | 02:04 | |
jamielennox | ayoung: looks like a fork | 02:05 |
ayoung | jamielennox, one test fails | 02:05 |
jamielennox | kerberos 1.1.1 was uploaded 2011-04-27 | 02:05 |
ayoung | jamielennox, BTW, I just hacked the version to be "1.1.5" in setup.py. looks like it is doing pbr type things | 02:05 |
jamielennox | ayoung: i think that's what the weird get_version regexp was donig | 02:06 |
ayoung | hmmm | 02:06 |
jamielennox | there's no source for pykerberos though | 02:06 |
jamielennox | i'm *guessing* it's https://github.com/02strich/pykerberos | 02:07 |
*** wanghong has joined #openstack-keystone | 02:08 | |
ayoung | Package Index Owner: 02strich yeah, that is a good guess | 02:08 |
*** jsavak has quit IRC | 02:09 | |
*** dims has quit IRC | 02:09 | |
jamielennox | but is that bit the problem? | 02:09 |
ayoung | I think we can work with it | 02:10 |
jamielennox | oh - flip over requests-kerberos to use pykerberos instead of kerberos | 02:10 |
ayoung | yeah | 02:10 |
ayoung | and hack the regex to not be a regex | 02:10 |
jamielennox | regexp versions is a problem for the rpm maintainer | 02:10 |
ayoung | yeah, we'll fix that | 02:11 |
ayoung | OK..someone had to fork it...we can deal with the fork, so long as we are not the ones adopting it. | 02:11 |
ayoung | I'll hack on it tomorrow...I think this looks promising | 02:11 |
jamielennox | yep, the issue here is that it's got to be requests-kerberos that makes the switch | 02:12 |
jamielennox | ayoung: if that doesn't work then we will have to look at making pykerberos a dependency directly and do our own plugin handling | 02:13 |
jamielennox | it's not too hard, just not something i want to maintain | 02:13 |
ayoung | we'll need it in the global requirements... | 02:14 |
jamielennox | ye3a | 02:14 |
jamielennox | i was wondering if we can do like a keystoneclient-auth-extras in stackforge or something | 02:14 |
jamielennox | there's no reason this has to be in tree | 02:14 |
*** diegows has quit IRC | 02:15 | |
jamielennox | and we have the same issue with lxml and federation stuff that they don't want for ksc | 02:15 |
ayoung | I want Kerberos to be a non-issue | 02:15 |
ayoung | then again, I want to be able to use Kerberos to set up TLS and that ain't gonna happen | 02:16 |
jamielennox | sure, i don't see it being in a different tree making that a problem | 02:16 |
jamielennox | having to do a = keystoneclient-kerberos.Auth() rather than keystoneclient.contrib.auth.kerberos.Auth() will not be an issue | 02:17 |
jamielennox | ideally i would like just one -extras repo, but it might need to be many | 02:18 |
openstackgerrit | A change was merged to openstack/keystone: Fix oauth sqlite migration downgrade failure https://review.openstack.org/119653 | 02:18 |
ayoung | I don't want kerberos in extras, but we are getting into depedency hell here, aren't we. Anyway, we can deal once we have something that builds | 02:20 |
jamielennox | my issue is that ksc is a very common dependency and we keep adding requirements to it | 02:20 |
jamielennox | lxml took it from pure python to having C extensions | 02:20 |
jamielennox | having kerberos as a dep will do the same thing | 02:20 |
jamielennox | and if we don't install requests-kerberos as a dependency and say you should install it if you want to use it, then we may as well just pull the kerberos plugin to its own repo | 02:21 |
ayoung | so it should be python-keystoneclient-kerberos and have its own repo | 02:22 |
ayoung | I'll suggest that at the meeting tomorrow. | 02:22 |
ayoung | I think that the dependency issue is a clincher on that | 02:22 |
jamielennox | yep, i was going to propose this for summit around fereation but i think that kerberos will come up quicker than that | 02:23 |
ayoung | We should somehow get all of the the Django-openstack-auth Kerberos dependencies crammed in there as well | 02:23 |
jamielennox | what are they? | 02:23 |
ayoung | really just that it needs to specify the plugin... | 02:24 |
jamielennox | I expect the ksc kerberos plugin would be all they should need | 02:24 |
ayoung | yep | 02:24 |
jamielennox | yea, that's ok - all the plugins specify a setuptools entrypoint | 02:24 |
jamielennox | if it's installed it will be available | 02:24 |
ayoung | but if it is a hard dependency it has the same problem..unless we use the config options | 02:24 |
ayoung | which, of course, Django doesn't support | 02:25 |
ayoung | because it is not Oslo config | 02:25 |
jamielennox | why wouldn't django support setuptools stuff? | 02:25 |
ayoung | But rather Django, which means it is a python file read out of ETC instead of a code dir | 02:25 |
jamielennox | so, the config option is just a string, send that to stevedore, load needed plugin | 02:25 |
jamielennox | damn | 02:26 |
jamielennox | back in a bit | 02:26 |
ayoung | ok... | 02:26 |
jamielennox | but yes i think we propose this as external repo at meeting tomorrow | 02:26 |
*** openstackgerrit has quit IRC | 02:33 | |
ayoung | jamielennox, so beyond "use a session" we need D-O-A to load the plugins via Stevedore...that is OK. I think I want to avoid doing a configuration option for it, though...the thought was the DOA should be able to tell from the environment. One thing it will test for is the env vars set for Kerberos | 02:33 |
ayoung | I think that will still work | 02:33 |
*** ayoung has quit IRC | 02:45 | |
*** annasort has joined #openstack-keystone | 02:53 | |
*** wanghong has quit IRC | 02:56 | |
*** KanagarajM has joined #openstack-keystone | 02:57 | |
*** ayoung has joined #openstack-keystone | 03:07 | |
*** amcrn has joined #openstack-keystone | 03:11 | |
*** wanghong has joined #openstack-keystone | 03:13 | |
jamielennox | ayoung: horizon is always going to be kind of funny there because it expects input from users | 03:16 |
jamielennox | i don't think we'll be able to have horizon auto generate an interface for a type of auth plugin or anything | 03:16 |
ayoung | jamielennox, I have a plan there...I'll writew it up tomoorrrow | 03:16 |
jamielennox | but it can at least opportunistically load the library or entrypoint and then do stuff based on whether it's available | 03:16 |
*** stevemar has joined #openstack-keystone | 03:24 | |
*** openstack has joined #openstack-keystone | 03:41 | |
*** gothicmindfood has joined #openstack-keystone | 03:46 | |
*** andreaf_ has joined #openstack-keystone | 03:46 | |
*** cjellick_ has joined #openstack-keystone | 03:46 | |
*** hrybacki has joined #openstack-keystone | 03:46 | |
*** dutsmoc has joined #openstack-keystone | 03:46 | |
*** Ephur has joined #openstack-keystone | 03:46 | |
*** dolphm has joined #openstack-keystone | 03:46 | |
*** hockeynut_ has joined #openstack-keystone | 03:46 | |
*** dtroyer has joined #openstack-keystone | 03:46 | |
*** KanagarajM has joined #openstack-keystone | 03:46 | |
*** stevemar has joined #openstack-keystone | 03:46 | |
*** wanghong has joined #openstack-keystone | 03:46 | |
*** amcrn has joined #openstack-keystone | 03:46 | |
*** ayoung has joined #openstack-keystone | 03:46 | |
*** annasort has joined #openstack-keystone | 03:46 | |
*** nkinder has joined #openstack-keystone | 03:46 | |
*** wwriverrat has joined #openstack-keystone | 03:46 | |
*** mitz_ has joined #openstack-keystone | 03:46 | |
*** miqui has joined #openstack-keystone | 03:46 | |
*** Haneef has joined #openstack-keystone | 03:46 | |
*** arunkant has joined #openstack-keystone | 03:46 | |
*** tim__r has joined #openstack-keystone | 03:46 | |
*** gyee has joined #openstack-keystone | 03:46 | |
*** rodrigods has joined #openstack-keystone | 03:46 | |
*** afaranha has joined #openstack-keystone | 03:46 | |
*** htruta has joined #openstack-keystone | 03:46 | |
*** rkofman has joined #openstack-keystone | 03:46 | |
*** samuelmz has joined #openstack-keystone | 03:46 | |
*** Daviey has joined #openstack-keystone | 03:46 | |
*** bjornar has joined #openstack-keystone | 03:46 | |
*** rm_work has joined #openstack-keystone | 03:46 | |
*** henrynash has joined #openstack-keystone | 03:46 | |
*** boris-42 has joined #openstack-keystone | 03:46 | |
*** roock has joined #openstack-keystone | 03:46 | |
*** Morgan_ has joined #openstack-keystone | 03:46 | |
*** fifieldt_ has joined #openstack-keystone | 03:46 | |
*** xianghui has joined #openstack-keystone | 03:46 | |
*** lsmola_ has joined #openstack-keystone | 03:46 | |
*** jamielennox has joined #openstack-keystone | 03:46 | |
*** larsks has joined #openstack-keystone | 03:46 | |
*** arosen has joined #openstack-keystone | 03:46 | |
*** YorikSar has joined #openstack-keystone | 03:46 | |
*** morganfainberg has joined #openstack-keystone | 03:46 | |
*** jimbaker has joined #openstack-keystone | 03:46 | |
*** afazekas has joined #openstack-keystone | 03:46 | |
*** kevinbenton has joined #openstack-keystone | 03:46 | |
*** palendae has joined #openstack-keystone | 03:46 | |
*** harlowja has joined #openstack-keystone | 03:46 | |
*** grantbow has joined #openstack-keystone | 03:46 | |
*** portante has joined #openstack-keystone | 03:46 | |
*** ekarlso- has joined #openstack-keystone | 03:46 | |
*** adam_g has joined #openstack-keystone | 03:46 | |
*** mflobo has joined #openstack-keystone | 03:46 | |
*** esmute has joined #openstack-keystone | 03:46 | |
*** dhellmann has joined #openstack-keystone | 03:46 | |
*** therve has joined #openstack-keystone | 03:46 | |
*** vishy has joined #openstack-keystone | 03:46 | |
*** bambam1 has joined #openstack-keystone | 03:46 | |
*** rushiagr_away has joined #openstack-keystone | 03:46 | |
*** nonameentername has joined #openstack-keystone | 03:46 | |
*** ctracey has joined #openstack-keystone | 03:46 | |
*** sbasam_ has joined #openstack-keystone | 03:46 | |
*** jraim__ has joined #openstack-keystone | 03:46 | |
*** x-eye has joined #openstack-keystone | 03:46 | |
*** mfisch has joined #openstack-keystone | 03:46 | |
*** dobson has joined #openstack-keystone | 03:46 | |
*** redrobot has joined #openstack-keystone | 03:46 | |
*** EmilienM has joined #openstack-keystone | 03:46 | |
*** hyakuhei has joined #openstack-keystone | 03:46 | |
*** zhiyan has joined #openstack-keystone | 03:46 | |
*** mhu has joined #openstack-keystone | 03:46 | |
*** russellb has joined #openstack-keystone | 03:46 | |
*** radez_g0n3 has joined #openstack-keystone | 03:46 | |
*** gus has joined #openstack-keystone | 03:46 | |
*** serverascode has joined #openstack-keystone | 03:46 | |
*** chmouel has joined #openstack-keystone | 03:46 | |
*** notmyname has joined #openstack-keystone | 03:46 | |
*** rharwood has joined #openstack-keystone | 03:46 | |
*** sudorandom has joined #openstack-keystone | 03:46 | |
*** jamiec has joined #openstack-keystone | 03:46 | |
*** dvorak has joined #openstack-keystone | 03:46 | |
*** marzif__ has joined #openstack-keystone | 03:46 | |
*** uvirtbot has joined #openstack-keystone | 03:46 | |
*** wolsen has joined #openstack-keystone | 03:46 | |
*** gmurphy has joined #openstack-keystone | 03:46 | |
*** anteaya has joined #openstack-keystone | 03:46 | |
*** zigo has joined #openstack-keystone | 03:46 | |
*** gabriel-bezerra has joined #openstack-keystone | 03:46 | |
*** achudnovets has joined #openstack-keystone | 03:46 | |
*** mgagne has joined #openstack-keystone | 03:46 | |
*** ByteSore has joined #openstack-keystone | 03:46 | |
*** shufflebot has joined #openstack-keystone | 03:46 | |
*** csd has joined #openstack-keystone | 03:46 | |
*** d0ugal has joined #openstack-keystone | 03:46 | |
*** ChanServ has joined #openstack-keystone | 03:46 | |
*** dstanek has joined #openstack-keystone | 03:46 | |
*** sendak.freenode.net sets mode: +o ChanServ | 03:46 | |
*** hrybacki has quit IRC | 03:56 | |
*** rm_work has quit IRC | 04:03 | |
*** HenryG has joined #openstack-keystone | 04:07 | |
*** rm_work has joined #openstack-keystone | 04:08 | |
*** rm_work is now known as rm_work|away | 04:08 | |
*** rushiagr_away is now known as rushiagr | 04:29 | |
*** ncoghlan has joined #openstack-keystone | 04:32 | |
*** dutsmoc is now known as comstud | 04:33 | |
*** gokrokve has joined #openstack-keystone | 04:46 | |
*** gokrokve has quit IRC | 04:51 | |
*** stevemar has quit IRC | 04:52 | |
*** ncoghlan is now known as ncoghlan_afk | 05:00 | |
*** ncoghlan_afk is now known as ncoghlan | 05:03 | |
*** ncoghlan is now known as ncoghlan_afk | 05:03 | |
*** rushiagr is now known as rushiagr_away | 05:07 | |
*** ayoung has quit IRC | 05:10 | |
*** gabriel-bezerra has quit IRC | 05:17 | |
*** rushiagr_away is now known as rushiagr | 05:21 | |
*** gyee has quit IRC | 05:22 | |
*** gabriel-bezerra has joined #openstack-keystone | 05:23 | |
*** gokrokve has joined #openstack-keystone | 05:46 | |
*** harlowja is now known as harlowja_away | 05:47 | |
*** gokrokve has quit IRC | 05:50 | |
*** afazekas_ has joined #openstack-keystone | 05:55 | |
*** ncoghlan_afk is now known as ncoghlan | 05:55 | |
*** jaosorior has joined #openstack-keystone | 06:04 | |
*** ajayaa has joined #openstack-keystone | 06:18 | |
*** ukalifon has joined #openstack-keystone | 06:45 | |
*** gokrokve has joined #openstack-keystone | 06:46 | |
*** gokrokve has quit IRC | 06:51 | |
jaosorior | henrynash, are you around? | 07:02 |
*** BAKfr has joined #openstack-keystone | 07:09 | |
*** dguitarbite has joined #openstack-keystone | 07:22 | |
mflobo | Someone has problems using Tox and the new requirements? | 07:44 |
mflobo | I have some problems related to cffi library | 07:44 |
*** gokrokve has joined #openstack-keystone | 07:46 | |
henrynash | jaosorior: hi | 07:48 |
*** gokrokve has quit IRC | 07:51 | |
*** openstackgerrit has joined #openstack-keystone | 07:52 | |
mflobo | Ok, my problem was solved installing libffi-devel library | 07:54 |
*** bvandenh has joined #openstack-keystone | 07:56 | |
*** Alexander has joined #openstack-keystone | 07:57 | |
*** Alexander is now known as Guest63524 | 07:57 | |
*** Guest63524 has quit IRC | 07:58 | |
*** amakarov has joined #openstack-keystone | 07:58 | |
jaosorior | henrynash: hey, are you acquainted with the module keystone.assignment.controllers? specifically the assignment inheritance stuff? need some help with it | 08:12 |
henrynash | jaosorior: yes, I’m somewhat famiiar with it | 08:12 |
jaosorior | I was refactoring some of those functions (I guess I'll have to wait for Kilo to finish it) and there is some stuff that was there that I would like to understand better, since it was pointed out by someone; And since you're kind of in my timezone I thought you could help; Got some minutes to look at this? | 08:15 |
jaosorior | https://review.openstack.org/#/c/119363/2/keystone/assignment/controllers.py | 08:15 |
*** andreaf_ is now known as andreaf | 08:25 | |
*** ncoghlan has quit IRC | 08:28 | |
*** KanagarajM2 has joined #openstack-keystone | 08:38 | |
*** KanagarajM has quit IRC | 08:38 | |
*** xianghuihui has joined #openstack-keystone | 08:45 | |
*** gokrokve has joined #openstack-keystone | 08:46 | |
*** gokrokve has quit IRC | 08:47 | |
*** gokrokve has joined #openstack-keystone | 08:48 | |
*** xianghuihuihui has joined #openstack-keystone | 08:49 | |
*** xianghuihui has quit IRC | 08:49 | |
*** gokrokve has quit IRC | 08:52 | |
*** aix has joined #openstack-keystone | 08:53 | |
*** amcrn has quit IRC | 08:54 | |
*** Dafna has joined #openstack-keystone | 08:55 | |
*** cjellick has joined #openstack-keystone | 08:58 | |
*** cjellick_ has quit IRC | 09:00 | |
*** fmarco76 has joined #openstack-keystone | 09:19 | |
*** openstackgerrit has joined #openstack-keystone | 09:19 | |
*** fmarco76 has quit IRC | 09:19 | |
*** rushiagr is now known as rushiagr_away | 09:21 | |
openstackgerrit | Alexander Makarov proposed a change to openstack/keystone: PKI and PKIZ tokens unnecessary whitespace removed https://review.openstack.org/120043 | 09:28 |
*** rushiagr_away is now known as rushiagr | 09:34 | |
*** KanagarajM2 has quit IRC | 09:39 | |
*** KanagarajM has joined #openstack-keystone | 09:44 | |
*** gokrokve has joined #openstack-keystone | 09:46 | |
*** gokrokve has quit IRC | 09:51 | |
*** aix has quit IRC | 10:00 | |
*** KanagarajM has quit IRC | 10:08 | |
*** KanagarajM has joined #openstack-keystone | 10:11 | |
*** aix has joined #openstack-keystone | 10:16 | |
openstackgerrit | Marcos FermÃn Lobo proposed a change to openstack/keystone: Templated catalog backend V3 not implemented https://review.openstack.org/120011 | 10:25 |
*** ukalifon2 has joined #openstack-keystone | 10:32 | |
*** ukalifon has quit IRC | 10:32 | |
openstackgerrit | A change was merged to openstack/keystone: Prevent domains creation for the default LDAP+SQL https://review.openstack.org/116858 | 10:34 |
*** xianghuihuihui has quit IRC | 10:40 | |
*** gokrokve has joined #openstack-keystone | 10:46 | |
*** topol has joined #openstack-keystone | 10:49 | |
*** gokrokve has quit IRC | 10:51 | |
openstackgerrit | Yuriy Taraday proposed a change to openstack/keystonemiddleware: Add a pool of memcached clients https://review.openstack.org/119774 | 11:01 |
openstackgerrit | Yuriy Taraday proposed a change to openstack/keystone: Add a pool of memcached clients https://review.openstack.org/119452 | 11:01 |
*** dims has joined #openstack-keystone | 11:11 | |
*** diegows has joined #openstack-keystone | 11:22 | |
*** wwriverrat has quit IRC | 11:31 | |
*** wwriverrat has joined #openstack-keystone | 11:31 | |
*** gordc has joined #openstack-keystone | 11:32 | |
*** gokrokve has joined #openstack-keystone | 11:46 | |
*** gokrokve has quit IRC | 11:51 | |
*** andreaf_ has joined #openstack-keystone | 11:54 | |
openstackgerrit | Marcos FermÃn Lobo proposed a change to openstack/keystone: Templated catalog backend V3 not implemented https://review.openstack.org/120011 | 11:55 |
*** andreaf has quit IRC | 11:56 | |
bjornar | How can I prevent pki token beeing stored in database? | 11:58 |
bjornar | I mean... does it need to be stored? | 11:58 |
*** gothicmindfood has quit IRC | 12:01 | |
*** gothicmindfood has joined #openstack-keystone | 12:05 | |
*** raildo has joined #openstack-keystone | 12:07 | |
*** dims has quit IRC | 12:11 | |
*** dims has joined #openstack-keystone | 12:12 | |
*** dims_ has joined #openstack-keystone | 12:12 | |
*** dims_ has quit IRC | 12:14 | |
*** dims_ has joined #openstack-keystone | 12:15 | |
*** dims has quit IRC | 12:16 | |
*** ChanServ sets mode: +o dolphm | 12:16 | |
ajayaa | bjornanr, You can't prevent pki tokens from being stored in db as of now. | 12:19 |
ajayaa | Work is still going on to make pki tokens non persistent in database. | 12:20 |
ajayaa | bjornar, ^^ | 12:20 |
*** KanagarajM has quit IRC | 12:21 | |
bjornar | ajayaa, ok.. what is the limiting factor? | 12:40 |
bjornar | Also, when do you use python-openssl or something instead of launching openssl binary? | 12:40 |
bjornar | I am struggeling with trying to understand why keystone is spending ~200 msecs logging me in.. | 12:41 |
*** gokrokve has joined #openstack-keystone | 12:46 | |
*** gokrokve has quit IRC | 12:50 | |
bjornar | ajayaa, ? | 12:53 |
ajayaa | bjornar, limiting factor for? | 12:53 |
*** hrybacki has joined #openstack-keystone | 12:54 | |
*** cdnchris has joined #openstack-keystone | 12:55 | |
bjornar | ajayaa, commenting out the INSERT INTO token (id, expires, extra, valid, user_id, trust_id) VALUES (... | 12:57 |
ajayaa | bjornar, I don't understand what you are trying to convey. | 12:58 |
*** topol has quit IRC | 12:58 | |
*** hrybacki has quit IRC | 12:58 | |
bjornar | The whole point afaik with PKI tokens is they can be verified by each agent locally without needing to query keystone (except revoke polling) | 12:59 |
bjornar | then I dont understand why token is inserted into db | 12:59 |
ajayaa | for revoke polling, I guess. Right now the revoke call returns a list of tokens which are revoked. | 12:59 |
ajayaa | bjornar, If you don't store the pki tokens, you have no way of knowing which pki tokens are revoked. | 13:01 |
ajayaa | dophm, | 13:01 |
ajayaa | dolphm, ^^ | 13:01 |
bjornar | hmm.. | 13:01 |
ajayaa | But going forward when token revocation events are in place, we won't need to store pki tokens. | 13:02 |
bjornar | ok, so is this planned for Juno? | 13:02 |
bjornar | And also, is using some libssl planned for Juno? | 13:03 |
ajayaa | I am unaware of release plans. I have pinged the PTL for keystone already. He is the right person to ask this question, imo. | 13:05 |
bjornar | Ok.. | 13:05 |
bjornar | Also, do you have any clues for me where the main bottleneck in posts to v2.0/tokens (or v3) is? | 13:06 |
bjornar | I am seeing ~200ms now, and I dont really see what is taking time... | 13:06 |
bjornar | openssl is using ~ 8ms | 13:06 |
bjornar | sql token insert is Query_time: 0.004509 Lock_time: 0.000892 | 13:06 |
*** jasondotstar has joined #openstack-keystone | 13:07 | |
ajayaa | Do you have you users in db or ldap? | 13:08 |
bjornar | db | 13:08 |
ajayaa | Is it a local call? if not so, network latency perhaps. | 13:08 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Allow providing an endpoint_override to requests https://review.openstack.org/117399 | 13:08 |
bjornar | should not be, im on 2x 10Gb SFP+ | 13:09 |
*** radez_g0n3 is now known as radez | 13:10 | |
*** nkinder has quit IRC | 13:10 | |
openstackgerrit | A change was merged to openstack/keystone: Update paste pipelines in configuration docs https://review.openstack.org/118533 | 13:12 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Handle invalidate in identity plugins correctly https://review.openstack.org/112440 | 13:12 |
ajayaa | bjornar, no idea mate. :( | 13:13 |
bjornar | Trying to analyse a pcap now | 13:13 |
ajayaa | Wait for an hour or so. It's almost time for keystone cores to be here. | 13:13 |
*** vhoward has joined #openstack-keystone | 13:16 | |
bjornar | ok, I will.. | 13:17 |
bjornar | See lots of crap in this pcap, so perhaps someone would like to have a look at it | 13:18 |
dolphm | ajayaa: the legacy token revocation list required tokens to be persisted so that they could be revoked. that's where token revocation events come in... we describe attributes of revoked tokens instead of enumerating the tokens themselves | 13:19 |
*** cdnchris has quit IRC | 13:21 | |
*** hrybacki has joined #openstack-keystone | 13:23 | |
*** cdnchris has joined #openstack-keystone | 13:24 | |
*** richm has joined #openstack-keystone | 13:25 | |
*** stevemar has joined #openstack-keystone | 13:31 | |
*** wanghong has quit IRC | 13:32 | |
*** wanghong has joined #openstack-keystone | 13:33 | |
*** bknudson has joined #openstack-keystone | 13:35 | |
*** hrybacki has quit IRC | 13:39 | |
*** r-daneel has joined #openstack-keystone | 13:43 | |
bjornar | ajayaa, so, who should I talk to about this? | 13:45 |
*** gokrokve has joined #openstack-keystone | 13:46 | |
*** joesavak has joined #openstack-keystone | 13:47 | |
ajayaa | bjornar, dolphm | 13:48 |
ajayaa | Please ping him here. | 13:48 |
*** cdnchris has quit IRC | 13:49 | |
bjornar | dolphm, there? | 13:49 |
*** gokrokve has quit IRC | 13:51 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 13:53 | |
*** sigmavirus24 has joined #openstack-keystone | 13:53 | |
*** nkinder has joined #openstack-keystone | 13:59 | |
*** topol has joined #openstack-keystone | 14:00 | |
BAKfr | hi guys | 14:00 |
BAKfr | I've a question about the behavior of delete_grant() in assignment/core.py | 14:00 |
BAKfr | If the method receive a project_id, can we revoke only tokens associated to this project ? | 14:01 |
BAKfr | I means, Is it safe to modify code, for replacing _emit_invalidate_user_token_persistence() by _emit_invalidate_user_project_tokens_notification() ? | 14:01 |
stevemar | bknudson, care to revisit: https://review.openstack.org/#/c/119422/ | 14:09 |
*** ajayaa has quit IRC | 14:09 | |
*** jimhoagland has joined #openstack-keystone | 14:10 | |
*** jsavak has joined #openstack-keystone | 14:15 | |
openstackgerrit | Steve Martinelli proposed a change to openstack/python-keystoneclient: Use oslo_debug_helper and remove our own version https://review.openstack.org/120104 | 14:15 |
*** jimhoagland has quit IRC | 14:15 | |
*** joesavak has quit IRC | 14:17 | |
*** joesavak has joined #openstack-keystone | 14:18 | |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystonemiddleware: Use oslo_debug_helper and remove our own version https://review.openstack.org/120105 | 14:19 |
*** jsavak has quit IRC | 14:20 | |
*** jorge_munoz has joined #openstack-keystone | 14:22 | |
bjornar | dolphm, I am looking a bit into keystone performance, and have some interesting finds, would you care to have a look? | 14:23 |
*** david-lyle has joined #openstack-keystone | 14:25 | |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Add characterization test for cleanup role assignments for group https://review.openstack.org/119630 | 14:25 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Fix delete group cleans up role assignments with LDAP https://review.openstack.org/119631 | 14:25 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Fix using local ID to clean up user/group assignments https://review.openstack.org/119629 | 14:25 |
openstackgerrit | Brant Knudson proposed a change to openstack/keystone: Fix LDAP group role assignment listing https://review.openstack.org/119480 | 14:25 |
dolphm | bjornar: i read your messages earlier - do you have anything else? | 14:25 |
bjornar | I am looking at what keystone does through tcpdump, and it has a lot of interesting queries... | 14:26 |
dstanek | bjornar: one of the things i hate is that we don't allow the sql engine to fail on foreign keys and instead always do a lookup by id | 14:27 |
*** gokrokve has joined #openstack-keystone | 14:27 | |
bjornar | http://pastie.org/private/xtqz4b8vfkmhmbnh00q | 14:29 |
openstackgerrit | A change was merged to openstack/python-keystoneclient: Add version parameter to adapter. https://review.openstack.org/117669 | 14:29 |
bjornar | Between these "legit" queries are atleast one commit, one rollback, and one select 1... | 14:29 |
openstackgerrit | A change was merged to openstack/keystone: Update the revocation configuration docs https://review.openstack.org/118536 | 14:29 |
bjornar | so multiply these queries by 4 | 14:29 |
bjornar | ... this is just a post to v2.0/tokens | 14:30 |
bjornar | and completely isolated | 14:30 |
bjornar | I can make the entire tcpdump public if you like. | 14:31 |
dstanek | bjornar: i was working on reducing the object lookup, but it's a redesign that i haven't figured out enough to write a spec | 14:31 |
*** cjellick has quit IRC | 14:32 | |
bjornar | The way I see it now, keystone is not optimal. Right not using 200ms to provide me a token. Could probably make that number look a little nicer, but the real problem here is in the code | 14:32 |
dstanek | bjornar: the problem is the design | 14:33 |
bjornar | 17 queries (many of them duplicated) (*4 (query + rollback + commit + select 1) | 14:33 |
bjornar | that makes a total of 68 db queries | 14:34 |
dolphm | bjornar: are you running with caching? | 14:34 |
bjornar | no | 14:34 |
dolphm | bjornar: http://docs.openstack.org/developer/keystone/configuration.html#caching-layer | 14:34 |
dstanek | bjornar: the two main issues are that we have to rely on the select by id queries because we use sqlite in our unit tests and some may be needed because there may be mixed backends (ldap + sql) | 14:35 |
dolphm | mixed backends are the expensive use case | 14:35 |
bjornar | So caching is fine also with distributed keystone-main/admin? | 14:35 |
dstanek | dolphm: :-) yeah, boo | 14:35 |
bjornar | Now we are basing this on galera | 14:36 |
bjornar | and memcache does not have replication afaik | 14:36 |
dstanek | bknudson: also the commit/rollback shenanagans are probably sqlalchemy or how we are using it | 14:36 |
dstanek | bjornar: you don't need replication for memcache | 14:36 |
dolphm | bjornar: yeah, just set your cache expirations appropriately low. we try, but i'm sure we don't invalidate as thoroughly as we could | 14:36 |
*** ayoung has joined #openstack-keystone | 14:37 | |
dolphm | memcache is fast because it's not complicated :) | 14:37 |
bjornar | yeah | 14:37 |
bjornar | but I guess tokens still have to live in db | 14:37 |
openstackgerrit | Alexander Makarov proposed a change to openstack/keystone: PKI and PKIZ tokens unnecessary whitespace removed https://review.openstack.org/120043 | 14:37 |
dolphm | bjornar: if you think you need replication, we support other cache backends via dogpile | 14:37 |
dolphm | bjornar: but i'd recommend pylibmc + memcached as the first choice option | 14:38 |
dstanek | bjornar: nothing is permanently stored in memcache - it just caches some of the DB calls | 14:38 |
bjornar | ..also, I dont like to introduce cache layer to early. Then you dont find the real bottlenecs ;) | 14:38 |
dolphm | bjornar: are you running a stable release or master? | 14:38 |
bjornar | icehouse just now. all wsgi | 14:38 |
dolphm | bjornar: i'd be curious to hear your experience with icehouse vs master then, both without caching | 14:39 |
dolphm | bjornar: juno-rc1 will be available in a couple weeks | 14:39 |
bjornar | Waiting for that... | 14:39 |
bjornar | You are probably going to paris aswell, so can perhaps speak to you there | 14:40 |
dolphm | bjornar: the bug countdown has begun https://launchpad.net/keystone/+milestone/juno-rc1 | 14:40 |
dolphm | i will certainly be there | 14:40 |
dolphm | in fact, i need to book stuff today. you should too, dstanek! | 14:40 |
bjornar | I can do some more work in publishing the isolated tcpdump of the different keystone api calls, perhaps it will get some performance work into focus | 14:42 |
dolphm | bjornar: open bugs where you see obvious bottlenecks (and tag them with 'performance' if you don't mind) | 14:42 |
dolphm | bjornar: https://bugs.launchpad.net/keystone/+bugs?field.tag=performance | 14:42 |
bjornar | yeah.. Id make a general report I thing, and can add that to the tracker | 14:43 |
bjornar | It doesnt take a genious to understand that doing: | 14:43 |
bjornar | SELECT domain.id AS domain_id, domain.name AS domain_name, domain.enabled AS domain_enabled, domain.extra AS domain_extra FROM domain WHERE domain.id = 'default' | 14:43 |
bjornar | 4 times from the same program is not very smart | 14:44 |
bjornar | ...ofcorse a cachelayer hides that problem... | 14:44 |
bjornar | but its even easier to just fix it! | 14:44 |
*** mitz has joined #openstack-keystone | 14:49 | |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Adds pipeline hints to the example paste config https://review.openstack.org/119827 | 14:49 |
dstanek | dolphm: yeah, i saw the email this morning | 14:50 |
bjornar | later | 14:51 |
openstackgerrit | Alvaro Lopez Garcia proposed a change to openstack/python-keystoneclient: auth_token: http_connect_timeout should be an int https://review.openstack.org/117213 | 14:55 |
dolphm | bjornar: morganfainberg's work on https://blueprints.launchpad.net/keystone/+spec/non-persistent-tokens in part minimizes redundant queries - but it's not feature complete in juno. contributions welcome for kilo :) | 14:55 |
openstackgerrit | Steve Martinelli proposed a change to openstack/keystone: Adds hint about filter placement to extension docs https://review.openstack.org/119834 | 14:56 |
openstackgerrit | Marcos FermÃn Lobo proposed a change to openstack/keystone: Keystone part of a PoC for Horizon/Keystone WebSSO https://review.openstack.org/106096 | 14:59 |
*** wwriverrat has quit IRC | 15:00 | |
amakarov | nkinder, hi! What means attrs='[1.1]' in a call to ldap_connection.search_s()? Found nothing in docs about it ( Is there a field named '[1.1]' in LDAP structure? | 15:02 |
nkinder | amakarov: 1.1 is a special attribute in the LDAP RFCs that means "no attributes" | 15:03 |
morganfainberg | mornin | 15:03 |
morganfainberg | dolphm, omg booking travel! | 15:04 |
dolphm | morganfainberg: ++ | 15:04 |
morganfainberg | dolphm, i should be landing there on Nov 2 (couldn't swing nov1 due to an appt i couldn't reschedule) | 15:05 |
morganfainberg | nkinder, ping | 15:06 |
dolphm | morganfainberg: probably same for me | 15:06 |
morganfainberg | nkinder, re https://review.openstack.org/#/c/119578/ | 15:06 |
nkinder | amakarov: see the end of section 4.5.1 in http://tools.ietf.org/html/rfc2251 | 15:06 |
nkinder | morganfainberg: pong | 15:06 |
*** cdnchris has joined #openstack-keystone | 15:06 | |
nkinder | amakarov: I'd have to track it down in the newer 45xx series of RFCs | 15:07 |
morganfainberg | nkinder, are the changes in patchset 2/3 covered in the master change? | 15:07 |
morganfainberg | nkinder, i'll 2x check but before i do i figured i'd ask | 15:07 |
nkinder | morganfainberg: yes | 15:07 |
morganfainberg | nkinder, ok. just saw that we had additional patchsets and changes in a backport. | 15:08 |
nkinder | morganfainberg: I double checked all search_s() calls in the assignment driver in master, and it looks good. | 15:08 |
*** jimhoagland has joined #openstack-keystone | 15:08 | |
nkinder | morganfainberg: yes, I should have done an exhaustive search when doing the backport | 15:08 |
YorikSar | morganfainberg: Hi. | 15:08 |
morganfainberg | nkinder, ok i'll run through it as well, but just wanted a 2x check with you first | 15:09 |
morganfainberg | nkinder, thanks! | 15:09 |
nkinder | morganfainberg: ++ | 15:09 |
morganfainberg | YorikSar, mornin | 15:09 |
YorikSar | morganfainberg: I've been asked to investigate if the same approach to memcached connections can be applied to Havana and there I found that token backend relies on cas() operation. | 15:09 |
nkinder | amakarov: the '1.1' attribute is also described in the ldapsearch man page | 15:09 |
YorikSar | morganfainberg: Is this still the case for Icehouse/Juno? | 15:09 |
amakarov | nkinder, thanks, didn't know | 15:10 |
nkinder | amakarov: sure | 15:10 |
morganfainberg | YorikSar, it wont be accepted for upstream havana | 15:10 |
morganfainberg | YorikSar, well... it *might* be since it's security associated, but lets work on master / icehouse first | 15:10 |
*** afazekas_ has quit IRC | 15:11 | |
morganfainberg | YorikSar, havana is almost EOL so it might not make it, depending on timeing | 15:11 |
YorikSar | morganfainberg: We have a customer tied to Havana, so I should at least tell them if we're going to backport that in-house. | 15:11 |
YorikSar | morganfainberg: But my question is about I/J... If cas() is used somewhere there we might get troubles with current approach. | 15:12 |
openstackgerrit | Peter Razumovsky proposed a change to openstack/keystone: Refactor LDAP backend using context manager for connection https://review.openstack.org/118138 | 15:12 |
dstanek | dolphm, morganfainberg: what days are your arriving/leaving? | 15:12 |
morganfainberg | YorikSar, icehouse *shouldn't* use CAS | 15:12 |
YorikSar | morganfainberg: Good :) | 15:13 |
morganfainberg | dstanek, i'm arriving on thr 2nd, checking out of the conf. hotel on the 8th, i might be staying longer cause... france. | 15:13 |
morganfainberg | YorikSar, let me 2x check though | 15:13 |
YorikSar | morganfainberg: I've already started to think if I'm so lucky that we never ran into problems with it. | 15:13 |
morganfainberg | YorikSar, however, havana uses cas fairly extensively | 15:14 |
morganfainberg | oh i mean in one place:P | 15:14 |
morganfainberg | https://github.com/openstack/keystone/blob/stable/havana/keystone/token/backends/memcache.py#L189 <<-- YorikSar | 15:14 |
YorikSar | morganfainberg: btw, why does it use it? | 15:14 |
morganfainberg | YorikSar, was used to update the user token list | 15:14 |
morganfainberg | YorikSar, fixed it in icehouse due to horrible performance. | 15:14 |
YorikSar | morganfainberg: Ah, I guess because we didn't use dogpile.cache there :) | 15:15 |
morganfainberg | YorikSar, that too | 15:15 |
dolphm | dstanek: arriving Nov 2nd (although I might try to work out how Nov 1st would look) | 15:15 |
dolphm | dstanek: and staying until the thursday *after* the summit | 15:15 |
morganfainberg | yeah i want to stay longer but i think i want to airbnb it instead of $$$ conf. hotel if i do | 15:16 |
*** cds has joined #openstack-keystone | 15:18 | |
*** ukalifon2 has quit IRC | 15:18 | |
*** david-lyle has quit IRC | 15:19 | |
bknudson | I'm also going to be hanging around paris after the conf. | 15:24 |
dolphm | morganfainberg: i'm looking at airbnb too | 15:24 |
dolphm | bknudson: where are you staying? | 15:25 |
*** cjellick has joined #openstack-keystone | 15:25 | |
bknudson | dolphm: i'm going to meet my mom there. she says it's the best western louvre | 15:25 |
bknudson | dolphm: I didn't try to tell her to use airbnb | 15:26 |
*** mikedillion has joined #openstack-keystone | 15:27 | |
*** zzzeek has joined #openstack-keystone | 15:31 | |
*** dhellmann is now known as dhellmann_ | 15:38 | |
*** lmtaylor1 has joined #openstack-keystone | 15:39 | |
*** gokrokve_ has joined #openstack-keystone | 15:41 | |
*** gokrokve has quit IRC | 15:44 | |
*** cdnchris has quit IRC | 15:48 | |
*** david-lyle has joined #openstack-keystone | 15:48 | |
dstanek | hmmm...looks like i need to find a crash course on french | 15:50 |
bknudson | dstanek: you learn the verbs and I'll learn the nouns | 15:51 |
dstanek | bknudson: i was thinking something more like 'must pee', 'need food' and 'where's my car?' | 15:52 |
bknudson | dstanek: Je dois pisser ! | 15:53 |
bknudson | dstanek: besoin de nourriture | 15:54 |
*** bvandenh has quit IRC | 15:55 | |
jaosorior | dstanek: if you know some spanish it seems that the parisians don't hate it so much :) :P | 16:02 |
*** wwriverrat has joined #openstack-keystone | 16:03 | |
jaosorior | If that helps in anything | 16:03 |
dstanek | jaosorior: i know 'no habla spanish' :-) | 16:03 |
jaosorior | Haha damn, well, it's going to be interesting then | 16:05 |
*** lvh has joined #openstack-keystone | 16:05 | |
lvh | Hello :-) | 16:05 |
*** marcoemorais has joined #openstack-keystone | 16:05 | |
*** wwriverrat has left #openstack-keystone | 16:20 | |
*** BAKfr has quit IRC | 16:21 | |
*** rm_work|away is now known as rm_work | 16:27 | |
rm_work | ayoung: yes, the use of the term "hijack" is a very specific wording choice on my part... I am trying to spark a debate there | 16:28 |
rm_work | ayoung: I am not sure how else it can be done though, but if people have problems with that, I want to hear it -- not trying to hide or abstract away that interaction in pretty language | 16:28 |
*** gokrokve_ has quit IRC | 16:32 | |
*** jimhoagland has quit IRC | 16:35 | |
*** david-lyle has quit IRC | 16:35 | |
*** david-lyle has joined #openstack-keystone | 16:36 | |
*** bjornar_ has joined #openstack-keystone | 16:40 | |
*** wwriverrat has joined #openstack-keystone | 16:40 | |
ayoung | rm_work, what are we talking about again? | 16:42 |
*** jimhoagland has joined #openstack-keystone | 16:42 | |
*** gordc has quit IRC | 16:43 | |
*** rushiagr is now known as rushiagr_away | 16:49 | |
openstackgerrit | Victor Sergeyev proposed a change to openstack/keystone: Remove of using session in migration 042 https://review.openstack.org/120146 | 16:49 |
*** andreaf has joined #openstack-keystone | 16:53 | |
*** Daviey has quit IRC | 16:53 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 16:55 | |
*** Daviey has joined #openstack-keystone | 17:01 | |
*** rkofman has quit IRC | 17:04 | |
bjornar_ | Would be nice if the keystone wsgi file could be updated | 17:04 |
*** rkofman has joined #openstack-keystone | 17:05 | |
rm_work | ayoung: probably this: http://i.imgur.com/fldU3OW.png | 17:08 |
morganfainberg | bjornar_, in what way? | 17:08 |
bjornar_ | I dunno, perhaps its my virtualenv that is playing games atm.. | 17:11 |
*** cdnchris has joined #openstack-keystone | 17:11 | |
*** dhellmann_ is now known as dhellmann | 17:13 | |
*** lmtaylor1 has quit IRC | 17:13 | |
*** rushiagr_away is now known as rushiagr | 17:14 | |
*** rushiagr is now known as rushiagr_away | 17:20 | |
*** gokrokve has joined #openstack-keystone | 17:21 | |
*** rushiagr_away is now known as rushiagr | 17:21 | |
*** rushiagr is now known as rushiagr_away | 17:23 | |
*** ukalifon has joined #openstack-keystone | 17:24 | |
*** cdnchris has quit IRC | 17:25 | |
*** harlowja_away is now known as harlowja | 17:25 | |
bjornar_ | What does this mean: | 17:28 |
bjornar_ | CRITICAL keystone.service [-] 'DomainV3' object has no attribute 'assignment_api' | 17:28 |
*** amcrn has joined #openstack-keystone | 17:28 | |
*** lmtaylor1 has joined #openstack-keystone | 17:29 | |
*** lmtaylor1 has left #openstack-keystone | 17:30 | |
openstackgerrit | Aaron Rosen proposed a change to openstack/python-keystoneclient: Sync with latest oslo-incubator https://review.openstack.org/119451 | 17:31 |
arosen | Hi, could I get a few keystone cores to approve this oslo-incubator sync https://review.openstack.org/#/c/119451/ . This fixes a bug that i'm hitting in the python-congressclient :/ | 17:33 |
openstackgerrit | Brad Topol proposed a change to openstack/keystone: Keystone local authenticate has an unnecessary pending audit record. https://review.openstack.org/120162 | 17:36 |
dstanek | dhellmann: you around? | 17:42 |
*** gyee has joined #openstack-keystone | 17:46 | |
*** david-lyle has quit IRC | 17:50 | |
*** cds has quit IRC | 17:50 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 17:59 | |
*** wwriverrat has left #openstack-keystone | 18:01 | |
openstackgerrit | A change was merged to openstack/keystone: Add rst code-blocks to a bunch of missing examples https://review.openstack.org/119210 | 18:02 |
dhellmann | dstanek: here | 18:03 |
rm_work | ayoung / nkinder: http://goo.gl/x6oBZu | 18:09 |
nkinder | rm_work: oooh, fancy... :) | 18:10 |
*** dims has joined #openstack-keystone | 18:11 | |
*** dims_ has quit IRC | 18:11 | |
*** dims has quit IRC | 18:12 | |
nkinder | rm_work: looks good/accurate from a trust standpoint | 18:12 |
*** ukalifon has quit IRC | 18:13 | |
*** dims_ has joined #openstack-keystone | 18:16 | |
openstackgerrit | Jamie Lennox proposed a change to openstack/python-keystoneclient: Allow fetching user_id/project_id from auth https://review.openstack.org/118520 | 18:16 |
ayoung | nkinder, yeah, he does nice work. | 18:16 |
ayoung | rm_work, letys chat after the Keystone meeting. I think I can help tweak that a bit | 18:16 |
rm_work | ayoung: ok. I did forget to do the "if Trust doesn't already exist)" part; just fixed it | 18:18 |
ayoung | rm_work, so, what we really want is "precanned trusts" | 18:19 |
rm_work | ayoung: in a way, yes | 18:19 |
ayoung | I don't want Barbican, or anyone else, giving me a blank check to sign for them | 18:19 |
rm_work | though for security purposes I like that the user has to pass their key to us *at least once* in order for us to make one | 18:19 |
ayoung | the trusts should be definied before the user hjas to execute them | 18:19 |
ayoung | rm_work, orthogonal to my complaint | 18:20 |
rm_work | hmm | 18:20 |
nkinder | ayoung: so user creates trust, passes trust ID to LBaaS | 18:20 |
rm_work | well, the other option is "to use our service, please create a trust on your account for this user: <lbaas user>" | 18:20 |
rm_work | and force the user to do it beforehand | 18:20 |
rm_work | yeah | 18:20 |
nkinder | rm_work: yeah, that's the ideal situation from a security POV | 18:20 |
rm_work | hmm | 18:20 |
ayoung | nkinder, sort of...I was thinking an earlier stage which is "post a template of the trust for the world to review" | 18:20 |
bjornar_ | running in virtualenv with master, I get: keystone.common.wsgi ImportError: No module named MySQLdb | 18:20 |
ayoung | and then, yes, as you wrote it | 18:21 |
nkinder | but, ease-of-use often wins out over security... :( | 18:21 |
ayoung | rm_work, but thereis a keystone meeting now...at 15:00 Eastern (40 minutes) OK? | 18:21 |
rm_work | yeah, if we could give them a template and all they had to do was say "I accept"... :P | 18:21 |
rm_work | ok | 18:21 |
rm_work | I'll be around | 18:21 |
nkinder | bjornar: you pip installed requirements and test-requirements in your virtualenv? | 18:21 |
bjornar_ | nkinder, does not the tools/install_venv.py take care of that? | 18:22 |
nkinder | bjornar: my workflow is 'virtualenv ./.venv; source ./.venv/bin/activate; pip install -r ./requirements.txt; pip install -r ./test-requirements.txt; pip install -e .' | 18:23 |
nkinder | bjornar: then ./run-tests.sh | 18:24 |
nkinder | bjornar: that worked for me with master yesterday | 18:24 |
bjornar_ | hmm.. requrements are installed | 18:24 |
nkinder | bjornar: you might need some C libs installed for things too | 18:26 |
bjornar_ | Ok.. but does it silently skip? | 18:26 |
nkinder | bjornar: but you would notice build errors when insttalling the requirements if that was the case (missing headers, etc.) | 18:26 |
nkinder | bjornar: it should not silently skip | 18:26 |
bjornar_ | could be I dont have mysql dev files.. | 18:28 |
bjornar_ | its probably sqlalchemy that should provide the mysqldb stuff? | 18:29 |
*** lmtaylor1 has joined #openstack-keystone | 18:30 | |
*** jaosorior has quit IRC | 18:32 | |
nkinder | bjornar: let me see what I usually install on a new dev system... | 18:34 |
*** henrynash has quit IRC | 18:35 | |
*** jaosorior has joined #openstack-keystone | 18:35 | |
nkinder | bjornar: on Fedora, I usually hav to install 'libxml-devel libxslt-devel sqlite-devel openldap-devel openssl-devel python-repoze-lru python-virtualenv python-tox' | 18:35 |
dstanek | bjornar: we don't have mysqldb in our requirements files - you have to add that by hand | 18:36 |
nkinder | bjornar: that list could be out of date though, as I think that was from the icehouse cycle | 18:36 |
*** henrynash has joined #openstack-keystone | 18:36 | |
bjornar_ | yeah | 18:36 |
dstanek | dhellmann: re: the pbr issue - that bug you linked to uses a different setting | 18:36 |
bjornar_ | should perhaps be there | 18:37 |
dstanek | bjornar: our tests don't currently run on a real database :-( | 18:37 |
bjornar_ | oh | 18:38 |
*** amcrn has quit IRC | 18:40 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed a change to openstack/keystone: Improve list role assignments filters performance https://review.openstack.org/116682 | 18:58 |
dolphm | i should advertise this too if anyone is interested... this is a list of every keystone review, sorted into "may land in RC1 vs blocked until Kilo" https://gist.github.com/dolph/bddbb047f06431f535c6 i probably won't add new patches to the "may land" list | 19:01 |
*** joesavak has quit IRC | 19:01 | |
ayoung | rm_work, OK...let me look again | 19:02 |
*** amakarov has quit IRC | 19:02 | |
jamielennox | also whilst people are here - i don't intend to be at next weeks (or the following 3) meeting - so if you need anything get me this week | 19:02 |
*** openstackgerrit has quit IRC | 19:02 | |
ayoung | jamielennox, any last reviews still burning? | 19:03 |
ayoung | rm_work, OK, so how about the following changes: | 19:04 |
jamielennox | ayoung: i've got a few i want to get through, about a 50% pass rate from gate from yesterday :p | 19:04 |
ayoung | first of all, the trust should not require impersonation | 19:04 |
*** henrynash has quit IRC | 19:04 | |
ayoung | just do the logic based on "user_id or trustor_id" will work in the policy file, though | 19:04 |
rm_work | ayoung: well, the Barbican side requires two things -- that we "look like the user", but also that we have a service-admin role | 19:04 |
rm_work | we need to be "the user, with service-admin | 19:05 |
rm_work | ", which the user won't have | 19:05 |
ayoung | rm_work, nah | 19:05 |
jamielennox | ayoung: https://review.openstack.org/#/c/118520/ had a conflict and needs to be sent off again, if you put the +2 back i can +A when check finishes | 19:05 |
ayoung | rm_work, how about this | 19:05 |
rm_work | ayoung: no, seriously, it needs that | 19:05 |
ayoung | user_id == service_user, trustor_id == key_owner | 19:05 |
rm_work | the "register as a consumer" is not a user operation, it's a management operation | 19:05 |
rm_work | users can't do it | 19:05 |
ayoung | rm_work, that is OK...you can say "this *must* be done with a trust token only | 19:05 |
ayoung | and use a policy AND rule for it | 19:06 |
rm_work | ah, hmm... ok | 19:06 |
rm_work | do you know what the repose rule looks like for that? | 19:06 |
rm_work | err, RBAC | 19:06 |
*** aix has quit IRC | 19:06 | |
ayoung | morganfainberg, btw ^^ is a more elegant solution to your "Composite tokens" BP | 19:06 |
ayoung | rm_work, mumble mumble uh yeah | 19:06 |
rm_work | https://github.com/openstack/barbican/blob/master/etc/barbican/policy.json#L16 | 19:07 |
ayoung | rm_work, OK, so lets start with the policy code from Oslo... | 19:07 |
rm_work | right now it's not especially accurate to what we want, I am afraid -- " | 19:07 |
ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/policy.py | 19:07 |
rm_work | I am not sure that "rule: admin" is actually correct | 19:07 |
ayoung | Nah, not right now....hold on | 19:07 |
nkinder | ayoung, jamielennox, morganfainberg: can we continue the kerberos plugin discussion here? | 19:08 |
ayoung | rm_work, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/policy.py#n412 | 19:08 |
ayoung | nkinder, looks like it is going to get kicked to a separate repo | 19:08 |
jamielennox | nkinder: sure, so i don't think it is a good idea for ksc to have a dependency on pykerberos, | 19:08 |
nkinder | if a new repo is needed, we would just create it under the keystone/identity program, right? | 19:09 |
ayoung | nkinder, yes | 19:09 |
nkinder | jamielennox: sure, understood | 19:09 |
jamielennox | nkinder: it's a C plugin and people will get pissy | 19:09 |
ayoung | nkinder, and a second one for the Fedearted auth plugin | 19:09 |
nkinder | ok, so let's just get a repo creation filed against infra | 19:09 |
morganfainberg | nkinder, we will need to talk to the TC but that could be where it lands, it might need to go stackforge initially. | 19:09 |
ayoung | so at least 2 new repos | 19:09 |
nkinder | ayoung: ++ | 19:09 |
rm_work | ok, so we'd do "consumers:post": "containers:get and is_using_trust" or something like that? | 19:09 |
ayoung | rm_work, let me parse that... | 19:09 |
nkinder | morganfainberg: it shouldn't need to be stackforge, as it's considered within the identity program, right? | 19:09 |
jamielennox | ayoung: i'll file those | 19:09 |
ayoung | rm_work, yeah, although if you put in | 19:10 |
morganfainberg | nkinder, right, we'll just likely need a governance change to get it attributed to our program | 19:10 |
rm_work | for reference, "consumer POST" == "container GET" + "admin operation in DB" | 19:10 |
jamielennox | (unless you've got a start somewhere) | 19:10 |
ayoung | trustor_id == key.user_id | 19:10 |
morganfainberg | nkinder, it's not a hard sell, but as a backup, we can stackforge it | 19:10 |
nkinder | morganfainberg: ++ | 19:10 |
ayoung | it implis that a trust is in use | 19:10 |
rm_work | ok | 19:10 |
rm_work | so | 19:10 |
jamielennox | morganfainberg: ask on -infra | 19:10 |
ayoung | rm_work, let me show you a rule from keystone | 19:10 |
nkinder | morganfainberg: the repo request puts it under the program IIRC | 19:11 |
rm_work | ok, I am not an expert at policy rules :P | 19:11 |
morganfainberg | nkinder, there is a yaml change that is also needed | 19:11 |
rm_work | in fact I know almost nothing about policy.json, i just kinda copied what other things were doing | 19:11 |
nkinder | morganfainberg: yes, exactly | 19:11 |
morganfainberg | nkinder, in the governance repo, | 19:11 |
ayoung | rm_work, so for creating a trust, we can check the data coming in http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n108 | 19:11 |
ayoung | to get a trust... | 19:11 |
nkinder | morganfainberg: ah, I know what you're referring to | 19:11 |
morganfainberg | it shouldn't be a big deal | 19:12 |
ayoung | rm_work, hmmm http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n109 | 19:12 |
nkinder | morganfainberg: yeah | 19:12 |
morganfainberg | but *worst* case if there is balking at it, we go stackforge | 19:12 |
ayoung | we used to have something more interesting than that | 19:12 |
nkinder | ayoung: barbican doesn't support much via policy AFAIK | 19:12 |
ayoung | rm_work, http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n7 | 19:12 |
nkinder | ayoung: access to secrets is tied to the user ID in the token I believe | 19:12 |
nkinder | ayoung: there it no more flexibility than that | 19:13 |
ayoung | nkinder, so we have code in keystone you are going to want to grab that fetches an object from the database before enforcing policy | 19:13 |
ayoung | admin_or_owner does that | 19:13 |
ayoung | "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or rule:owner", | 19:13 |
morganfainberg | nkinder, ayoung, what is the timeline of getting the new repo spun up, it's not hard to do, just need to plan it. also are we starting from scratch or do we have a repo to base from? in the latter case need to import the code on new repo request | 19:13 |
ayoung | morganfainberg, we have a commit in the keystoneclient gerrit that is the basis... | 19:13 |
nkinder | morganfainberg: ASAP to be honest. I really am trying to get kerberos to be usable against Juno | 19:14 |
morganfainberg | ayoung, ok, so ideally if that is split into a github repo we can use it as a basis for the new repo | 19:14 |
*** dmsimard has joined #openstack-keystone | 19:14 | |
nkinder | morganfainberg: but we don't have a working repo to base it off of | 19:14 |
ayoung | morganfainberg, I can do that | 19:14 |
rm_work | ok, so maybe I am not clear on what the "impersonation" part of the "trust with impersonation" does | 19:14 |
morganfainberg | ayoung, :) | 19:14 |
ayoung | nkinder, I can get one to work | 19:14 |
dmsimard | Hi guys. Bare with me here, trying to find the deprecation notes about XML for Keystone. Is there a blueprint or a specific review for it ? | 19:14 |
rm_work | the "trust token" gives you the domain:role combo from the user that you set up the trust with | 19:14 |
rm_work | right? | 19:14 |
ayoung | nkinder, oooh...so this second repo doesn't need to be gating on python33 to start | 19:15 |
nkinder | ayoung: true... | 19:15 |
rm_work | and I thought the Impersonation part is what added our service-account's roles to the token as well | 19:15 |
morganfainberg | ayoung, i'm happy to put the reviews up for governance and for infra if you want. if not i'm happy to review the changes | 19:15 |
ayoung | dmsimard, what are we Baring? Our Souls? | 19:15 |
morganfainberg | ayoung, py34* | 19:15 |
nkinder | ayoung: you define the jobs when we set up the repo | 19:15 |
ayoung | morganfainberg, the python-kerberos stuff right now works Pythion27 only | 19:15 |
ayoung | we are working on the 33 support, but this would take the pressure off | 19:15 |
dmsimard | ayoung: s/bare/bear :) | 19:16 |
morganfainberg | ayoung, i'll make the py34 (33 is going away) an expirimental test | 19:16 |
ayoung | dmsimard, and hear you got me all ready to confess | 19:16 |
nkinder | morganfainberg: ++ | 19:16 |
ayoung | morganfainberg, ++ | 19:16 |
morganfainberg | ayoung, means you just need to issue an expirmental comment in the review and it'll run that check. | 19:16 |
ayoung | morganfainberg, OK...I can do that. | 19:16 |
dmsimard | ayoung: So does that mean you know when XML was deprecated/thrown out the window/killed in a fire? :D | 19:17 |
morganfainberg | there shall be no bareing of anything in this channel today :P | 19:17 |
nkinder | repos are only created on Friday IIRC, so we should get the request filed and reviewed | 19:17 |
ayoung | dmsimard, its been a while since we borked XML IIRC | 19:17 |
ayoung | dmsimard, it has to do with how we marshall | 19:17 |
morganfainberg | jamielennox, saw the convo. makes it easier | 19:17 |
ayoung | I know that trusts was broken with XML fairly early on | 19:17 |
dmsimard | ayoung: Trying to reference when the support for XML would've been removed, this third party company has no clue what they're talking about and want to prove them wrong :) | 19:18 |
dmsimard | I think the last setup they worked against was Folsom or something | 19:19 |
ayoung | dmsimard, it was never removed, and there are still a slew of tests that check it, but I think there are some APIs that have never been tested against XML | 19:19 |
ayoung | morganfainberg, OK, the removal of the Py3* requirement makes my life significantly easier. I'm all with the new repo thing now. | 19:20 |
dmsimard | They're sending a POST to /tokens with an "Accept: application/xml" and they're getting a JSON reply back. They are expecting an XML response. | 19:21 |
dolphm | morganfainberg: dstanek: RC1 or kilo? https://review.openstack.org/#/c/113586/ | 19:21 |
dmsimard | v2.0/tokens * | 19:21 |
morganfainberg | dolphm, i'm fine with that going into K | 19:21 |
ayoung | rm_work, OK, the trust policy enforcement code has changed since I last looked at it. It is more restrictive than it used to be. But there is a decorator we have that says "fetch the object from the repo first, then apply policy" | 19:21 |
dolphm | morganfainberg: any reason to block it for rc1? | 19:21 |
rm_work | hmm | 19:21 |
morganfainberg | dolphm, it's mostly just a "oh this is a bit better than we have now and should prevent the same bug from being re-opened" | 19:21 |
* ayoung assumes it is still in the code | 19:21 | |
morganfainberg | dolphm, if it's good to go in, there shouldn't be a reason to prevent it from RC | 19:22 |
dolphm | morganfainberg: k | 19:22 |
morganfainberg | dolphm, it's low on the priority list though, so if we punt that for some other code, it's a good tradeoff | 19:22 |
dstanek | dolphm: morganfainberg: i agree | 19:22 |
ayoung | rm_work, I think it is http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/controller.py#n161 | 19:22 |
morganfainberg | s/other code/other review cycles | 19:22 |
rm_work | ayoung: ok, I am not positive how to translate from "functions in keystone code" to "what does the line in policy.json look like" yet :P | 19:23 |
bknudson | maybe somebody knows this already ... in multi-backends, I assume the assignment table should always have the public ID? | 19:23 |
bjornar_ | someone asked me earlier to try out master (I was looking at keystone api through tcpdump, 68 queries in total to get a token) ... Now I have tried out master... and its about 5 times slower... | 19:23 |
ayoung | rm_work, yeah, the code bases are very different. We have a specific "fetch the thing from the driver" approach that we can generalize on | 19:23 |
ayoung | rm_work, here it is http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/controller.py#n118 | 19:24 |
ayoung | rm_work, and that is specific to the controller....so in the case of the trusts_controller it looks like this: | 19:24 |
morganfainberg | bjornar_, there is a lot of optimisations we can do, it is absolutely on the long list of things we need to be working on | 19:25 |
ayoung | I lied | 19:25 |
ayoung | I think this code has been removed | 19:25 |
morganfainberg | bjornar_, part of the issue is we have subsystems that you can't make unified queries to, so you need to lookup domain in some cases, and then project, and user (separate couldn't be lumped together) | 19:25 |
rm_work | ayoung: ok... i am still very lost though :) | 19:26 |
morganfainberg | bjornar_, some of this is a hassle of using an ORM, and the extra work required to clean up that usage and make it better | 19:26 |
ayoung | rm_work, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/assignment/controllers.py#n355 | 19:26 |
rm_work | I haven't ever looked at the keystone code before, I was hoping digging into the code wouldn't be required to figure out a policy rule :) | 19:26 |
rm_work | I *can* dig into keystone code, but it will take me a bit to get up to speed, obviously | 19:27 |
ayoung | rm_work, nah, forget about the specifics...hear me now and believe me later but understand me next week | 19:27 |
bjornar_ | I used to see ~200ms "token-time", now its 1200ms and more... | 19:27 |
morganfainberg | bjornar_, what configuration | 19:27 |
rm_work | alright... | 19:27 |
bjornar_ | morganfainberg, mysql, no caches | 19:27 |
ayoung | rm_work, ok...lets start with your diagram | 19:27 |
morganfainberg | bjornar_, how many tokens in your token table? | 19:27 |
morganfainberg | bjornar_, that can actually cause significant slowdowns. | 19:28 |
morganfainberg | bjornar_, also, deployed under eventlet or apache | 19:28 |
ayoung | rm_work, I would say that the first change is this: | 19:28 |
morganfainberg | bjornar_, and UUID tokens or PKI? | 19:28 |
bjornar_ | | 53602 | | 19:28 |
ayoung | user must generate a key and a trust and send them both to Barbican | 19:28 |
bjornar_ | PKI | 19:28 |
morganfainberg | eh, 53k isn't bad overall as long as mysql has enough ram. | 19:29 |
ayoung | rm_work, the token that the user sends to barbican should not have the ability to create a trust on it, but that is a different story | 19:29 |
rm_work | ayoung: alright, i think that is a different argument from what we're talking about | 19:29 |
bjornar_ | no performance problems with mysql | 19:29 |
ayoung | lets assume that the user has removed that ability from their token | 19:29 |
rm_work | at least, what we were talking about right now? | 19:29 |
ayoung | and instead, they create the trust. Then Barbican executes the trust | 19:29 |
rm_work | *LBaaS executes the trust | 19:29 |
morganfainberg | bjornar_, is this under eventlet or apache and if under eventlet do you have a lot of queries going to keystone or is it just a token request? | 19:29 |
morganfainberg | bjornar_, actually even under apache, is keystone under load? | 19:30 |
ayoung | so, Barbican tells the user "here is the trust you need to create and give to me in order to store your key" | 19:30 |
ayoung | basically, delegate to the Barbican service user the "create_key" role | 19:30 |
rm_work | errr, again, s/Barbican/LBaaS/ right? | 19:30 |
ayoung | its all Greek to me | 19:30 |
bjornar_ | no load, nothing | 19:30 |
rm_work | Barbican in our example is "the other service" | 19:30 |
rm_work | we are LBaaS | 19:31 |
ayoung | LeBarbican as a Service.... | 19:31 |
rm_work | lol | 19:31 |
rm_work | well, it matters for the diagram :P | 19:31 |
bjornar_ | morganfainberg, this was the only query to keystone at the time. | 19:31 |
ayoung | EEEt eees fro the Parieee Summit, Non? | 19:31 |
morganfainberg | bjornar_, ok | 19:31 |
bjornar_ | morganfainberg, and query is from curl, so I have control | 19:31 |
rm_work | heh | 19:31 |
morganfainberg | bjornar_, well if you had a ton of requests going in and added one more i'm not surprised. | 19:31 |
rm_work | this is actually going to hit the mailing-list ASAP | 19:31 |
rm_work | might end up being a brown-bag at Paris but that's not the main purpose | 19:32 |
rm_work | this is going to drive the code we write in the next few weeks | 19:32 |
*** dmsimard has left #openstack-keystone | 19:32 | |
rm_work | we're at the "actually implement this interaction" stage | 19:32 |
ayoung | rm_work, what is the Key being used for in this use case? Access to an encrypted volume? | 19:33 |
bjornar_ | morganfainberg, no, its dev | 19:33 |
morganfainberg | bjornar_, if you don't mind, can you switch your keystone to use UUID tokens and tell me if it's any faster. 1200ms seems awfully slow. | 19:33 |
rm_work | ayoung: Cert/Key is for TLS Termination on a Load Balancer | 19:33 |
bjornar_ | seems 1200 ms is for special cases, probably during warmup when I dont have connections established.. | 19:33 |
morganfainberg | bjornar_, i've been running a number of things for testing recently and can't remember things taking that long even with tight-loop token issuance | 19:33 |
bjornar_ | morganfainberg, but I keep seeing the ~200ms times, which is _way_ to slow | 19:33 |
ayoung | rm_work, why "save trust id for later" in your diagram? | 19:34 |
rm_work | ayoung: there's actually two scenarios, this diagram is the initial one | 19:34 |
ayoung | what is "later" here? | 19:34 |
morganfainberg | bjornar_, ~200ms is slow, but that is something i can reasonably say we should focus on fixing in K (sorry it's a bit late in J to really get sweeping changes in) | 19:34 |
rm_work | the additional scenario is no user interaction -- we need to migrate their load balancer to a different host later because of a failure event or something, we will need to retrieve their cert/key again at some random time without their interaction | 19:34 |
morganfainberg | bjornar_, under apache (if you're using mod_Wsgi deployment) the first few requests can take a lot longer because mod_Wsgi needs to spin up the child process | 19:35 |
bjornar_ | morganfainberg, I can understand it: Atleast 2 queries are run 4 times just to get the token, and between every "real" query, it is run: rollback .. commit .. select 1 | 19:35 |
morganfainberg | bjornar_, the trade off of the slowness for the spinup initially is fine based on the overall benefit of running under apache | 19:35 |
rm_work | the scenario in this diagram is the "initial load balancer setup | 19:35 |
rm_work | " | 19:35 |
morganfainberg | bjornar_, the select 1 is a keepalive thing in oslo.db i think | 19:35 |
bjornar_ | so I counted a total of 68 (I think) sql queries to generate a token | 19:35 |
morganfainberg | bjornar_, so lets ignore that one, we may not have any control on that front directly in keystone | 19:36 |
bjornar_ | morganfainberg, I guess... but does it need to keep it alive every ms? | 19:36 |
nkinder | morganfainberg, jamielennox: I missed the infra discussion. Is the plan to go ahead with new repos for kerberos and federation, and that py3* is not going to be a gating job? | 19:36 |
bjornar_ | morganfainberg, if you scroll back some 4-5 hours, you find a pastie.org link | 19:36 |
morganfainberg | nkinder, correct. | 19:36 |
nkinder | morganfainberg: awesome | 19:37 |
morganfainberg | nkinder, it'll be expirimental | 19:37 |
nkinder | jamielennox: are you going to file the repo/governance requests? | 19:37 |
morganfainberg | nkinder, i'll get to work on this once ayoung has the repo on github split up. | 19:37 |
jamielennox | nkinder: i think morganfainberg and i both offered | 19:37 |
morganfainberg | nkinder, unless jamielennox wants to do it | 19:37 |
nkinder | morganfainberg: ah, cool. Much appreciated! | 19:37 |
morganfainberg | :) | 19:37 |
morganfainberg | perfectly happy to let him fight with the config repo to get the data in. | 19:38 |
morganfainberg | erm s/data/repo | 19:38 |
morganfainberg | :P | 19:38 |
jamielennox | morganfainberg: i have an infra review that is weeks old and not passing, if it doesn't happen this week i'll still need you to shepherd it | 19:38 |
morganfainberg | ok | 19:39 |
morganfainberg | bjornar_, yep see it, that looks *about* right | 19:39 |
*** david-lyle has joined #openstack-keystone | 19:40 | |
*** openstackgerrit has joined #openstack-keystone | 19:40 | |
morganfainberg | bjornar_, looking at the paste | 19:40 |
morganfainberg | bjornar_, we can *probably* lighten some of that up. i had a patch that aimed to do a lighter weight select when just checking existence of an object in SQL. i'll see about resurrecting it | 19:41 |
morganfainberg | may not reduce the queries but may reduce the object housekeeping in-code overhead within SQLA | 19:41 |
jamielennox | ayoung: do you want to commit the existing kerberos plugin to a new repo (bypass review) or should i submit something empty. | 19:42 |
*** csd has quit IRC | 19:42 | |
ayoung | how about empty | 19:42 |
ayoung | and then we'll do the kerb plugin as the first review still | 19:42 |
ayoung | test the workflow | 19:42 |
rm_work | ayoung: did I answer your question? you disappeared for a minute there :P | 19:43 |
*** csd has joined #openstack-keystone | 19:44 | |
bjornar_ | morganfainberg, here are the timings and complete flow: http://pastebin.com/raw.php?i=ZQMGAK03 | 19:44 |
*** alee has joined #openstack-keystone | 19:45 | |
bjornar_ | morganfainberg, search for "Statement" and jump through the file.. | 19:46 |
dolphm | lbragstad: ttx also suggested we use a juno-rc-potential tag for bugs that are non-blocking nice-to-haves worth tracking. i've moved a couple of the Low bugs from RC1 to that | 19:46 |
lbragstad | dolphm: cool, good deal | 19:46 |
bjornar_ | morganfainberg, first of all, why do you rollback and commit selects ? | 19:46 |
morganfainberg | bjornar_, side effect of the session object. | 19:47 |
morganfainberg | bjornar_, a lot of things are done in transactions in a weird way | 19:47 |
rm_work | ayoung: anyway, if we wanted to make the user do the Trust setup and just pass us the TrustID, we'd need to have them delegate "container:get", "secret:decrypt", and "secret:get", and in "consumers:post" we'd actually just rely on it being a trust? | 19:47 |
morganfainberg | bjornar_, it's something we can work on cleaning up next cycle | 19:47 |
rm_work | I'm not sure if relying on "this is a trust" works because they could just set up a trust to some other non-service-admin account, and then would be able to mess with consumers, which we don't want | 19:48 |
dolphm | lbragstad: these failures look legit btw https://review.openstack.org/#/c/119843/ | 19:48 |
bjornar_ | I hope so, because as it is now, its not something you want to show people ;) | 19:48 |
ayoung | rm_work, you can also enforce based on trustess_user_id | 19:48 |
ayoung | so a trust works fine there | 19:48 |
rm_work | ok so | 19:48 |
rm_work | what would the actual line in policy.json look like then? | 19:48 |
lbragstad | dolphm: saw those, I'll work on respinning | 19:49 |
morganfainberg | bjornar_, out of curiosity, in uuid tokens how fast is the token issuance compared to pki? still ~200ms? | 19:49 |
rm_work | ayoung: right now it is: "consumers:post": "rule:admin" | 19:49 |
*** vhoward has left #openstack-keystone | 19:49 | |
morganfainberg | bjornar_, i'm wondering how much overhead the popen adds. | 19:49 |
bjornar_ | morganfainberg, also, I am wondering about status of: 1) /usr/bin/openssl -> pythonlibssl 2) pki tokens not stored | 19:49 |
ayoung | rm_work, and rule:admin is what? | 19:49 |
morganfainberg | bjornar_, popen->sopenssl | 19:49 |
bjornar_ | morganfainberg, its about 10ms | 19:49 |
ayoung | that the user has the admin role? | 19:49 |
morganfainberg | bjornar_, ok good to know | 19:49 |
bjornar_ | but should for sure get rid of it | 19:49 |
rm_work | but it'd need to be something like: "consumers:post": "rule:container:get and <something about trustee", | 19:49 |
bjornar_ | because its the 10ms it should answer in :) | 19:50 |
ayoung | hmmmmm that is not going to work. The token will not have the trustees role in it | 19:50 |
dstanek | morganfainberg: bjornar_: but does popen introduce any sort of blocking behavior? | 19:50 |
morganfainberg | bjornar_, well that is a different issue, i wont say we can or can't get rid of the popen | 19:50 |
rm_work | ayoung: at the moment yes, but ignore that because i'm 99% sure it's wrong | 19:50 |
morganfainberg | dstanek, it does. | 19:50 |
ayoung | on the delegated roles from the trustor | 19:50 |
morganfainberg | dstanek, or can. | 19:50 |
rm_work | ok, so err | 19:50 |
bjornar_ | also, I have experienced hung openssl procs | 19:50 |
morganfainberg | dstanek, depends on a lot of things. | 19:50 |
ayoung | rm_work, you could always require two tokens | 19:50 |
ayoung | one for the trust and one from the service user itself | 19:50 |
rm_work | err | 19:50 |
ayoung | rm_work, there have been requests for that kind of thing | 19:51 |
ayoung | but...Ug Lee | 19:51 |
rm_work | I thought that was the purpose of the Impersonation | 19:51 |
bjornar_ | In fact I have implemented more or less this exact thing using lua and libssl (with mysql backend) .. it manages 20k qps | 19:51 |
ayoung | rm_work, no...impersonation is not going to help either way here | 19:51 |
ayoung | but impersonation is always wrong | 19:51 |
bjornar_ | so I find it amazing that a huge group of people, and amazing people, manage to put this shit together | 19:52 |
bjornar_ | ;) | 19:52 |
morganfainberg | ok i need to go get food. | 19:52 |
ayoung | rm_work, the two token solution is possible. They would go in separate headers. THere was some discussion about composite tokens at the last summit, but not sure the status of that req | 19:53 |
ayoung | rm_work, so an end user can't do this themselves, it must be the combination of end user and service user? | 19:53 |
morganfainberg | it's long past lunch | 19:54 |
bjornar_ | Will there be any keystone performance spesific meetings in paris? | 19:56 |
morganfainberg | bjornar_, nothing is specifically slated for paris yet | 19:56 |
morganfainberg | bjornar_, i expect to see some conversations on it at the very least | 19:56 |
morganfainberg | even if it's not in a specific dev session | 19:56 |
bjornar_ | would like to eventually join that conversations.. | 19:56 |
dolphm | topol: i'm getting notifications anytime you add a reviewer to anything | 19:57 |
rm_work | ayoung: yes | 19:57 |
rm_work | ayoung: end user can't do it on their own containers, and we can't read their containers on our own | 19:57 |
rm_work | ayoung: in the end, it is a combination sort of issue | 19:57 |
morganfainberg | bjornar_, well look for us at the summit! i'm sure we'll discuss it there | 19:57 |
rm_work | ayoung: and I don't know if we can wait on some new keystone feature to be released in Kilo, we need to figure out a way to get this working with keystone v2 <_< | 19:58 |
ayoung | rm_work, that was the composite token use case, and ...lets see | 19:58 |
ayoung | rm_work, two tokens | 19:58 |
bjornar_ | I mean.. its a keystone service.. | 19:58 |
topol | dolphm??? | 19:58 |
bjornar_ | it should behave | 19:58 |
ayoung | one for the admin user, one as a trust token for the end user | 19:58 |
topol | I did what now? | 19:58 |
dolphm | topol: added reviewers to your audit patch | 19:58 |
ayoung | rm_work, that is a requirement, I think, no matter who creates the trust. The trust token will only have roles for the end user, not the admin | 19:59 |
topol | dolphm, is that normal or sometin special? | 20:00 |
dolphm | topol: new to me and i'm now realizing annoying :) | 20:00 |
dolphm | topol: especially when you add 8 reviewers at once and i get 8 notifications | 20:00 |
*** joesavak has joined #openstack-keystone | 20:00 | |
topol | dolphm, I dont think I did anything to cause this. And I did not personally add reviewers | 20:01 |
dolphm | topol: oh, well someone did. i assumed it was you since it was your patch | 20:01 |
topol | did stevemar do this perhaps | 20:01 |
*** jsavak has joined #openstack-keystone | 20:01 | |
topol | doplhm, stevemar, can someone please get this bus off me? | 20:02 |
rm_work | ayoung: right, but isn't that what the Impersonation piece does? adds the roles from the service-user? | 20:02 |
ayoung | rm_work, nope | 20:02 |
topol | dolphm ^ | 20:02 |
jamielennox | dolphm: need to set the email filters to get rid of that | 20:02 |
stevemar | oh that was definitely me | 20:02 |
rm_work | hmm | 20:02 |
dolphm | stevemar: thanks. | 20:02 |
topol | :-) | 20:02 |
ayoung | rm_work, impersonation would just set the user_id on the token to the end user, not the service user | 20:02 |
stevemar | dolphm, happy to help | 20:02 |
*** alee has quit IRC | 20:03 | |
*** dolphm changes topic to "Review RC1 blockers plzkthx https://gist.github.com/dolph/651c6a1748f69637abd0" | 20:03 | |
stevemar | jokes aside, i thought that adding 'keystone-core' to a patch was OK? | 20:03 |
dolphm | stevemar: it is | 20:03 |
stevemar | dolphm, then what was wrong? | 20:03 |
dolphm | stevemar: just don't all cla-signers | 20:03 |
dolphm | add* | 20:03 |
dolphm | stevemar: i just got a stream of notifications for each user that was added | 20:04 |
jamielennox | morganfainberg: is it worth setting up ksc-federation at the same time or just do -kerberos for now? | 20:04 |
stevemar | huh? | 20:04 |
stevemar | oh | 20:04 |
morganfainberg | jamielennox, lets not do federation at the same time, we want to preserve history and that is a lot more work | 20:04 |
dolphm | stevemar: https://review.openstack.org/#/admin/groups/324,members | 20:04 |
bknudson | I'm looking at everything in keystone that I can already so no need to add me. | 20:05 |
morganfainberg | jamielennox, if we didn't care about history, i'd day easy to split it. | 20:05 |
*** joesavak has quit IRC | 20:05 | |
* topol dolphm your apology is accepted :-) | 20:05 | |
dolphm | topol: your welcome | 20:05 |
topol | :-) | 20:05 |
stevemar | bknudson, so you're saying you are operating at 100% capacity? | 20:06 |
bknudson | I give 110%. | 20:06 |
stevemar | time to upgrade your processor(s) | 20:06 |
bknudson | so 100% of 110%. | 20:07 |
* lbragstad has dibs on bknudson's old processor | 20:07 | |
dolphm | EVERYONE open this review and click on the Closes-Bug https://review.openstack.org/#/c/120043/ thank you | 20:09 |
morganfainberg | dolphm, LOLOLOLOL | 20:09 |
gyee | looks like https://review.openstack.org/#/c/58372/ is a dupe of mine https://review.openstack.org/#/c/117658/ | 20:09 |
bknudson | too much whitespace to catch the fish | 20:11 |
gyee | since https://review.openstack.org/#/c/117658/ is much further along, I'd say abandon the other one | 20:11 |
stevemar | lol | 20:11 |
dolphm | gyee: clean up the bugs first | 20:11 |
gyee | dolphm, let me link that bug too | 20:11 |
stevemar | good ol fishing bugs | 20:12 |
dolphm | gyee: there's 3 different bug reports there. if your patch fixes the third bug, or if the third bug is a dupe of one of the others - that needs to be cleaned up first | 20:12 |
bknudson | dolphm: I hope that's targeted to rc1... need to catch fish | 20:12 |
topol | dolphm, Bug #1348263 I dont get it. whats the joke? | 20:13 |
uvirtbot | Launchpad bug 1348263 in toontowninfinite "Lag is affecting fishing. BADLY" [Undecided,New] https://launchpad.net/bugs/1348263 | 20:13 |
stevemar | i kinda want to subscribe to that bug | 20:13 |
stevemar | topol, click it | 20:13 |
topol | I did its some poem about fishing | 20:13 |
dolphm | stevemar: you should be like "we have a fix for this here..." | 20:14 |
stevemar | dolphm, haha | 20:14 |
gyee | dolphm, https://bugs.launchpad.net/keystone/+bug/1254849 is a dupe of https://bugs.launchpad.net/keystone/+bug/1361306 | 20:14 |
uvirtbot | Launchpad bug 1254849 in keystone "Wrong LDAP attribute used in user response bodies" [Medium,In progress] | 20:14 |
dolphm | stevemar: maybe they can cherry pick it? | 20:14 |
morganfainberg | dolphm, too bad the launchpad bot is too smart to stick the "patch proposed to master" on that bug >.> | 20:14 |
* topol so lost... why is this funny. | 20:15 | |
dolphm | gyee: are you marking them as such? | 20:15 |
gyee | they are essentially describing the same problem, one is more AD centric and the other is more generic | 20:15 |
dolphm | topol: we finally fixed the fishing lag, duh | 20:15 |
gyee | dolphm, doing it now | 20:15 |
dolphm | gyee: thanks | 20:15 |
stevemar | topol, the author referenced the wrong bug, the bug he referenced is a bug in a game called 'toon town infinite' apparently | 20:15 |
dolphm | gyee: that's one more off the RC list :) | 20:15 |
gyee | dolphm, :) | 20:15 |
bknudson | I always blame the lag when I can't catch fish | 20:15 |
topol | god Im old | 20:15 |
ayoung | topol, I'm Young, but we are the same Age. | 20:16 |
morganfainberg | ayoung, no you're A Young. | 20:16 |
* morganfainberg sees himself out | 20:16 | |
ayoung | morganfainberg, what happend with composite tokens? | 20:16 |
dolphm | bknudson: https://www.youtube.com/watch?v=_fNp37zFn9Q | 20:16 |
dolphm | living with lag IRL ^ | 20:16 |
morganfainberg | ayoung, it's pending it's a middleware bp | 20:16 |
stevemar | dolphm, thats great! | 20:17 |
morganfainberg | ayoung, https://review.openstack.org/#/c/108384/ | 20:17 |
samuelmz | dolphm, are bug fixes and refactoring being blocked until we open for Kilo development? | 20:18 |
dolphm | samuelmz: refactoring is mostly being blocked, yes | 20:18 |
samuelmz | dolphm, or we're blocking only patches that introduce new features? | 20:18 |
samuelmz | dolphm, ok | 20:18 |
dolphm | samuelmz: list of blocked patches is at the bottom here https://gist.github.com/dolph/bddbb047f06431f535c6 | 20:18 |
*** dims_ has quit IRC | 20:18 | |
dolphm | samuelmz: anything deemed "risky" for stability is held until kilo | 20:19 |
*** dims_ has joined #openstack-keystone | 20:19 | |
samuelmz | dolphm, thanks | 20:19 |
dolphm | samuelmz: so yeah, new features, non-trivial refactors, even complex bug fixes that aren't high priority | 20:19 |
gyee | dolphm, stupid question, how do I close the bug as duplicate? | 20:20 |
stevemar | gyee, you just mark it | 20:20 |
samuelmz | dolphm, fair enough, I was asking beacause I have a refactoring blocked (https://review.openstack.org/#/c/116682/) | 20:20 |
dolphm | gyee: Ctrl+F "Mark as Duplicate" | 20:20 |
stevemar | yep | 20:20 |
*** topol has quit IRC | 20:20 | |
stevemar | dolphm, what was the outcome of the 'add id's to endpoints' bug? | 20:20 |
dolphm | samuelmz: yeah, that fell into my non-trivial refactor bucket :-/ looks super intriguing though! | 20:21 |
dolphm | stevemar: ignoring for juno | 20:21 |
gyee | stevemar, secrete to secret? :) | 20:22 |
stevemar | gyee, i guess so, someone wanted that in | 20:23 |
gyee | My international version of MS Office said secrete is correct | 20:23 |
dolphm | gyee: -1! | 20:23 |
gyee | haha | 20:23 |
dolphm | gyee: secrete is a word, it's just not the one people assume it is | 20:23 |
stevemar | secrete is a word | 20:23 |
gyee | lmao | 20:23 |
*** dims_ has quit IRC | 20:23 | |
stevemar | i thought it was supposed to be funny, like your password is secreting | 20:23 |
dolphm | we do it for security, secret is too easy to guess | 20:23 |
bjornar_ | gyee, the most frightening is that you are in possession of MS Office | 20:24 |
dolphm | bjornar_: ++ | 20:24 |
samuelmz | dolphm, we depend on this patch (currently on master branch) to efficiently implement list role assignments in the context of hierarchical projects (feature/hierarchical-multitenancy branch) | 20:24 |
rm_work | ayoung: sorry, got pulled away for a few | 20:24 |
samuelmz | dolphm, so we have 2 options : 1) put this patch on feature/hierarchical-multitenancy branch | 20:24 |
dolphm | samuelmz: that should land in both branches then -- master in kilo and feature/hierarchical-multitenancy | 20:24 |
rm_work | ayoung: so, I am trying to chart out exactly what the trust does versus what impersonation does | 20:24 |
gyee | bjornar_, I only use it on Wednesdays | 20:25 |
samuelmz | dolphm, yes .. :-) | 20:25 |
*** mikedillion has quit IRC | 20:25 | |
samuelmz | dolphm, thanks | 20:25 |
ayoung | rm_work, impersonation is a factor of a trust that says "change the user_id on the token to be the truess Id" that is all | 20:25 |
ayoung | and don't do it | 20:25 |
ayoung | just forget that it exists | 20:25 |
rm_work | ok, so it does nothing whatsoever with roles? | 20:25 |
ayoung | its only there for a Swift use case that doesn't even really need it anymore | 20:26 |
dolphm | rm_work: correct | 20:26 |
rm_work | my original understanding was that it did THAT, but also combined the roles of the two accounts in some way | 20:26 |
ayoung | no effect on roles | 20:26 |
ayoung | nope | 20:26 |
rm_work | hmm ok | 20:26 |
ayoung | rm_work, 2 tokens | 20:26 |
rm_work | so that's "proposed functionality" or existing? | 20:26 |
ayoung | two tokens? Its what I am proposint you do | 20:26 |
ayoung | the composite token idea has not been implemented yet | 20:27 |
ayoung | and I don't know that you really need it | 20:27 |
bjornar_ | what is it for? | 20:27 |
bjornar_ | added complexity only=? | 20:27 |
bjornar_ | ;) | 20:27 |
ayoung | you send X-Auth-Token with the users trust token, and X-Subject-Token with the service users token | 20:27 |
gyee | ayoung, https://review.openstack.org/#/c/108384/ | 20:27 |
bjornar_ | heat stuff? | 20:28 |
ayoung | rm_work, see https://review.openstack.org/#/c/108384/ | 20:28 |
gyee | bjornar_, you mean what composite tokens are for? | 20:28 |
bjornar_ | gyee, no, MS Office | 20:28 |
gyee | use case is specified in the spec | 20:28 |
gyee | haha | 20:28 |
rm_work | ayoung: ok, and RBAC middleware supports dealing with this already? | 20:29 |
*** stevelle_ has joined #openstack-keystone | 20:29 | |
ayoung | MS office is used for obfuscating documents and tying you to a vicious upgrade cycle of planned obsolesce and vendor lock in | 20:29 |
ayoung | rm_work, it will once that one is approved/ Let me look at it now | 20:29 |
ayoung | its a +609 line change so ... | 20:29 |
ayoung | will take a bit to review | 20:30 |
ayoung | mostly it is documentation and tests, though | 20:30 |
rm_work | ayoung: this review is the COMPOSITE token thing, which is different from two token thing? or that is the two token thing | 20:30 |
ayoung | rm_work, two tokens replaced composite, it looks like | 20:30 |
bjornar_ | Where is the document (is there any), describing the difference between the main and admin proc, and does it need to be a admin proc? | 20:31 |
*** henrynash has joined #openstack-keystone | 20:31 | |
ayoung | rm_work, I'd forgotten that we had agreed to that | 20:31 |
rm_work | ayoung: ok, so, even if this is approved, it won't be in until Kilo, right? since we have passed the feature freeze date? | 20:31 |
ayoung | it will be in Juno | 20:31 |
ayoung | its in the middleware code, that has a diffferent release cycle | 20:32 |
gyee | its a middleware thingy so different release cycle | 20:32 |
rm_work | ayoung: ah, ok | 20:32 |
rm_work | but, to use it, people need to be running keystone v3? | 20:32 |
rm_work | or again, not related | 20:32 |
rm_work | ah, not related i guess | 20:32 |
ayoung | rm_work, there is no Keystone V3 | 20:32 |
rm_work | err | 20:33 |
ayoung | There is V3 of the identity API, but that is supported by Keystone now | 20:33 |
rm_work | ok | 20:33 |
dstanek | dhellmann: i just put up a patch to show a possible solution | 20:33 |
rm_work | so Identity-v2 vs. Identity-v3 is all just Keystone-v2 anyway | 20:33 |
rm_work | or... | 20:33 |
rm_work | just "Keystone | 20:33 |
rm_work | " | 20:33 |
rm_work | Keystone provides Identity_v2 and Identity_v3 | 20:34 |
rm_work | so I guess what I meant was "this is not related to identity v2 or v3" | 20:34 |
rm_work | ayoung: that is ... more correct? | 20:34 |
ayoung | rm_work, this will work regardless of v2 or v3 tokens | 20:35 |
*** dims_ has joined #openstack-keystone | 20:35 | |
rm_work | ok | 20:35 |
rm_work | that's all I needed to know then | 20:35 |
rm_work | so, assuming this goes in, it'll look like.... | 20:35 |
rm_work | err, well, give me a sec to update this diagram | 20:35 |
*** radez is now known as radez_g0n3 | 20:37 | |
*** fifieldt_ has quit IRC | 20:38 | |
bjornar_ | once again, admin proc vs main proc, what are the differences, and where can I read up? | 20:39 |
*** lmtaylor1 has left #openstack-keystone | 20:41 | |
*** stevelle_ has left #openstack-keystone | 20:42 | |
rm_work | ayoung / nkinder: http://goo.gl/6MlhHS | 20:43 |
rm_work | ayoung: updated to move the Trust creation to the User's scope, and to indicate we use TWO tokens for the "Register as Consumer" step | 20:44 |
gyee | bjornar_, https://github.com/openstack/keystone/blob/master/etc/keystone-paste.ini#L105 | 20:44 |
bjornar_ | so apiv3 does not have separate apis? | 20:45 |
gyee | nope, Keystone v3 have no admin/public separation | 20:46 |
bjornar_ | thats nice | 20:46 |
rm_work | gyee: apparently there is no Keystone v3 :P | 20:46 |
gyee | whahhh? | 20:46 |
rm_work | gyee: ayoung just told me, lol | 20:46 |
rm_work | I think it's a terminology issue <_< | 20:47 |
rm_work | but as someone new to this it is very confusing | 20:47 |
bjornar_ | but once again.. what is admin api used for? | 20:47 |
*** gordc has joined #openstack-keystone | 20:47 | |
*** andreaf has quit IRC | 20:48 | |
*** dolphm has left #openstack-keystone | 20:49 | |
bjornar_ | are all components api-v3 compatible in master now? | 20:50 |
*** fifieldt_ has joined #openstack-keystone | 20:50 | |
gyee | bjornar_, that's a historic thing | 20:52 |
gyee | Keystone v2 and prior, admin APIs are mostly extensions | 20:52 |
bjornar_ | I see some services are using it.. | 20:52 |
gyee | service using it and API extension are two different thing | 20:54 |
bjornar_ | yes... but | 20:55 |
gyee | "identity management" is one of those things where Keystone can't quite get a good grasp on | 20:55 |
bjornar_ | I see, for example nova list: | 20:56 |
bjornar_ | http://pastie.org/pastes/9539988/text?key=wdm1xzeec8ww0iiecep1w | 20:56 |
*** jasondotstar has quit IRC | 20:56 | |
gyee | identity management requirements are different, depending on the vendor and industry | 20:57 |
gyee | some require PII protection, some may not, some require life cycle management, some may not | 20:58 |
Morgan_ | gyee: it would be too easy otherwise. | 20:58 |
gyee | right, point is, we never quite agree on what is identity management, so opted for the minimum :) | 20:59 |
gyee | and hence, integration/federation as the easy way out | 21:00 |
bjornar_ | but again: does all (nova,neutron,glance,cinder,ceilometer,heat) support v3 api now? (juno/master)? | 21:00 |
*** marcoemorais has quit IRC | 21:01 | |
gyee | bjornar_, yes, most service support v3 api now | 21:01 |
bjornar_ | most.... | 21:01 |
*** marcoemorais has joined #openstack-keystone | 21:01 | |
Morgan_ | bjornar_: most of the services don't care what keystone API is used. The middleware is the important part. If it translates the data in a way the services can read it will work. | 21:01 |
bjornar_ | I dont care if trove does not support.. | 21:01 |
bjornar_ | admin_auth_url ... | 21:01 |
gyee | bjornar_, there are still a couple of loose ends to tie | 21:02 |
*** jaosorior has quit IRC | 21:02 | |
Morgan_ | gyee: and the whole role policy thing. | 21:02 |
gyee | yes, that policy thing too | 21:02 |
gyee | but policy is customizable | 21:03 |
Morgan_ | Nova seems to handle non matching projects decently. At least a sane error for domaine scoped tokens | 21:03 |
Morgan_ | Policy is a big bit of tech debt we have across openstack. | 21:04 |
gyee | Morgan_, oh, get implemented match any for oslo policy? | 21:04 |
gyee | s/get/you/ | 21:04 |
Morgan_ | gyee: nope no changes needed. It says something like "project doesn't match context" | 21:04 |
gyee | k, cryptic error, but works :) | 21:05 |
Morgan_ | Yeah. Going to submit a doc change to nova (this week I hope) | 21:05 |
Morgan_ | Just to cover our bases | 21:05 |
gyee | nice! | 21:05 |
openstackgerrit | Aaron Rosen proposed a change to openstack/python-keystoneclient: Sync with latest oslo-incubator https://review.openstack.org/119451 | 21:06 |
bjornar_ | So you guys know the best.. What services can I deploy now with only v3 keystone api enabled | 21:06 |
*** gordc has quit IRC | 21:08 | |
gyee | bjornar_, none, till we fix this last one, https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L1044 | 21:08 |
gyee | so you'll have to run both v2 and v3 for now | 21:09 |
gyee | till we close the loop on these | 21:09 |
gyee | I think there's a patch pending on the keystonemiddleware side already | 21:10 |
gyee | if not, I'll work on it | 21:10 |
bjornar_ | is this juno ready, then? | 21:10 |
dstanek | dobson: what do you think about my comment here https://review.openstack.org/#/c/110904/ on aug 8th? | 21:10 |
gyee | bjornar_, keystonemiddleware is on a different release cycle | 21:11 |
gyee | it is released on-demand | 21:11 |
dstanek | hmmmm...no dolphm? | 21:11 |
openstackgerrit | Samuel de Medeiros Queiroz proposed a change to openstack/keystone: Improve list role assignments filters performance https://review.openstack.org/116682 | 21:11 |
dstanek | sorry dobson! mistype | 21:11 |
Morgan_ | dstanek: a real concern | 21:12 |
Morgan_ | dstanek: table scans suck. | 21:12 |
dstanek | Morgan_: if the table is small and static it could be OK, but i hate to advertise a feature that could significantly slow down someone's cloud | 21:13 |
Morgan_ | I def want to see stuff like that cleaned up for kilo. But I'd hope that table isn't too bad (a few hundred rows to few thousand wouldn't e the end of the world) | 21:13 |
dstanek | is that call admin only? | 21:14 |
*** meker12 has joined #openstack-keystone | 21:15 | |
*** topol has joined #openstack-keystone | 21:15 | |
dstanek | Morgan_: what's up with the new name? | 21:15 |
Morgan_ | dstanek: on my phone at a coffee shop for lunch | 21:15 |
Morgan_ | This is through irc cloud | 21:15 |
Morgan_ | dstanek: if that call is admin only I'm much less worried about the code btw. | 21:16 |
*** gordc has joined #openstack-keystone | 21:18 | |
dstanek | Morgan_: yeah, that's why is asked :-) otherwise it could be a real easy way to get DOSed | 21:18 |
Morgan_ | ++. | 21:18 |
dstanek | Morgan_: how do you like irc cloud? i look a while back, but decided not to try. do they still have a free tier? | 21:19 |
Morgan_ | If it isn't admin only let's punt to kilo saying we need to address dos issues. Even if it is aim only, maybe punt | 21:19 |
*** dims__ has joined #openstack-keystone | 21:19 | |
Morgan_ | dstanek: yep. But you can't stay connected for more than 2hrs idle after the first 7days | 21:20 |
Morgan_ | So it's good in a pinch just not for everyday use unless you pay | 21:20 |
*** dims__ has quit IRC | 21:20 | |
*** dims__ has joined #openstack-keystone | 21:21 | |
dstanek | i'll probably stick with my combo of weechat and androirc | 21:22 |
*** dims_ has quit IRC | 21:23 | |
Morgan_ | I don't see weechat for iOS. | 21:23 |
Morgan_ | Or I'd move to it. | 21:24 |
rm_work | ayoung: talked to our other project members, and while I know it isn't ideal from Keystone's perspective (and probably from a security purist's perspective) we're probably going to stick with something more like the original design, in which LBaaS creates the Trust using the Token the user sent in: http://goo.gl/uXKyjs | 21:24 |
*** dims__ has quit IRC | 21:25 | |
dstanek | Morgan_: androirc is pretty good on my android, but i'd love to find something better | 21:25 |
*** jsavak has quit IRC | 21:28 | |
rm_work | dstanek: I use AndChat, it works well, HoloIRC looked good but i had an issue where messages just *didn't show up* from some users in some cases (still no idea WTF) so I stopped using it | 21:29 |
rm_work | but maybe it is better now? :/ it definitely looked slick | 21:29 |
rm_work | AndroIRC was my least favorite, I think <_< | 21:30 |
morganfainberg | anyway | 21:31 |
*** TheDodd has joined #openstack-keystone | 21:33 | |
*** TheDodd has quit IRC | 21:39 | |
*** amcrn has joined #openstack-keystone | 21:39 | |
*** joesavak has joined #openstack-keystone | 21:39 | |
*** dims_ has joined #openstack-keystone | 21:39 | |
*** jsavak has joined #openstack-keystone | 21:40 | |
*** dolphm has joined #openstack-keystone | 21:43 | |
*** ChanServ sets mode: +o dolphm | 21:43 | |
*** joesavak has quit IRC | 21:44 | |
*** dims_ has quit IRC | 21:45 | |
*** dims_ has joined #openstack-keystone | 21:45 | |
*** aix has joined #openstack-keystone | 21:46 | |
*** henrynash has quit IRC | 21:49 | |
samuelmz | dolphm, thanks for your comment on 'Making KvsInheritanceTests use backend KVS' (https://review.openstack.org/#/c/118466/) | 21:51 |
samuelmz | dolphm, I just replied | 21:52 |
dolphm | samuelmz: you're reasoning is testing a backwards compatibility for legacy configurations though | 21:52 |
dolphm | samuelmz: if you want to test KVS assignments, i don't see why you shouldn't explicitly set the assignments driver to KVS | 21:53 |
samuelmz | dolphm, so if I want to test kvs assignment with kvs identity I should set both drivers.. even if kvs identity loads kvs assig by default | 21:55 |
dolphm | samuelmz: yeah, if you want to test both, definitely set both explicitly. that backwards compatibility over a year old, and i could see it being dropped soon. then we'll be back to testing the wrong driver :( | 21:56 |
dolphm | is* over | 21:56 |
*** jsavak has quit IRC | 21:56 | |
*** topol has quit IRC | 21:56 | |
bknudson | samuelmz: in the near future the assignment driver won't get its class from the identity driver. | 21:56 |
*** joesavak has joined #openstack-keystone | 21:57 | |
samuelmz | dolphm, bknudson, I got it :) | 21:57 |
dolphm | samuelmz: i knew there was more to that patch than i suspected :) thanks for clarifying | 21:57 |
samuelmz | dolphm, bknudson, in this case, soon we'd be testing kvs identity with <somehting> assignment | 21:58 |
bknudson | probably sql | 21:58 |
morganfainberg | dstanek, responded to your comment about admin-only | 21:58 |
dolphm | https://review.openstack.org/#/c/110904/ ^ dstanek | 21:58 |
samuelmz | dolphm, changing to set explicitly set the assignment driver .. even if we're about to drop the kvs backend | 21:59 |
samuelmz | dolphm, just to make things work as they are supposed to :-) | 21:59 |
*** jsavak has joined #openstack-keystone | 22:00 | |
*** stevemar has quit IRC | 22:01 | |
*** nkinder has quit IRC | 22:02 | |
*** joesavak has quit IRC | 22:05 | |
ayoung | rm_work, that does not solve your problem | 22:05 |
ayoung | the trust token will not have the admin privs on it | 22:05 |
jamielennox | morganfainberg, ayoung: https://review.openstack.org/120261 - i don't know any way to test it than let the gate do it's job so let me know if you see a problem | 22:06 |
ayoung | as far as LBaaS creating a trust, yeah, that sucks, but do what you feel best. | 22:06 |
morganfainberg | jamielennox, pretty much | 22:07 |
morganfainberg | jamielennox, need to let the gate do it's thing | 22:07 |
*** bknudson has quit IRC | 22:08 | |
ayoung | jamielennox, good start | 22:08 |
morganfainberg | jamielennox, ayoung, are we not sourcing from githubg? | 22:10 |
jamielennox | morganfainberg: i could throw together a cookie cutter base repo, but i figured we could just as easily do that in review | 22:10 |
ayoung | morganfainberg, I was still pulling the code together. | 22:10 |
jamielennox | putting the base plugin into github and bringing it in that way is a bit like cheating | 22:10 |
morganfainberg | dolphm, dstanek, if the admin-only concern on the list_services filter by name | 22:11 |
morganfainberg | dolphm, dstanek, i'm good to press go on it | 22:11 |
openstackgerrit | Samuel de Medeiros Queiroz proposed a change to openstack/keystone: Making KvsInheritanceTests use backend KVS https://review.openstack.org/118466 | 22:11 |
samuelmz | dolphm, ^ | 22:11 |
rm_work | ayoung: yeah, note I also ported over the part where we use *both* tokens to do the Container Registration | 22:13 |
rm_work | LBaaS->Barbican: Register as a Consumer on ContainerID | 22:13 |
jamielennox | ayoung, dolphm: this had a previous +A and needed rebasing: https://review.openstack.org/#/c/119261/ | 22:13 |
rm_work | note right of LBaaS: using Trust Token *and* LBaaS Token | 22:13 |
rm_work | ayoung: ^^ which is the CR you linked me, right? | 22:13 |
rm_work | ayoung: so, next steps are: wait for that CR to make it through, and then update Barbican's middleware code, and then fix the rule in policy.json in Barbican to check for the right things | 22:14 |
rm_work | ayoung: right? | 22:14 |
rm_work | still need to figure out what "the right things" to check for are though, but I'll get there | 22:15 |
*** sigmavirus24 is now known as sigmavirus24_awa | 22:15 | |
rm_work | I guess I will just have to stall that one piece until that stuff makes it in | 22:15 |
*** ayoung has quit IRC | 22:16 | |
*** bjornar_ has quit IRC | 22:16 | |
jamielennox | morganfainberg: can you look at https://review.openstack.org/#/c/116757/ and https://review.openstack.org/#/c/116760/ - same sides of the same problem which means HEAD keystonemiddleware tests won't pass with HEAD keystoneclient | 22:17 |
morganfainberg | ah | 22:17 |
jamielennox | two sides of the same problem | 22:17 |
morganfainberg | jamielennox, in a couple will look | 22:17 |
jamielennox | morganfainberg: no problem - sharing things around | 22:17 |
rm_work | bbl | 22:19 |
*** jorge_munoz has quit IRC | 22:30 | |
*** jsavak has quit IRC | 22:31 | |
*** gordc has quit IRC | 22:32 | |
*** joesavak has joined #openstack-keystone | 22:34 | |
jamielennox | gyee: can you look over https://review.openstack.org/#/c/117709/ when you get a minute | 22:38 |
gyee | jamielennox, sure, I am in review mode | 22:39 |
jamielennox | gyee: in that case... | 22:39 |
gyee | uh oh | 22:39 |
jamielennox | there's the two i was trying to give to morgan https://review.openstack.org/#/c/116757/ and https://review.openstack.org/#/c/116760/ | 22:40 |
jamielennox | gyee: none of these are hard yet | 22:40 |
jamielennox | gyee: mostly i'm just trying to clear up the easy ones that have sat unreviewed | 22:40 |
jamielennox | gyee: if i can do that then i'll try and get people to tackle the ones with actual new features tomorrow | 22:40 |
*** joesavak has quit IRC | 22:41 | |
gyee | yeah, those looks like nobrainers | 22:41 |
jamielennox | https://review.openstack.org/#/c/119261/ has had a previous +A but needed a small fix | 22:41 |
*** dims_ has quit IRC | 22:42 | |
*** dims_ has joined #openstack-keystone | 22:43 | |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Document mod_wsgi doesn't support chunked encoding https://review.openstack.org/120274 | 22:45 |
*** dims_ has quit IRC | 22:47 | |
openstackgerrit | Morgan Fainberg proposed a change to openstack/keystone: Document mod_wsgi doesn't support chunked encoding https://review.openstack.org/120274 | 22:47 |
*** dims_ has joined #openstack-keystone | 22:49 | |
*** amerine has joined #openstack-keystone | 22:52 | |
morganfainberg | jamielennox, +2 on both of the ones you pointed me at | 22:57 |
jamielennox | morganfainberg: thanks | 22:57 |
dolphm | gyee: you're on a roll :) | 22:57 |
gyee | dolphm, I am in review mode today | 22:58 |
*** dims_ has quit IRC | 23:00 | |
*** dims_ has joined #openstack-keystone | 23:00 | |
dolphm | gyee: thanks :) | 23:00 |
*** dims_ has quit IRC | 23:05 | |
dolphm | just had a heart attack: git status -> oh shit all my changes are gone?! -> pwd -> wtf?! -> ls -> ?! oh i'm in the same repo on the same cwd in two terminals on two different hosts | 23:09 |
gyee | lmao | 23:10 |
gyee | need color-coded prompts :) | 23:11 |
*** david-lyle has quit IRC | 23:15 | |
*** gordc has joined #openstack-keystone | 23:17 | |
*** nkinder has joined #openstack-keystone | 23:18 | |
*** ncoghlan has joined #openstack-keystone | 23:19 | |
*** ayoung has joined #openstack-keystone | 23:28 | |
*** david-lyle has joined #openstack-keystone | 23:34 | |
*** zzzeek has quit IRC | 23:40 | |
openstackgerrit | Samuel de Medeiros Queiroz proposed a change to openstack/keystone: Fix return from list role assignments on KVS https://review.openstack.org/118482 | 23:49 |
samuelmz | dolphm, ^ related to those bugs of inheritance and kvs backend | 23:51 |
*** samuelmz is now known as samuelmz-zzz | 23:57 | |
jamielennox | gyee: still reviewign? | 23:58 |
*** oomichi has joined #openstack-keystone | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!