Wednesday, 2014-06-18

ayoungthat pass the sanity check>?00:00
ayoungjamielennox, let it atleast pass jenkins before you noodge00:00
jamielennoxayoung: fair - just need to get back into nagging mode00:01
ayoungHeh..looking at the adapters patch...00:01
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Fix a few typos in the shibboleth doc  https://review.openstack.org/10072300:01
ayoungjamielennox, I take it that is just cleanup?00:02
openstackgerritayoung proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889700:02
jamielennoxayoung: it's what we need to work with the session in other clients00:02
morganfainbergayoung, i'll keep my eye on that ^ so we can get it moving (barring any major issues)00:02
morganfainbergthen... yay gate on mod_wsgi!00:03
ayoungjamielennox, ah...ok00:03
jamielennoxi'd like if it was called something other than adapter - but i got nothing00:03
ayoungjamielennox, nah, it makes sense, especially in that it is for working with other's code00:04
ayoungpython33 error00:04
ayounghttp://logs.openstack.org/81/97681/3/check/gate-python-keystoneclient-python33/fbae529/console.html.gz00:04
ayoung TypeError: Can't convert 'bytes' object to str implicitly00:04
ayoungFile "./keystoneclient/adapter.py", line 94, in request00:05
ayoung2014-06-10 23:39:02.166 |     body = resp.json()00:05
jamielennoxalmost c&p https://review.openstack.org/#/c/95986/1/cinderclient/client.py and https://review.openstack.org/#/c/85920/7/novaclient/client.py00:05
ayoungjamielennox, I think that is just (str)00:05
jamielennoxeh, really?00:05
jamielennoxwhere's that?00:05
ayoungjamielennox, hmmm, maybe?  that is what it was for the PKIZ tokens00:06
*** gokrokve_ has joined #openstack-keystone00:06
ayounghttps://review.openstack.org/#/c/100545/00:06
ayoungah, no, that was from uicode, not bytes00:06
jamielennoxthat one passes00:06
ayoungunicode00:06
ayoungpy33?00:06
jamielennoxoh - right, yea that one needs a lot more work i just wanted to see if it was ok00:07
*** hrybacki has joined #openstack-keystone00:07
ayoungmsg.decode('utf-8')00:08
jamielennoxideally this would eventually fix the circular dependency not cleaning up thing in keystoneclient as well00:08
ayoungjamielennox, I think you need ^^00:08
jamielennoxyea00:08
*** gokrokve has quit IRC00:09
*** bknudson has quit IRC00:11
*** amerine has quit IRC00:17
*** amerine has joined #openstack-keystone00:19
ayoungjamielennox, https://review.openstack.org/#/c/81166/ is your territory00:23
ayoungmorganfainberg, you need ^^ for ephemeral, too00:23
ayounggyee, I'll noodge you just cuz you are here00:24
jamielennoxergh, yea such a monster00:24
morganfainbergayoung, yeah.00:24
ayoungthat one is not that bad00:24
jamielennoxi'm not sure if you need to break out the revoke model stuff00:25
morganfainbergayoung, "not that bad" (~1200 lines later) :P00:25
jamielennoxyour model is very tied to the v3 format00:25
ayoungis it 1200?00:25
morganfainbergayoung, 116200:25
ayoungah...cuz it pulled the code over from server00:25
ayoungthat code is almost a direct copy of code in keystone.contrib.revoke.model00:26
jamielennoxand it means you have things like RevokeModel that seems to do pretty much only serialize and unserialize - that could be just a resource00:26
ayoungall the hard parts are00:26
ayoungjamielennox, agreed that it could be restrucutred.  I was trying to make it easy by just copying the file over00:26
morganfainbergayoung, going to fix the nits in PKIZ really quickly00:26
ayoungthere were a few earlier issues that involved modifing the model00:27
ayoungmorganfainberg, please do00:27
jamielennoxyea, the other side is i've never quite got through all the process of checking revocations - just trusting00:27
jamielennoxso if you copied most of model across from the server that make some sense00:27
jamielennox_build_token stuff can be entirely replaced by AccessInfo00:27
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889700:28
jamielennoxayoung: can i have a go at cutting it down?00:29
jamielennoxdo you intend to import that code from the server?00:29
ayoungjamielennox, absolutely00:29
ayounggo for it00:29
morganfainbergayoung, well, moving to apache keystone, tempest is taking 31 minutes instead of 43. that seems to be a win!00:29
ayoung++00:29
jamielennoxthere was some rally benchmarks going around that showed apache faster as well00:30
gyeeayoung, that over 1KLOC to review!00:30
gyeeits going to take me all night00:30
ayoungmorganfainberg, we are going to spam the hell out of the logs with that deprecation warning, aren;t we?00:31
morganfainbergonly on startup.00:31
ayoungmorganfainberg, is it?00:31
ayoungmorganfainberg, well, if it does, we an remove it00:31
morganfainbergyep. it is used on manager init and in a couple testsshouldn't be bad00:32
morganfainbergit's not used over and over afaict00:32
ayoungmorganfainberg, +13ed.  feel free to +2 and gyee feel free to +2a00:32
ayoung+1ed.  I wish I could +1300:32
morganfainbergayoung, hah00:32
gyeelooks good!00:33
ayoungOK..still at the office. going to drive home.  If you guys put the +2 on it, I'll +A when I'm home, assuming it passes muster00:33
gyeegym time, will check back in an hour or so00:34
ayoungjamielennox, I'll start cranking through the client code once I'm home.00:34
morganfainbergayoung, +2, once it passes check good for +A (PKIZ)00:34
morganfainbergayoung, i'll +A if I see it finish before you do.00:35
morganfainbergi need to get devstack to setup caching (memcached) for keystone.00:35
morganfainbergso we can gate on that (not just unit tests) then we need tempest to run with caching. bet that will improve things again.00:36
hrybackiayoung: 830 and you're still not home. Dedication.00:36
ayounghrybacki, just got to your email.00:40
ayounghrybacki, do a code review of the session patch.  You'll need to understand how that works to understand why its what you need to do for auth_token00:41
hrybackiokay00:41
ayoungjamielennox, hrybacki was able to work through getting the revokation script running00:41
ayoungif you rework the client, give it to him so he can double check against a live keystone00:41
ayoung(that is how we abuse interns at Red Hat)00:42
ayoungmake em work with thee guys on Australian time00:42
ayoungme flees00:42
hrybackihah00:42
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907600:42
*** browne has quit IRC00:42
jamielennoxayoung: np00:43
jamielennoxi thought they abused the non-us guys by making them work US time00:43
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9626500:47
*** ayoung has quit IRC00:49
*** hrybacki has quit IRC00:52
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add trust users to AccessInfo  https://review.openstack.org/10073300:54
*** rwsu has quit IRC00:58
*** huats has quit IRC00:58
*** marcoemorais has quit IRC01:06
*** rodrigods has joined #openstack-keystone01:09
*** rodrigods has joined #openstack-keystone01:09
*** mberlin has joined #openstack-keystone01:12
*** mberlin1 has quit IRC01:13
openstackgerritArun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling.  https://review.openstack.org/9530001:13
*** huats has joined #openstack-keystone01:19
*** huats has quit IRC01:19
*** huats has joined #openstack-keystone01:19
openstackgerritArun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling.  https://review.openstack.org/9530001:26
*** nkinder_ has joined #openstack-keystone01:32
*** ayoung has joined #openstack-keystone01:34
jamielennoxayoung: does revocation use role_id or role_name?01:35
ayoungjamielennox, id, I think01:36
jamielennoxdamn01:36
* ayoung has to confirm01:36
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/revoke/core.py#n86  jamielennox role_id01:37
jamielennoxit's like the only thing that does01:37
ayoungjamielennox, why is that a problem?01:37
openstackgerritArun Kant proposed a change to openstack/keystone: Adding support for ldap connection pooling.  https://review.openstack.org/9530001:37
jamielennoxnothing just another thing to fix in client01:38
ayoungjamielennox, I think we could potentially change that01:38
ayoungif it really is wrong01:38
jamielennoxare role_ids available in v2 tokens?01:38
ayoungjamielennox, good question.  I haven't thought about this code in a month or so...01:41
ayoungjamielennox, https://review.openstack.org/#/c/81166/17/keystoneclient/contrib/revoke/model.py  line 29601:41
ayounggyee, https://review.openstack.org/#/c/95989/  when you get back:  are you OK with the general flow now, or is something still unclear01:45
*** richm has left #openstack-keystone01:49
*** praneshp has quit IRC01:53
*** rodrigods has quit IRC01:54
jcromeris this an appropriate place to ask a question regarding active directory as an ldap backend for keystone?01:56
*** dims has quit IRC01:58
ayoungjcromer, yes01:58
jcromerayoung, I have read thru a number of your blog posts regarding ldap01:59
ayoungI lie01:59
jcromer:D01:59
ayoungI make things up01:59
ayoungI break things01:59
jcromerdon't we all01:59
ayoungall the people, some of the time....me, all the time01:59
ayoungwhat can I help you with?01:59
jcromerhah01:59
jcromerso i configured keystone for ldap backend for auth02:00
jcromerset all my service acounts up02:00
jcromereverything works great02:01
jcromerbut i want to be able to create users02:01
ayoungno you don't02:01
jcromerwell i need to02:01
jcromerfor rally02:01
ayoungin AD?02:01
jamielennoxayoung: so do you kow how old that ['metadata']['roles'] thing is because it doesn't exist in any of our test tokens?02:01
ayoungyour AD is not read only?02:01
jamielennoxayoung: when you have time02:01
ayoungjamielennox, empirical?02:01
ayoungjamielennox, I think I just created one and looked at it?02:01
ayoungeasy enough to check02:02
jcromersome of the rally scenarios i am using create users and tenants and then delete them after the tests concludes02:02
ayoungjcromer, so, yeah, it is possible to do.  I know CERN does it...02:03
jcromerthis doesn't work anymore since the change to ldap02:03
ayoungwell, I think they do.  They have AD writable02:03
jcromeri have been searching the interwebs02:03
ayoungjcromer, what happens when you do a user-add?02:03
jcromernot finding a whole lot as to how this is accomplished02:03
jcromerSvcErr: DSID-031907E9, problem 5003 (WILL_NOT_PERFORM)02:03
* ayoung stifles inappropriate comment02:04
jcromerHAHA02:04
jcromeryea02:04
jcromerit's not performing02:04
ayoungAD return codes are so refreshing02:04
jcromerlove them02:04
ayoungjcromer, can you inject a user into AD by hand using, say, the openldap command line tools?02:05
jcromeri (foolishly) thought it would be as easy as user_allow_create = True02:05
ayoungjcromer, heh, don't know what is wrong. But if it were a keystone config option, it wouldn't be getting to AD at all02:05
jcromeri have not yet tried that02:05
ayoungI assure you SvcErr: DSID-031907E9, problem 5003 (WILL_NOT_PERFORM)  is not a Keystone error message02:06
jcromeroh i know that much02:06
jcromerjust wasn't sure if there was something that i was missing02:06
jcromerin the config02:06
ayoungjcromer, are you doing one level or deep searches for users?02:06
jcromersome secret option i was missing02:06
jcromersub02:06
ayounghmmm, that might be the problem...02:06
jcromerfor the query scope you mean?02:06
ayoungjust a guess, but to add a user you need a DN, and I think that subtree does something different02:07
ayoungOK...here is where I show just how big a hack I am02:07
ayoungthe LDAP code was origianally written by someone else for Nova and hacked into keystone, then hacked out, and then I hacked it back in02:08
ayoungits ugle, and made some really bad assumptions02:08
ayoungI got rid of some of those assumptions, but not all02:08
jcromeryou know what they say, a good artist borrows a great artist steals02:08
ayoungone of them was that the userid attribute was the left most segment of the DN02:08
ayoungso if your dn is cn=jcromer,cn=someor,cn=com  the userid attribute was cn02:09
ayoungeven if cn for your record was Cromer, Jaques02:09
ayoungso the subtree  query break free of that, and will actually search on cn=02:10
ayoungas opposed to composing the DN.  Follow me?02:10
ayoungthe subtree stuff came later, which is why it is inconsistent02:10
jcromeri think so02:10
ayoungso, I don;t know if, with subtree, it knows how to create the DN02:10
morganfainbergayoung, getting close to PKIZ!02:11
ayounglets take a look and see02:11
ayoungmorganfainberg, don't jinx it02:11
jcromerok02:11
morganfainbergayoung, already knocked on wood and toss salt over the shoulder02:11
ayoungmorganfainberg, I knocked on salt and threw wood over my shoulder.  I knew I had something wrong02:11
morganfainbergayoung, hah02:12
ayoungjcromer, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/ldap/core.py#n96902:12
ayounglooking at that code, I think:   how did that ever work?02:12
jcromerheading there now02:12
morganfainbergayoung, looks like we save ~5-10mins on a tempest run with keystone under apache (and PKIZ)02:13
ayoungjcromer, how badly do you need this?02:13
morganfainbergayoung, some LDAP stuff wonky?02:13
ayoungmorganfainberg, he wants to be able to write to AD.  Crazy monkey.02:13
morganfainbergayoung, whoa.02:13
jcromerit's not like it is a production, do or die type situation02:14
morganfainbergi uh.. dunno if we've ever tried that02:14
jcromerbut for rally testing02:14
morganfainbergin theory... possible02:14
ayoungmorganfainberg, I have ,but not with subtree query for user.  Suspect it is broken/unfixable02:14
jcromerwhich we are starting to do a lot of lately02:14
jcromerwell02:14
ayoungjcromer, can you create the users directly?02:14
morganfainbergayoung, ah02:14
ayoungIf not, can you go from subtree?02:14
ayounger...drop the subtree requirement?02:15
jcromeri could potentially drop the subtree requirement02:15
jcromerput all users in a specific OU02:15
ayoungjcromer, try that. I think that will work for you02:15
openstackgerritA change was merged to openstack/keystone: Default to PKIZ tokens  https://review.openstack.org/9889702:15
ayoungjcromer, that is what FreeIPA does.  It is very relational in its approach to users, and that leads to sanity02:16
morganfainbergboom.02:16
morganfainbergayoung, https://review.openstack.org/#/c/100747/02:16
ayoungmorganfainberg, and we now hear the screaming02:16
jcromershould i then be taking a look at FreeIPA instead?02:16
ayoungjcromer, I am not an impartial judge of that02:17
ayoungit depends on your needs.02:17
jcromeri think the case is rare where users will need to be created02:17
ayoungBut in my terribly biased opinion FreeIPA rocks02:18
jcromerbut it will be required every so often02:18
ayoungjcromer, but I think that if, you are up and running , and can drop the subtree requirement, it would not buy you much to change before you get it working02:18
morganfainbergayoung, also.. figured might as well muck with this in here: https://review.openstack.org/#/c/100747/ caching in tempest!02:19
ayoungmorganfainberg, I put a +1 and a comment on that review02:19
morganfainberg:)02:19
morganfainbergbut that one is WIP02:19
morganfainbergwant to see how it performs.02:19
*** nsquare has quit IRC02:19
ayoungmorganfainberg, wrong patch. That is the same one you just posted02:19
morganfainbergyeah02:19
morganfainbergcopy/paste fail: https://review.openstack.org/#/c/100738/02:20
ayounggate-tempest-dsvm-large-ops SUCCESS in 29m 08s02:21
jcromerby the way02:21
jcromeri found a bug regarding this just now02:21
ayoungmorganfainberg, what was it before on a comparable run?02:21
jcromerafter you mentioned02:21
morganfainbergayoung, uhm...02:21
ayoungno way, that code is flawless jcromer02:21
jcromerhah02:22
jcromerhttps://bugs.launchpad.net/keystone/+bug/1210141.02:22
uvirtbotLaunchpad bug 1210141 in keystone "Document howto config LDAP identity with non-DN based ids." [Medium,In progress]02:22
morganfainberg3202:22
morganfainbergayoung, 32 ish from what i was seeing02:22
morganfainbergbut the real trick will be what is it under apache.02:22
*** dims has joined #openstack-keystone02:24
ayoungjcromer, so, if you did do subtree...where would you create a new user?02:24
*** dims has quit IRC02:28
jcromerwell right now i three OUs under Accounts: Domestic, International and Service02:31
jcromerthe problem is my service OU contains accounts for all the openstack services and Domestic contains actual user accounts02:32
*** Chicago has joined #openstack-keystone02:33
*** Chicago has joined #openstack-keystone02:33
jcromermaybe one would work02:34
ayoungjamielennox, OK,  if you have any reviews that are high priority, makes sure you've added me explicitly as a reviewer.  AFAICT I have addressed all that are not -1ed somehwhere02:35
*** ayoung is now known as ayoung_ZZZzzz02:35
jamielennoxok, i haven't been setting that much anymore02:36
*** gokrokve_ has quit IRC02:43
*** zhiyan_ is now known as zhiyan02:44
stevemarayoung_ZZZzzz, yay compressed tokens by default02:44
stevemarmorganfainberg, ping?02:48
*** harlowja is now known as harlowja_away02:48
morganfainbergstevemar, pong02:48
stevemarmorganfainberg, so ya know how our keystone dev docs and keystoneclient dev docs have the same layout?02:49
morganfainbergstevemar, uh sure02:49
stevemarmorganfainberg, do you know how to migrate to that format? because http://docs.openstack.org/developer/python-novaclient/ and http://docs.openstack.org/developer/python-openstackclient don't :\02:49
morganfainberguhhh02:49
morganfainberguhmmm02:49
morganfainbergnot really sure02:50
stevemardid i just blow your mind? is it too late for this nonsense ?02:50
*** praneshp has joined #openstack-keystone02:50
morganfainbergstevemar, sorry elbow deep in grenade atm, trying to get us gating on mod_wsgi for keystone02:53
morganfainbergstevemar, :P02:53
stevemarmorganfainberg, s'all good :)02:54
*** gokrokve has joined #openstack-keystone02:54
*** praneshp_ has joined #openstack-keystone02:59
*** gyee has quit IRC02:59
*** praneshp has quit IRC03:02
*** praneshp_ is now known as praneshp03:02
*** Chicago is now known as SuperUser03:15
*** SuperUser is now known as UsurperUser03:17
*** UsurperUser has left #openstack-keystone03:17
*** topol has joined #openstack-keystone03:42
*** dims has joined #openstack-keystone04:27
*** dims has quit IRC04:32
*** ajayaa has joined #openstack-keystone04:44
*** dims has joined #openstack-keystone04:46
*** dims has quit IRC04:51
*** nsquare has joined #openstack-keystone05:16
morganfainbergdtroyer_zz, https://review.openstack.org/#/c/100747/ needs a grenade upgrade script here: https://review.openstack.org/#/c/100764/05:17
*** henrynash has joined #openstack-keystone05:40
*** jkappert has quit IRC05:45
*** jkappert has joined #openstack-keystone05:45
*** dims has joined #openstack-keystone05:47
*** dims has quit IRC05:51
*** afazekas_ has joined #openstack-keystone05:54
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/9700506:00
*** topol has quit IRC06:04
*** openstackgerrit_ has joined #openstack-keystone06:10
*** gokrokve has quit IRC06:11
*** stevemar has quit IRC06:14
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add trust users to AccessInfo and fixture  https://review.openstack.org/10073306:15
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add role ids to the AccessInfo  https://review.openstack.org/10077406:15
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add issued handlers to auth_ref and fixtures  https://review.openstack.org/10077506:15
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add OAuth data to AccessInfo  https://review.openstack.org/10077606:15
jamielennoxayoung_ZZZzzz: tomorrow i'll rebase the revocation events patch on top of ^ so feel free to pressure people into approving them06:18
*** tomoiaga1 has joined #openstack-keystone06:19
*** ajayaa has quit IRC06:19
*** jimbaker has quit IRC06:19
*** openstackgerrit has quit IRC06:19
*** ajayaa has joined #openstack-keystone06:23
*** jimbaker has joined #openstack-keystone06:23
*** openstackgerrit has joined #openstack-keystone06:23
*** henrynash has quit IRC06:30
*** ncoghlan has joined #openstack-keystone06:45
*** dims_ has joined #openstack-keystone06:47
*** jaosorior has joined #openstack-keystone06:51
*** dims_ has quit IRC06:53
*** gokrokve has joined #openstack-keystone07:02
*** xuhaiwei_ has joined #openstack-keystone07:03
*** gokrokve has quit IRC07:07
xuhaiwei_hi, I met this problem, I ran 'nova --debug list' and got the token, and then copy the curl commands to request to the API directly, but I got an 401 Unauthorized, it is said the token is invalid, this used to work well, so I want to know if something is changed by keystone07:08
xuhaiwei_Could anyone help?07:08
*** BAKfr has joined #openstack-keystone07:12
*** xianghui^ has joined #openstack-keystone07:12
*** xianghui has quit IRC07:16
*** chandan_kumar has quit IRC07:17
*** i159 has joined #openstack-keystone07:34
*** henrynash has joined #openstack-keystone07:35
*** henrynash has quit IRC07:52
*** marekd|away is now known as marekd07:55
*** nsquare has quit IRC07:58
*** leseb has joined #openstack-keystone08:02
*** gokrokve has joined #openstack-keystone08:03
*** leseb has quit IRC08:06
*** leseb has joined #openstack-keystone08:07
*** gokrokve has quit IRC08:08
*** praneshp has quit IRC08:09
*** andreaf_ has quit IRC08:11
*** ncoghlan has quit IRC08:18
*** henrynash has joined #openstack-keystone08:28
*** dims_ has joined #openstack-keystone08:51
*** ByteSore has quit IRC08:52
*** ByteSore has joined #openstack-keystone08:52
*** leseb has quit IRC08:54
*** Gippa has joined #openstack-keystone08:55
*** dims_ has quit IRC08:56
*** andreaf has joined #openstack-keystone08:57
*** andreaf_ has joined #openstack-keystone08:58
*** andreaf has quit IRC09:01
*** gokrokve has joined #openstack-keystone09:03
openstackgerritRoman Bodnarchuk proposed a change to openstack/keystone: Return 400 in case request body is JSON, but not a dictionary  https://review.openstack.org/9280909:08
*** gokrokve has quit IRC09:09
*** xuhaiwei_ has quit IRC09:18
openstackgerritRoman Bodnarchuk proposed a change to openstack/keystone: Fix 500 error if request body is not JSON object  https://review.openstack.org/9280909:20
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users and groups from controller to manager  https://review.openstack.org/10083309:25
*** ByteSore has quit IRC09:28
*** ByteSore has joined #openstack-keystone09:28
*** xianghui^ has quit IRC09:28
openstackgerritChristoph Gysin proposed a change to openstack/keystone: fix flake8 issues  https://review.openstack.org/10062809:43
*** tomoiaga1 has quit IRC09:44
*** zhiyan is now known as zhiyan_09:51
*** dims_ has joined #openstack-keystone09:51
*** xianghui^ has joined #openstack-keystone09:53
*** pheadron has joined #openstack-keystone09:54
pheadrond09:54
*** rodrigods has joined #openstack-keystone09:55
*** rodrigods has quit IRC09:55
*** rodrigods has joined #openstack-keystone09:55
*** dims_ has quit IRC09:56
*** leseb has joined #openstack-keystone09:58
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users and groups from controller to manager  https://review.openstack.org/10083309:58
*** rodrigods has quit IRC09:59
*** gokrokve has joined #openstack-keystone10:04
*** ajayaa has quit IRC10:05
*** gokrokve has quit IRC10:10
*** pheadron has quit IRC10:10
*** leseb has quit IRC10:13
*** xianghui^ has quit IRC10:30
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083310:33
*** ajayaa has joined #openstack-keystone10:33
*** dims_ has joined #openstack-keystone10:43
*** leseb has joined #openstack-keystone10:51
*** xianghui^ has joined #openstack-keystone10:56
*** leseb has quit IRC10:56
*** henrynash has quit IRC11:01
*** gokrokve has joined #openstack-keystone11:05
*** gokrokve has quit IRC11:10
*** topol has joined #openstack-keystone11:13
*** dims_ has quit IRC11:16
*** i159 has quit IRC11:16
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/10027911:21
*** i159 has joined #openstack-keystone11:25
*** d0ugal has quit IRC11:33
*** d0ugal has joined #openstack-keystone11:34
*** leseb has joined #openstack-keystone11:52
openstackgerritAjaya Agrawal proposed a change to openstack/keystone: TestAuthInfo class in test_v3_auth made more efficient.  https://review.openstack.org/9807211:54
*** leseb has quit IRC11:57
*** juanmo has joined #openstack-keystone12:01
*** gokrokve has joined #openstack-keystone12:06
*** i159 has quit IRC12:08
*** gokrokve has quit IRC12:10
*** i159 has joined #openstack-keystone12:11
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Scope unscoped saml2 tokens.  https://review.openstack.org/9970412:12
*** topol has quit IRC12:13
*** Gippa has quit IRC12:16
*** rodrigods has joined #openstack-keystone12:30
*** rodrigods has joined #openstack-keystone12:30
*** andreaf_ has quit IRC12:37
*** andreaf_ has joined #openstack-keystone12:37
*** leseb has joined #openstack-keystone12:38
*** andreaf_ is now known as andreaf12:40
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083312:40
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Simplified Mapping for Federated Authentication  https://review.openstack.org/10028012:44
*** gordc has joined #openstack-keystone12:45
*** henrynash has joined #openstack-keystone12:45
*** tellesnobrega has quit IRC12:56
*** rodrigods has quit IRC12:56
*** htruta has quit IRC12:57
*** richm has joined #openstack-keystone13:00
*** htruta has joined #openstack-keystone13:00
*** rodrigods has joined #openstack-keystone13:01
*** gokrokve has joined #openstack-keystone13:01
*** gokrokve_ has joined #openstack-keystone13:02
*** tellesnobrega has joined #openstack-keystone13:02
*** gokrokv__ has joined #openstack-keystone13:02
*** richm has quit IRC13:03
*** erecio has joined #openstack-keystone13:04
*** dims_ has joined #openstack-keystone13:04
*** gokrokve has quit IRC13:05
*** gokrokve_ has quit IRC13:06
*** gordc has quit IRC13:10
*** nkinder_ has quit IRC13:13
*** joesavak has joined #openstack-keystone13:13
*** dims_ has quit IRC13:13
*** bknudson has joined #openstack-keystone13:14
*** leseb has quit IRC13:15
*** leseb has joined #openstack-keystone13:16
*** henrynash has quit IRC13:16
*** dims_ has joined #openstack-keystone13:17
*** diegows has joined #openstack-keystone13:23
dolphmwhy were 4 completely irrelevant patches dependent on https://review.openstack.org/#/c/98897/ ?13:25
*** gordc has joined #openstack-keystone13:27
*** dims_ has quit IRC13:28
*** richm has joined #openstack-keystone13:31
marekddstanek_zzz: thanks for the review.13:34
openstackgerritSteven Hardy proposed a change to openstack/python-keystoneclient: Enable forcing re-authentication for trust-scoped clients  https://review.openstack.org/9629813:36
*** leseb has quit IRC13:38
*** stevemar has joined #openstack-keystone13:39
*** hrybacki has joined #openstack-keystone13:40
ajayaadolphm, among those four, I have submitted one. How did it become dependent on 98897?13:41
ajayaaI just pulled the latest and resubmitted my patch.13:42
dolphmajayaa: i didn't look at how... i assume that's in the gerrit log13:42
*** dstanek_zzz is now known as dstanek13:42
dolphmajayaa: 98897 is already merged so it's not a big deal, but it struck me as super odd13:43
dstanekmarekd: np13:44
ajayaadolphm, on a side note please review https://review.openstack.org/#/c/98072/ :)13:44
openstackgerritChristoph Gysin proposed a change to openstack/keystone: fix flake8 issues  https://review.openstack.org/10062813:45
marekdstevemar: ding dong.13:46
stevemarmarekd, !!13:47
marekdstevemar: i missed our ping yesterday (had some guests and went offline actually)13:47
marekdyour ping*13:47
marekdstevemar: what's up? :-)13:48
*** ajayaa has quit IRC13:48
stevemarmarekd, i'm trying to remember what it was...13:48
marekdstevemar: your IBM IdP ?13:48
*** daneyon_ has quit IRC13:48
stevemarmarekd, oh maybe ... we got it working, still some issue with shib's key, cause it signs all the assertions13:49
stevemarmarekd, i don't recall13:49
marekdstevemar: apparently nothing really serious.13:49
stevemarmarekd, yeah, sorry13:51
marekdstevemar: no worries!13:51
*** bklei has joined #openstack-keystone13:53
*** bklei has quit IRC13:53
*** sbasam_ is now known as sbasam13:57
*** raildo has joined #openstack-keystone13:58
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907614:05
*** nkinder_ has joined #openstack-keystone14:06
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907614:13
bknudsondolphm: I think the depency change happens when the review is rebased.14:14
*** zuqiang has joined #openstack-keystone14:14
openstackgerritDolph Mathews proposed a change to openstack/keystone-specs: JSON Home  https://review.openstack.org/9735914:14
*** zuqiang has left #openstack-keystone14:15
bknudsonI use emacs for my rst files and it doesn't clean up trailing whitespace14:15
stevemarmarekd, oh oh i remember14:21
*** esmute has quit IRC14:22
stevemarmarekd, it was about testing the full flow of federation test cases14:22
morganfainbergdolphm, gerrit's display is wonky i think, rebases occurred once PKIZ merged.14:22
stevemarmarekd, i suspect you will just say 'thats why we need client'!14:22
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Update sample keystone.conf file  https://review.openstack.org/10015514:23
*** esmute has joined #openstack-keystone14:25
morganfainbergdolphm, so (beyond the needed fixes for grenade) - it looks like we end up saving up to ~5+ minutes per tempest run moving keystone to under apache https://review.openstack.org/#/c/100747/14:25
morganfainbergish.14:25
bknudsonmorganfainberg: because it runs in parallel?14:26
morganfainbergbknudson, something like that i think14:26
morganfainbergeither that or eventlet really sucks14:26
dolphmmorganfainberg: nice!14:27
*** dims_ has joined #openstack-keystone14:27
*** leseb has joined #openstack-keystone14:27
dolphmwhy is red hat ci falling over14:27
morganfainbergdolphm, because it can't install mod_wsgi.14:27
morganfainbergdolphm, something that i'll have to fix in devstack14:27
morganfainbergobviously never tested :P14:27
*** beav has joined #openstack-keystone14:28
*** rwsu has joined #openstack-keystone14:29
morganfainbergor...14:29
morganfainbergnot /me is looking through that log14:29
*** diegows has quit IRC14:31
*** henrynash has joined #openstack-keystone14:34
morganfainbergdolphm, really useful error logging :( http://pasteraw.com/s1yhqo2dsw2jh4a934zqbxcha2ehavx14:34
marekdstevemar: no, i will say: we need this to be finall merged https://review.openstack.org/#/c/83829/ and feel free to weigh in here: https://review.openstack.org/#/c/92166/ and https://review.openstack.org/#/c/99704/ :-)14:34
marekd(sorry, had a confcall)14:34
stevemarmarekd, yeeeep, thats what i thought you would say :)14:35
marekdstevemar: good we are on the same page :-)14:35
stevemarmarekd, also, when you try this w/ a browser, whats the target URL, does it include :5000 in the request?14:35
marekdstevemar: no, i had some issues with nonstandard ssl port :/14:36
stevemarbut you include the port #?14:36
marekdi had my configuration working on 443, and later used https://keystone/v3/[...] and no...didnt use port.14:36
marekdwhat's up with ports?14:36
openstackgerritChristoph Gysin proposed a change to openstack/keystone: fix flake8 issues  https://review.openstack.org/10062814:37
dstanekmorganfainberg: i'm really surprised that it's that much faster14:40
morganfainbergdstanek, i'm seeing it consistently that much faster under apache (might also be PKIZ related)14:40
morganfainbergor the combination of PKIZ + apache14:40
dstanekmorganfainberg: also you'll be blocked less by the MySQL driver14:41
morganfainbergdstanek, yeap14:41
morganfainbergayoung_ZZZzzz, so unique identifier issues in redatcting token ids...14:47
morganfainbergayoung_ZZZzzz, we don't actually rip apart the token in session object14:47
morganfainbergayoung_ZZZzzz, it's an opaque blob.14:47
*** lbragstad has quit IRC14:48
*** lbragstad has joined #openstack-keystone14:49
morganfainbergdstanek, can i pick your brain for a few minutes?14:50
morganfainbergdstanek, you might have an idea or three to help on this front.14:51
dstanekmorganfainberg: sure14:52
morganfainbergdstanek, token obfuscation in logs: we can't hash the token, we have been asked to maintain a way of correlating token X was used across Y,Z,andQ requests, we don't decode/explode the token data in the session object14:52
morganfainbergdstanek, any thoughts on how to meet those requirements?14:53
morganfainbergdstanek, or start to?14:53
*** daneyon has joined #openstack-keystone14:53
dstanekmorganfainberg: why is hashing out?14:53
morganfainbergdstanek, compliance reasons14:54
dstanekhmmm...not even salted? :-(14:54
morganfainbergdstanek, and because if you use a compliant hashing algorithm, and keystone is configured to hash to the same algorithm we end up with the same issue we have now, token is valid to be used14:54
bknudsonessentially the requirement for compliance is that you must be able to disable the non-compliant hashing algorithms14:54
morganfainbergdstanek, i was told yesterday < SHA2 hashing is out14:54
bknudsonso if it's configurable then that's ok, because it will work with a different algorithm14:55
dstaneki guess salting would help anyway14:55
morganfainbergbknudson, will using SHA1 for unique user_ids have the same issue?14:55
dstanekcouldn't match up the tokens to each other with out access to the original token14:55
bknudsonmorganfainberg: yes, because sha1 wouldn't be available14:55
morganfainbergbknudson, ...14:56
bknudsonmorganfainberg: but I thought you could use different methods for user IDs?14:56
morganfainbergbknudson, we were going to use non-configurable sha1 because uuid is bad, we need it to be reproducable14:56
morganfainbergbknudson, this isn't even secure data. this is simply a mechanism to create an ID.14:57
dstanekmorganfainberg: the requirements are that we need the ability is shrink a token into something that's not reversible (compliance), smaller in the logs and repeatable so they can match?14:57
morganfainbergi think the compliance stuff is overzealous.14:57
morganfainbergdstanek, yep14:57
bknudsonsure, but if there's no sha1 function then it won't work14:57
morganfainbergbknudson, by that token i think UUID can't be used.14:57
bknudsonit is overzealous14:58
morganfainbergbknudson, i think UUID is a sha1-based system across the board14:58
* morganfainberg is almost positive about that.14:58
dstanekmorganfainberg: what is the tolerance for tokens mapping back to the same thing? (same hash or whatever)14:58
bknudsonhttp://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_.28random.2914:59
morganfainbergdstanek, as long as you can look into the logs and see a given token (whatever form we use) was used for multiple requests.14:59
bknudsonlooks like uuid4 is random and not sha1, uuid5 is sha114:59
morganfainbergand the others are even worse.15:00
dstanekbknudson: yeah, only uuid5 is sha based15:00
bknudsonmorganfainberg: y, there's some crappy options in uuid!15:00
morganfainbergdstanek, and we don't want to let people take token-repr from logs back to token.15:01
dstanekmorganfainberg: that really sounds like a hash of some sort15:01
*** jaosorior has quit IRC15:02
dstaneki can't think of another way to do it right now15:02
dstanekunless you maintain a lookup table :-P15:02
morganfainbergdstanek, oh god no15:02
morganfainbergdstanek, also not really doable15:02
dstanekhaha15:02
bknudsonI think that was essentially the idea of the tracking id in the token.15:03
dstanekcan we pull data from the token and use that instead? user_id and roles maybe?15:03
morganfainbergdstanek, maybe we just do token_str = token_id[:10] + token_id[-10:]15:03
morganfainbergdstanek, we aren't decoding the token atm15:03
*** ayoung_ZZZzzz is now known as ayoung15:03
bknudsonmorganfainberg: I like the idea of taking part of the token... that's how I look for it anyways.15:03
morganfainbergif we were, i'd just say: put tracking_id in token15:03
ayoungmorganfainberg, yes, we treat it as an opaque blob, and we treat it as a symmetric secret.  We can;t have it both ways15:04
morganfainbergbknudson, yeah its crummy though because we use uuid tokens and pki15:04
morganfainbergbknudson, if it was only pki, i'd have less issue with it.15:04
bknudsony, just need to make sure we don't take too much15:04
morganfainbergbknudson, so 20 bytes?15:05
morganfainbergayoung, i know ... *grumbles*15:05
ayoungmorganfainberg, but, we don't need to rip apart the token when it is requested15:05
bknudsonI would think 6 chars is enough, that's what git uses for short hash15:05
morganfainbergayoung, what we're tyring to solve is actually that.15:05
ayoungmorganfainberg, the response has the body of the token in its expanded form15:05
morganfainbergayoung, this is the curl-like log line in debug mode that has X-AUTH-TOKEN in it15:05
ayounghttp://docs.openstack.org/developer/keystone/api_curl_examples.html  morganfainberg that is v2, but v3 is comparable15:05
ayounglook at the example response15:06
ayoungand everywhere that is using the token has validated it, so they have it in unpacked form as well.15:06
dstaneki would think we would need it longer than 6 because the the number of tokens we have and the chances for collision15:06
bknudsondstanek: 7?15:06
morganfainbergayoung, we're not capturing any of that i need to go retrofit the whole auth-plugin model in the client to do that.15:07
morganfainbergayoung, i was hoping for something relatively small. thats all.15:07
*** dims_ has quit IRC15:07
marekddstanek: https://review.openstack.org/#/c/99704/5/keystoneclient/contrib/auth/v3/saml2.py regarding your comment from line 515: i am not creating any secial usecase where project and domain ids are required so I think there should always be only one of them, right?15:08
morganfainbergayoung, don't worry about it. i'll figure something out here.15:08
ayoungmorganfainberg, I'm not worried.  I'm right.15:08
ayoung:)15:08
morganfainbergayoung, no15:09
dstanekbknudson: was never good with statistics :-(15:09
ayoungdstanek, 103% of people aren';t15:09
morganfainbergayoung, you're pointing out something i know that i want to avoid mucking with that much code for a stupid logline / that much overhead15:09
bknudsonalso seems like shaing long string is more work than extracting some bytes15:09
ayoungmorganfainberg, no...its more than that15:09
ayoungit is a need to support the audit infrastructure15:09
ayoungand, I think, it shows a missing piece of the token architecture15:10
morganfainbergayoung, however we solve this can be used there15:10
ayoungI don't think it needs to be horribly invasive to do that, either.15:10
*** afazekas_ has quit IRC15:10
morganfainbergayoung, but i'm not advocating not getting there, i'm trying to solve this iteratively w/o needing to muck with a ton of pieces for a "lets make log lines less sucky"15:11
ayoungmorganfainberg, whne you said "auth plugin" you mean the client auth plugin, right?15:11
dstanekmorganfainberg: what is the tolerance for tokens "hashing" to the same value as other tokens?15:11
morganfainbergayoung, yes15:11
bknudsonif a client is passed a token it will also have to be passed the tracking id15:11
ayoungok...let me look15:11
morganfainbergayoung, we just aren't capturing it. it's easy enough to add.15:11
ayoungmorganfainberg, and how does that tie in with logging?15:11
bknudsonor the client will have to go to keystone to get the tracking id15:11
morganfainbergayoung, i just didn't want to muck with this part *yet*15:11
ayoungheh15:12
morganfainbergayoung, this is the curl debug lines that shouldn't leak the token data.15:12
dstanekmarekd: that's what i'm trying to figure out15:12
morganfainbergbknudson, lets not do that :P15:12
marekddstanek: so i think no.15:12
ayoungmorganfainberg, so we need to not log the token header, ever15:12
ayoungand your point is that then we need to log outside of curl?15:13
morganfainbergayoung, nope15:13
dstanekmarekd: in my mind if the object should only ever have one of those set then checking in the __init__ makes it obvious15:13
marekddstanek: ok15:13
morganfainbergayoung, we need to redact this but let us still know X token (not usable) was used across multiple requests.15:13
marekdgonna change it.15:13
morganfainbergayoung, the unique id is the right answer... it's just more work than i wanted to fix the logline.15:14
dstanekmorganfainberg: my biggest concern of using token[:7] would be the possibility of collision15:14
morganfainbergdstanek, yeah not going to do that15:14
morganfainberggoing to just make sure we capture the unique id properly15:14
hrybackiayoung: that code review didn't connect the dots15:14
ayoungmorganfainberg, so...since there is sensitive data in the Headers, we can't just turn logging over to curl.  We need to intercept the process.  However, right now, the context of the token body is thrown away after the token is fecthed by the client.  To log anything internal to the token body would require holding on to it,15:14
dstanekmorganfainberg: so you couldn't use that to legally say this person did some action15:14
ayoungor at least, holding on to that piece of data, and linking it to the token in use,  right?15:14
ayoungHave I stated the problem clearly?15:14
morganfainbergayoung, correct.15:15
morganfainbergayoung, well. sortof15:15
ayoungmorganfainberg, OK.  So your goal has ben to provide a logging mechanism that works with just the blob15:15
morganfainbergayoung, but close enough15:15
morganfainbergayoung, nah. we have all the data we need15:15
ayoungbut that can connect which token is used across multiple services15:15
ayoungand thus must be reproducible.  But not give away the token itself15:15
morganfainbergayoung, it just is going to take a bit of work for the session object (not a ton)15:15
morganfainbergayoung, i'm letting the "just use the blob" sail. we'll make it the unique id - its there, it just needs to be made available. you are eitherlogging from auth_token (explodes out the token) or you're logging based upon an auth_request that you made and received a token back for15:16
ayoungmorganfainberg, so we are now in violent agreement?15:17
morganfainbergin the latter case,w e just need to pull the unique_id out of the token_data returned from keystone [it's fine]15:17
ayoungand you are just annoyed because what you thought was going to be a simple fix is a lot more invasive?15:17
morganfainbergayoung, yeah, i was just hoping for a short answer now, and the longer answer later on this cycle15:17
ayoungmorganfainberg, Keystone IPA.  Identity.  Policy.  Audit15:17
morganfainbergayoung, yep because i need to replicate the long answer around a bunch of the client code.15:17
ayoungcool.  I know that you are on it.  Let me know if you want any help.15:18
morganfainbergayoung, client code != ksc, i mean other clients not using session obj15:18
morganfainbergayoung, yeah i'll tag you on the reviews :P15:18
morganfainberg;)15:18
ayoungmorganfainberg, I think we need to make the tracking number an official API change.15:18
morganfainbergayoung, part of the token data spec.15:19
ayoungand retroactive to the V2 api.  And if we get a v2 token without a tracking number, we will be in the same boat, but we have an answer of "cannot be tracked"  or something15:19
ayoung++15:19
morganfainbergayoung, i'm going to make the debug line just say X-AUTH-TOKEN: **REDACTED** and just log the tracking id as a separate part of that same thing15:20
ayoung++15:20
morganfainbergayoung, and the unique_id (just like the token version) will be a top level object - if the token doesn't have a unique id, sorry we don't know what to do for ya15:21
morganfainbergso, you can't see it.15:21
morganfainbergno tracking id = no tracking (icehouse and older keystones)15:21
dstanekis tracking id inside the token?15:27
morganfainbergdstanek, it will be15:27
morganfainbergdstanek, i'll just use a uuid4 in the token itself *i guess*15:28
dstanekdoes that mean that we could slow down things by having to decode the token everytime it's logged?15:29
morganfainbergdstanek, na15:29
morganfainbergdstanek, i just need to grab the token_id from the keystone body response15:29
morganfainbergdstanek, not actually decode.15:29
dstanekoh, i thought you were talking about other services logging the token too15:30
dstanekmorganfainberg: re: the recent mailing list discussion15:30
morganfainbergauth_token and clients are what we care about15:30
morganfainbergyah this is the client code and the middleware15:30
morganfainbergother services all use client code for debugging :)15:30
morganfainbergso, fix it in a couple places, fix it everywhere15:30
dstanekcool, i was under the impression that things were also logged in the services15:31
morganfainbergif they do, i can't stop them, but that is dumb and they shouldnt!15:32
*** dims_ has joined #openstack-keystone15:32
morganfainberg:)15:32
bknudsonthe auth_token middleware could extract the tracking id15:33
morganfainbergbknudson, yep. that one i'm not worried about15:34
bknudsonactually it would be in keystone.token_info15:34
bknudsonjust don't try to generate the tracking id from the token id15:35
*** BAKfr has quit IRC15:37
morganfainbergbknudson, yep15:37
*** packet has joined #openstack-keystone15:38
dstanekbknudson: question about https://review.openstack.org/#/c/99745/1/keystoneclient/__init__.py15:42
dstanekbknudson: why have the __all__?15:42
*** dims_ has quit IRC15:42
bknudsondstanek: http://legacy.python.org/dev/peps/pep-0008/#public-and-internal-interfaces15:43
bknudsondstanek: does that answer?15:43
*** dims_ has joined #openstack-keystone15:44
*** stevemar2 has joined #openstack-keystone15:44
bknudsonI wasn't thinking about whether to remove __all__ or not, since I don't really know what it does.15:44
bknudsonWas just getting the doc build to not generate warnings15:44
*** i159 has quit IRC15:44
stevemar2bknudson, the keystoneclient warnings?15:44
dstanekbknudson: hmmm...odd. __all__ is really for 'import *'15:45
*** stevemar has quit IRC15:45
dstanekfrom keystoneclient import * # import all things from __all__ instead of globals15:45
bknudsonstevemar2: (is this stevemar?) y, there were warnings for these doing tox -e docs15:45
bknudsondstanek: maybe it's a bug in the doc builder?15:45
stevemar2bknudson, yep, i was disconnected, now i am 2.0-ified.15:47
dstanekbknudson: no, the problem is that __all__ is advertising that is has those attributes and they are public15:47
stevemar2bknudson, I recall fixing a similar issue with the keystone docs, and the only way to get it working was to delete the block15:47
bknudsonstevemar2: delete __all__ ?15:47
dstanekwhat's interesting is that pep8 is a little confusing because it says modules should have an __all__ and doesn't say anything about packages15:48
stevemar2bknudson, yeah, let me find the change15:48
openstackgerritA change was merged to openstack/keystone: Fix a few typos in the shibboleth doc  https://review.openstack.org/10072315:48
stevemar2bknudson, oh https://review.openstack.org/#/c/72544/3/keystone/tests/contrib/kds/fixture/__init__.py15:49
stevemar2would that work?15:49
bknudsonstevemar2: it already had ''15:49
stevemar2gah15:49
bknudsonit was missing the imports instead15:49
* morganfainberg needs caffienation15:50
dstanekyeah, __all__ has to be a list of strings that are the names of globals in that module15:50
bknudsonin this case it would be like "__all__ = ['SqliteDb', 'KvsDb']" but then there was no "SqliteDb = sqlitedb.SqliteDb"15:51
dstanekthe right solution is to add the imports to get the names in globals or to delete the __all__15:51
bknudsondstanek: when do you use __all__ ?15:52
*** Ephur has joined #openstack-keystone15:53
bknudson"it's a list of public objects of that module -- it overrides the default of hiding everything that begins with an underscore" ?15:53
dstanekbknudson: i have never been in the habit of using it because i don't import *, but i'm not opposed to keeping it15:53
bknudsonlooks like you need it if you want to only make some symbols in the module "public"15:54
stevemar2bknudson, dstanek it seems like it's only used if we explicitly call import * ?15:54
bknudsoni.e., from p import *15:54
stevemar2bknudson, i think we're on the same page: http://stackoverflow.com/questions/44834/can-someone-explain-all-in-python15:55
bknudsonstackoverflow is the best15:55
stevemar2delete it and see if the tests pass :)15:55
bknudsonwe should have tests to ensure that all the public symbols are exported as expected15:55
bknudsondstanek: so we'd only need __all__ if we wanted some of those imports to not be public15:56
bknudsonor do imports work differently?15:56
dstanekbknudson: jas15:56
*** dims_ has quit IRC15:57
dstanekbknudson: http://dpaste.com/3P5NGCQ15:58
dstanekdefault with 'import *' is everyting in globals that isn't prefixed with _; __all__ gives you control to say only certain things are included so you don't need the _15:59
dstanekbknudson: people say __all__ documents a modules public API and i guess that's true to some extent15:59
bknudsondstanek: so is there an issue with the "import pbr.version" in __init__.py?15:59
*** gyee has joined #openstack-keystone16:00
bknudsonwouldn't we get a pbr in globals?16:00
bknudsonif someone did import * and we removed __all__16:00
dstanekno, without the __all__ it would be included in 'from keystoneclient import *'16:00
bknudsonwe don't want that16:00
bknudsonso I think we still need __all__ in __init__.py16:00
dstanekpeople are not import * right now because it's broken, but adding the imports would fix it16:01
*** leseb has quit IRC16:01
bknudsonreally? I didn't try it16:01
*** jsavak has joined #openstack-keystone16:01
*** leseb has joined #openstack-keystone16:01
dstaneki think you would get an attribute error16:02
dstanekmy general rule of thumb is not to 'import *' except in certain cases like Tk or testtools.matchers where the module was designed for it16:03
*** joesavak has quit IRC16:03
bknudsonI don't think we can tell people to not use from keystoneclient import * if they want to16:04
openstackgerritA change was merged to openstack/python-keystoneclient: auth_token _cache_get checks token expired  https://review.openstack.org/9678516:04
*** joesavak has joined #openstack-keystone16:04
dstaneki don't think we should16:04
mfischWhen using PKI tokens do the other services (nova, etc) need to be configured to handle them?16:05
*** leseb has quit IRC16:06
bknudsonmfisch: the other services use the auth_token middleware which supports both UUID and PKI tokens16:06
dolphmdoes logstash have a CLI?16:06
bknudsonno config required16:06
*** jsavak has quit IRC16:06
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/9907616:07
mfischbknudson: how do the services get the keystone cert?16:07
bknudsonmfisch: auth_token middleware fetches it from keystone16:07
dstanekbknudson: if you take out the __all__ nobody would do an import * anyway; there would be nothing to import16:07
*** dvorak has joined #openstack-keystone16:08
bknudsondstanek: ['baseclient', 'client', 'pbr', '__builtins__', 'v2_0', 'utils', 'discover', 'auth', '__package__', 'access', 'generic', 'session', 'v3', 'service_catalog', 'openstack', 'exceptions', '__name__', 'base', '__doc__', 'httpclient']16:08
bknudsonthat's what I get when I remove __all__ from 9974516:09
bknudsonglobals().keys()16:09
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083316:09
stevemar2dstanek, bknudson what about http://paste.openstack.org/show/84404/16:09
bknudsonvs ['__builtins__', '__package__', 'access', 'generic', 'v3', 'client', 'service_catalog', 'v2_0', 'exceptions', '__name__', '__doc__', 'httpclient']16:09
bknudsonstevemar2: ah, I thought apiclient was in oslo-incubator16:10
dstanekbknudson: that's interesting - i did not expect that16:10
stevemar2nope16:10
dstanekbknudson: is that with your imports in the file?16:10
bknudsonmight as well fix that one too, then16:10
bknudsondstanek: yes, that's with the imports16:11
dstanekbknudson: ah, that's why16:11
dstanekif you have the original file and remove the __all__ you'll get something different16:11
bknudson['__builtins__', '__name__', 'pbr', '__doc__', '__package__']16:11
bknudsondstanek: it's just pbr16:11
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/9626516:12
dstaneklike i said, i'm fine with the imports - i was just wondering why we had an __all__16:13
bknudsondstanek: I think it's right having the __all__, since don't want to export pbr16:13
dstanekbknudson: it's only not exported in the import * case16:13
dstanekif you import the package you can still access it as an attribute16:14
bknudsonfrom keystoneclient import pbr16:14
bknudson:(16:14
bknudsonalso, it serves as documentation16:15
bknudsonfor what's public and what's not16:15
bknudsonmaybe we could from pbr import version as _version?16:15
dstanekbknudson: probably not worth it - we are only talking about the main package now - what about all of the other modules?16:16
sbasamHow is token revocation handled in the PKI use case? Does each keystone server store the list interally to itself in kvs?16:16
marekddstanek: hey, looking at moving project_id/domain_id to __init__().16:16
bknudsondstanek: they should also use __all__ according to pep8. it's just that we didn't enforce it as we should have16:16
dstanekbknudson: what strange about __all__ is that it defines a module API and not a package API16:16
marekddstanek: in this use case the logic should be like: "if none is set, list all available projects and domains"16:17
mfischbknudson: thanks, sounds like it's a simple transition then16:17
bknudsonsbasam: keystone server searches the token table for revoked and not expired tokens if tokens are stored in sql16:17
marekddstanek: and this happens via HTTP calls to the Keystone. See lines 517,518 https://review.openstack.org/#/c/99704/5/keystoneclient/contrib/auth/v3/saml2.py16:17
marekddstanek: so I don't thnk it's a good idea to move it all to __init__16:18
*** chandan_kumar has joined #openstack-keystone16:18
bknudsondstanek: can you import * from a package?16:18
sbasambknudson: We don't want to store the token due to scaling issues with it. Is it possible to just stored revoked tokens in the DB?16:18
sbasamWe are currently using UUID tokens and looking to migrate to PKI due to storage issues with UUID tokens.16:19
bknudsonsbasam: there's other work going on in juno to make it so that tokens don't have to be stored16:19
dstanekbknudson: yes16:19
dstanekmarekd: that's unfortunate16:20
dstanekbknudson: but what i mean is that doesn't say that keystone.session is public or private when directly imported16:20
marekddstanek: you don't always know what project/domain you can access, since your rolles are assigned dynamically..16:20
bknudsondstanek: using __all__ in a package worked for me16:21
marekddstanek: and of course making the plugin caling keystone evertime an object is created is a nightmare :-)16:21
dstanekbknudson: is keystoneclient.session public?16:21
bknudsondstanek: I think so. it's got the keystone.session.request function which we supposedly support16:22
bknudsonsome things are public when they probably shouldn't be16:23
dstanekbknudson: that's what i mean - it's public and not in the __all__ - it's more from the module perspective than package16:24
bknudsondstanek: I think that's a bug16:25
dstanekyeah, that's why i've never used it :-( since there is no enforcement there is no way to know if it's up to date16:28
bknudsonthere must be a way to write a test for it16:28
*** bknudson has quit IRC16:30
*** leseb has joined #openstack-keystone16:32
*** leseb has quit IRC16:37
*** leseb has joined #openstack-keystone16:37
dstaneki think that was bknudson's mic drop16:41
lbragstaddstanek: +!16:43
lbragstad+1*16:44
*** ByteSore has quit IRC16:48
*** ByteSore has joined #openstack-keystone16:49
*** leseb has quit IRC16:50
*** leseb has joined #openstack-keystone16:50
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Scope unscoped saml2 tokens.  https://review.openstack.org/9970416:54
*** leseb has quit IRC16:54
*** browne has joined #openstack-keystone16:58
*** marekd is now known as marekd|away16:59
*** dims_ has joined #openstack-keystone16:59
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083317:03
*** harlowja_away is now known as harlowja17:06
openstackgerritMorgan Fainberg proposed a change to openstack/python-keystoneclient: Do not expose Token IDs in debug output  https://review.openstack.org/9943217:12
*** stevemar2 has quit IRC17:13
*** stevemar has joined #openstack-keystone17:14
*** hrybacki_ has joined #openstack-keystone17:15
*** thedodd has joined #openstack-keystone17:16
*** marcoemorais has joined #openstack-keystone17:17
*** praneshp has joined #openstack-keystone17:17
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083317:18
*** hrybacki has quit IRC17:18
henrynashayoung, dtsanek, morganfainberg: have posted first split out of the multi-backend uuid patch…the one that just migrates ID generation from controller to manager….hopefully pretty uncontenious, so great to push this along: https://review.openstack.org/#/c/100833/17:19
*** hrybacki_ has quit IRC17:20
morganfainberghenrynash, nice! thanks for splitting it up17:20
morganfainberghenrynash, i'll take a look at it here in a minute17:20
*** nsquare has joined #openstack-keystone17:20
henrynashmorganfainberg: thx….even thats was 680 lines!   Couln’t really see how to split it down further….and it is nearly all mechanical changes of the same form17:21
morganfainberghenrynash, yeah thats why breaking it up is so helpful17:26
morganfainberghenrynash, we can at least not be as overloaded on reviewing the code :)17:26
morganfainbergthis one should be easier to review in either case17:26
henrynashmorganfainberg: agreed!17:26
morganfainberghenrynash, also... miiiinor tweak to your sha1 bits17:27
morganfainberghenrynash, for the spec change17:27
morganfainbergwe can't use sha117:27
morganfainbergcompliance issues17:27
henrynashmorganfainberg: eeek!17:27
morganfainbergit either needs to be configurable or be sha2 based17:28
morganfainberg(sha224, 256, etc)17:28
henrynashmorganfainberg: and don’t they all generate more than 32 bytes (hex)?17:29
morganfainberg64 is our limit17:29
morganfainbergbut sha256 is 64 bytes17:29
morganfainbergto keep it 32 bytes or less... don't think we can use hashing17:29
morganfainbergw/o making it configurable17:29
morganfainberge.g. sha1, sha224, sha25617:29
henrynashI did wonder about allowing a plugable hash driver...17:30
*** bknudson has joined #openstack-keystone17:32
ayounghenrynash, > 400 lines...any way you can make is smaller17:34
ayoungjust kidding17:34
henrynashayoung: missile on its way....17:34
henrynashayoung: :-)17:35
*** bknudson has quit IRC17:36
ayounghttps://review.openstack.org/#/c/100833/7/keystone/identity/core.py,cm  I wonder if that is going to mess up the people currently using LDAP.17:38
ayoungIE.  cern, and the people that are using Rally tests that periodically create users, like that guy last night asked about17:38
henrynashayoung: calling the manager?17:39
ayounghenrynash, yeah...probably it is no real change17:39
ayoungI think the LDAP code injects a UUID in the CN or something wonky like that anyway17:39
henrynashayoung: if they call the driver itself, their fine17:40
ayoungyep17:40
ayounghenrynash, and for existing LDAP cases, they should just accept the userid presented by LDAP17:40
ayounghenrynash, just to be sure, I'll try this against liveLDAP17:41
henrynashayoung: I tried variou s ways of not changing the manager signature, but ‘cause we pass the ID as well as the object (that has to have the ID in it as well!)…it’s messy17:41
ayoungagreed17:41
*** hrybacki has joined #openstack-keystone17:41
ayounghenrynash, why the additional cleanup in the fixture code?  Shouldn';t we be going from a blank database when we run this?17:42
ayoung   # This will clear out any roles on the project as well17:42
ayoung                        self.assignment_api.delete_project(tenant['id'])17:42
henrynashayoung:…ahh, actually you’re right that’s not stricly needed in this patch….it is when we haev different public vs entity IDs cause some of tests re-create the fixture users…and you end up with additonla roles in projects since their Public IDs may have changed depending on what test we are running17:44
ayounghenrynash, so it is from the next patch?17:45
henrynashayoung: yes17:45
ayoungOK...17:45
henrynashayoung: sorry, slipped into this one by mistake...17:45
henrynashayoung: I’m a git add -i newbie!17:45
ayoungheh17:46
ayoungnot a big deal, just wasn't clear if it was intentional.  I know I make changes like that for development sake, and then end up leaving them in during the review17:46
henrynashayoung: I can pull that one out….once a few people have reviewed I’ll do a minor update17:47
ayoungcool.  I don;t really care17:47
ayoungtwas others that insisted on the patch splitting17:47
ayounghenrynash, why this code17:48
ayoung  password = self.user1['password']17:48
ayoung        self.user1 = self.identity_api.create_user(self.user1)17:48
ayoung        self.user1['password'] = password17:48
ayoungI see that pattern in a few places17:48
henrynashayoung: so often the user record was initialised with teh password in….which is NOT returned by the create, and the test will later refere to it from the object17:49
*** bknudson has joined #openstack-keystone17:49
*** dims_ has quit IRC17:53
ayoungah, the filter thing17:58
morganfainbergbknudson, dolphm, i think for the middleware split the answer is we just freeze the keystoneclient middleware and deprecate it (message that says go install new stuff from XXXX package)17:59
morganfainbergbknudson, dolphm, it save circular deps, breaking people, etc.17:59
bknudsonmorganfainberg: works for me17:59
morganfainbergbknudson, dolphm, and it's purely a deployer function on which one to use.  we can even say release YY of keystoneclient will remove this old middleware if we want18:00
bknudsonwe'll need to fix any security vulns in there18:00
morganfainbergbknudson, security maintenance != new features, totally agree18:00
morganfainbergbknudson, it means we might have code going into 2 places, but it should be minimal.18:00
ayounghenrynash, +2 from me18:00
morganfainbergbknudson, it also means we shouldn't refactor to use session (etc) the current one in keystoneclient18:00
*** jsavak has joined #openstack-keystone18:01
morganfainbergit also means the split is a much much easier proposal18:01
ayoungmorganfainberg, ARGH!@18:01
ayoungreally18:01
*** dims_ has joined #openstack-keystone18:01
morganfainbergayoung, i can't in good conscience make a circular dependency for packages.18:02
ayoungmorganfainberg, ok...lets delay that split we get the current one in a stable state18:02
ayoungand that means the refactoring and use of revocation events18:02
ayoungthen split18:02
morganfainbergayoung, negative, lets not do the massive refactor18:02
morganfainbergayoung, rev. events sure18:02
morganfainbergayoung, actually for juno it wont matter really18:03
morganfainbergayoung, but eh18:03
morganfainbergw/e ... if we delay i can work on otherthings18:04
*** joesavak has quit IRC18:04
bknudsonmaybe we'll figure out the circ dependency thing soon anyways18:04
*** packet has quit IRC18:05
morganfainbergbknudson, it isn't that pip can't do it, i was talking with some people in -infra about it18:05
morganfainbergits that ... i think it's not worth the headaches it will cause us.18:05
ayoungmorganfainberg, the events code needs the refactor18:06
morganfainbergayoung, alternatively we could do the split this week and make the 1st release of the new middleware refactor + events18:07
ayoungmorganfainberg, true18:07
morganfainbergayoung, defer to you on this i'm updating the spec now.18:07
ayoungthat might be better.  Then, revoke events only goes into the new code18:07
ayounglets talk it over with jamielennox when he's around18:07
morganfainbergayoung, ++ if you want the split this week though, i think i'll need to know middle of todayish18:08
ayoungmorganfainberg, dumb idea18:08
morganfainbergmiddle-to-late pacific18:08
bknudsonauth_token in keystoneclient is deprecated once middleware is released?18:08
ayoungwhat if we completely strip everything out of python-keystoneclient and put it in new libraries18:08
morganfainbergbknudson, correct that would be my goal.18:08
ayoungno circular dependencies18:09
ayoungkeystoneclient the library gets a new name18:09
morganfainbergayoung, that was my first thought. keystonelib?18:09
ayoungkeystonecommon?18:09
ayoungnah18:09
bknudsonisn't it just cms?18:09
morganfainbergwe could absolutely do that instead. but it's probably wont be an early juno thing18:09
morganfainbergbknudson, and session18:10
bknudsonwhat's the circular dependency with session?18:10
bknudsonsession doesn't use auth_token18:10
morganfainbergbknudson, we want auth_token to use session18:10
morganfainbergbknudson, its on the "lets refactor this correctly to use the new code" list18:10
bknudsondoesn't session use keystoneclient?18:11
ayoungeven without that I think we have a circular18:11
morganfainbergkeystoneclient uses session18:11
bknudsonI thought session used keystoneclient ... maybe it's the plugins18:13
morganfainbergsession is what the plugins are for18:13
morganfainbergit's something that other python-*client code can consume, if we were to split it the keystoneclient (interacting with keystone) would remain in the keystoneclient lib, but the common code (e.g. session + plugins, cms) would move out18:14
bknudsonaren't the plugins going to use keystoneclient?18:17
bknudsonthey need to talk to keystone, so seems like they should use keystoneclient for it.18:17
bknudsonalthough could do that with injected function18:18
morganfainbergi'd need to bug jamielennox to know for sure the grand plan18:18
bknudsonhttp://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/auth/identity/v3.py18:18
*** packet has joined #openstack-keystone18:19
bknudsonthe v3 auth plugin uses exceptions from keystoneclient18:19
bknudsonbut it doesn't use keystoneclient, uses session.post and builds the request itself.18:20
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create python-keystonemiddleware repo  https://review.openstack.org/9598718:26
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create python-keystonemiddleware repo  https://review.openstack.org/9598718:27
morganfainbergbknudson, yeah it is a little intertwined. i think it all depends on where we want the code to live. - it would be doable to split that out as well.18:28
bknudsonauth plugins18:28
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create python-keystonemiddleware repo  https://review.openstack.org/9598718:29
morganfainbergok now that i got all the extra whitespace out...18:29
ayoungmorganfainberg, OK...so the pieces as I see it are:  keystonecli_>dead, becomes common CLI.  session mgmt...candidate for the openstack-sdk project,   keystonelib  specific for calls to keystone,  keystone middleware.18:30
morganfainbergsession management could be openstack-sdk or oslo18:31
ayoungthe problem with the commons is that it means that a team working on something has to give it up, or a person has to transition over to it to supervise, and gets sucked in to thing beyond what they care about18:31
morganfainbergayoung, yeah basically that covers it18:31
ayoungI wish we could put something into common and keep oversight of it18:32
morganfainbergthat level of split will (i think) be beyond the scope of early juno18:32
morganfainbergfwiw18:32
morganfainbergor even possiblt juno at all.18:33
bknudsonthere's lots of different oslo libs that have different maintainers18:33
*** daneyon has quit IRC18:34
*** dims_ has quit IRC18:36
*** marcoemorais has quit IRC18:37
*** ayoung has quit IRC18:37
*** marcoemorais has joined #openstack-keystone18:37
*** gokrokv__ has quit IRC18:42
*** nkinder_ has quit IRC18:44
henrynashayoung: thx18:51
*** MEDOU has joined #openstack-keystone18:58
*** ozialien has joined #openstack-keystone18:59
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create python-keystonemiddleware repo  https://review.openstack.org/9598719:00
*** dims_ has joined #openstack-keystone19:00
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create python-keystonemiddleware repo  https://review.openstack.org/9598719:01
bknudsonmorganfainberg: what middleware is being pulled out of keystone? all of it?19:03
morganfainbergbknudson, ec2token19:03
morganfainbergbknudson, s3 already has been moved19:04
morganfainbergbknudson, and the other middleware is internal (authcontext19:04
morganfainbergjsonbody etc19:04
morganfainbergi mean.. we could split those out too19:04
* morganfainberg shrugs19:05
*** jsavak has quit IRC19:05
*** MEDOU has left #openstack-keystone19:06
*** openstackgerrit has quit IRC19:06
*** openstackgerrit_ has joined #openstack-keystone19:07
bknudsonmorganfainberg: seems like some of the middleware could be in oslo.19:08
bknudsonRequestBodySizeLimiter19:08
morganfainbergbknudson, possibly.19:08
*** openstackgerrit_ is now known as openstackgerrit19:08
morganfainbergbknudson, i'm happy to evaluate that but i'm hesitant to lump that into this spec19:08
*** dims_ has quit IRC19:09
*** joesavak has joined #openstack-keystone19:09
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083319:10
*** gokrokve has joined #openstack-keystone19:15
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083319:17
*** ozialien has quit IRC19:18
*** gokrokve has quit IRC19:20
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create python-keystonemiddleware repo  https://review.openstack.org/9598719:21
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Service Token Composite Authorization Specification  https://review.openstack.org/9631519:27
openstackgerritDavid Stanek proposed a change to openstack/keystone: Middleware tests now run under Python3  https://review.openstack.org/9966919:38
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds a fork of python-ldap for Py3 testing  https://review.openstack.org/9582719:38
openstackgerritDavid Stanek proposed a change to openstack/keystone: Updates Python3 requirements to match Python2  https://review.openstack.org/9582619:39
morganfainbergdstanek, i meant to ask you aout the LDAP fork19:39
morganfainbergdstanek, it's just someone trying to get the stuff into upstream python-ldap so we're using it and going to help champion it?19:40
dstanekmorganfainberg: it's much worse then that :-( jas19:41
morganfainbergdstanek, ok19:41
*** gokrokve has joined #openstack-keystone19:42
dstanekmorganfainberg: take a look at my post https://mail.python.org/pipermail/python-ldap/2014q2/thread.html19:42
dstanek...crickets...19:42
dstanekmorganfainberg: jdennis' response is very enlightening19:42
morganfainbergwow19:43
dstanekmorganfainberg: my goal is not to champion it, but to get as far as i can knowing that we can't really release until all of the i's are crossed and t's dotted19:43
morganfainbergyeh19:43
dstanekmorganfainberg: it may be that i'll jump in and help at some point once i've gone as far as i can go19:44
morganfainbergnod19:44
dstanekthere is also a python3 version (from different devs), but the API is different19:44
dstanekhttps://pypi.python.org/pypi/python3-ldap19:45
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create keystonemiddleware repo  https://review.openstack.org/9598719:49
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: create keystonemiddleware repo  https://review.openstack.org/9598719:49
jdennispython3-ldap looks interesting, but it relatively immature AFAICT, being pure Python has it's advantages but I wonder about performance and all the nasty ASN.1 which has to be spot on correct, then there is the face it's a different API :-(19:49
*** rodrigods has quit IRC19:51
*** diegows has joined #openstack-keystone19:53
bknudsondoes the wrapper in keystone make it easier? could it translate to/from python3-ldap?19:54
morganfainbergbknudson, interesting thought19:55
jdennisbknudson: if you're talking about the wrappers I introduced the answer is no, the wrappers are a 1-to-1 match on the existing python-ldap API19:56
*** rodrigods has joined #openstack-keystone19:59
openstackgerrithenry-nash proposed a change to openstack/keystone: Migrate ID generation for users/groups from controller to manager  https://review.openstack.org/10083320:02
*** leseb has joined #openstack-keystone20:02
dstaneki think it would be possible to write an adapter layer, but probably not worth the effort until more of the dust settles20:02
*** ayoung has joined #openstack-keystone20:08
*** wyllys has joined #openstack-keystone20:11
wyllysis it possible to add users in Active Directory using keystone with the LDAP backend?20:11
* morganfainberg grumbles valencia is not an approved hotel20:12
dstanekmorganfainberg: i think there is an embassy even closer to geekdom20:18
morganfainbergHilton looks to be the closest20:18
morganfainbergand the recommended "best choice" one20:19
dstanekdo you get a better rate there than the rackspace rate?20:19
morganfainbergno, but the system is being bitchy about letting me go outside of policy20:19
dstaneki'm not sure where the hilton is downtown20:20
morganfainberg200 South Alamo St.20:20
morganfainbergclaims to be 0.44 mi from geekdom20:20
*** stevemar has quit IRC20:20
morganfainbergthough i'm getting a car this time because i have to be at the airport early on saturday morning.20:21
morganfainbergand not staying at the same hotel as other folks20:21
*** gordc has left #openstack-keystone20:21
dstanekmorganfainberg: i think that's closer to the old geekdom20:21
dstanekbut if you have a car it won't matter20:22
morganfainbergyep20:22
morganfainbergthats the plan20:22
*** wyllys has quit IRC20:24
*** nkinder_ has joined #openstack-keystone20:27
morganfainbergbknudson, https://review.openstack.org/#/c/100497/ re hashing you seem to know the most about this.20:36
morganfainbergbknudson, before we get lost - i want to pre-emptively make sure we're not in violation with whatever is chosen.20:36
mfischdoes DELETE /v2.0/tokens/{token-id} require some config to make it work?'20:39
mfischlike a policy.json entry?20:39
openstackgerritRaildo Mascena de Sousa Filho proposed a change to openstack/keystone-specs: Hierarchical Multitenacy  https://review.openstack.org/10101720:42
*** topol has joined #openstack-keystone20:43
raildomorganfainberg: If you can review =]20:43
morganfainbergraildo, Awesome! was going to go looking for you tomorow on that actually20:44
raildomorganfainberg: great! thanks20:44
*** diegows has quit IRC20:44
openstackgerritayoung proposed a change to openstack/keystone: Kerberos as method name  https://review.openstack.org/9598920:50
*** nsquare has quit IRC20:51
ayoungWTF don't people stick around to hear the answer to their questions?20:51
ayoungraildo, I thought we were putting an explict param on to get thewhole hierarchy20:53
ayoungah..projects, not project20:53
ayoungraildo,  on Token must be scoped to the target project on which the action is performed. A higher-project scoping will not work.20:54
ayoungI think we need to be clearer that a user with a role on A should or should not be able to get a token scoped to B20:54
ayoungbased on whether the role is "inheritable"20:55
ayoungits implied in there, but should be explicit20:55
mfischit turns out DELETE tokens works if you use curl properly...20:55
*** dstanek is now known as dstanek_zzz20:55
raildoayoung: I understand, but which of the two solutions is the ideal? I think the token must be valid.20:57
ayoungraildo, no, I just mean make explicit what you have there20:58
ayoungif the role is inheritable, then you can get a token for the child project20:58
*** hrybacki has quit IRC20:58
ayoungif it is not, you need an explicit role20:58
ayoungraildo, also, what do you think of this20:58
raildoayoung: ok20:58
ayoungmerge the domain and project tables and then domain_id become parent_id20:59
ayounga domain is an entry with no parent20:59
*** erecio has quit IRC20:59
sbasammfisch: Did you have to do that using an admin role?  Default policy.json seems to require an admin role21:00
raildoayoung: I remember this discussion, I think dolph until he had suggested it. In my opinion it is a good idea.21:01
mfischsbasam: I was failing to properly add the Auth-Token to my curl request ;)21:01
ayoungraildo, I'll add that to the review21:01
raildook, thanks21:02
ayoungnice work21:02
*** juanmo has quit IRC21:02
raildoayoung: thank you21:02
morganfainbergraildo, i agree with using domain_id as the top level21:03
morganfainbergerm domain21:03
morganfainbergok i am going to go get some food, coffee, etc be back in a bit21:04
*** dims_ has joined #openstack-keystone21:06
raildomorganfainberg: ayoung I was with two questions about the solution. When a user wants to delete a project that is in the middle of the hierarchy, you must delete the rest of the hierarchy, or throw an exception (the user only to delete the leaves)?21:06
raildoThe other question is, can I add/change projects in the middle of the hierarchy?21:07
morganfainbergi think we agreed that moving projects was a big issue21:07
morganfainberg(e.g. adding/removing from the heiarchy)21:07
morganfainbergchanging a project's info (ID is imuutable) shouldn't matter21:07
*** jamielennox is now known as jamielennox|away21:08
openstackgerritA change was merged to openstack/keystone: Update sample keystone.conf file  https://review.openstack.org/10015521:08
raildoThis is a good argument.21:08
raildoI'll have to leave now, but in half an hour I'm back to fix these points. =]21:08
morganfainbergsure.21:09
morganfainbergthanks for the work on that!21:09
ayoungraildo, great question.  I think it would be an explicit "delete all" and would require a specific role21:09
ayoungadd in the middle..no, only leaf nodes21:09
raildomorganfainberg: It's nothing! =]21:09
ayoungchange?  no moving21:09
raildoayoung:  I was thinking about moving.21:10
sbasamquestion on pki token revocations in a multi node keystone service... Is the revocation list shared between nodes or is each keystone server holds the list that it handled?21:10
*** topol has quit IRC21:10
*** raildo has left #openstack-keystone21:10
bknudsonsbasam: if the token backend is shared then they're shared... you can share with memcache and sql21:11
sbasambknudson: thanks.21:12
ayoungsbasam, good question21:16
*** henrynash has quit IRC21:17
*** diegows has joined #openstack-keystone21:18
*** dims_ has quit IRC21:20
*** dims_ has joined #openstack-keystone21:21
*** dims_ has quit IRC21:26
*** henrynash has joined #openstack-keystone21:28
*** packet has quit IRC21:38
*** diegows has quit IRC21:40
*** nkinder_ has quit IRC21:47
*** andreaf has quit IRC21:48
*** nkinder_ has joined #openstack-keystone21:48
*** raildo_ has joined #openstack-keystone21:50
*** henrynash has quit IRC21:52
*** sbasam is now known as sbasamaway21:53
*** nkinder_ has quit IRC22:00
*** nkinder_ has joined #openstack-keystone22:01
*** dims_ has joined #openstack-keystone22:16
*** dims_ has quit IRC22:19
*** dims_ has joined #openstack-keystone22:20
*** thedodd has quit IRC22:29
*** leseb has quit IRC22:42
*** leseb has joined #openstack-keystone22:43
*** leseb has quit IRC22:47
*** leseb has joined #openstack-keystone22:50
*** raildo_ has quit IRC22:54
*** leseb has quit IRC22:55
*** ozialien has joined #openstack-keystone23:03
*** leseb has joined #openstack-keystone23:13
*** hrybacki has joined #openstack-keystone23:13
*** leseb has quit IRC23:14
*** leseb has joined #openstack-keystone23:15
*** dims_ has quit IRC23:17
*** jamielennox|away is now known as jamielennox23:19
*** leseb has quit IRC23:19
*** joesavak has quit IRC23:19
*** yfujioka has joined #openstack-keystone23:49
hrybackilooking through tempest logs on Gerrit and all I can think about is how much space these things must take up given all of the changes that exist...23:52
*** dims_ has joined #openstack-keystone23:56

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