Wednesday, 2014-03-05

*** achampion has joined #openstack-keystone00:09
*** nkinder has quit IRC00:12
*** richm has quit IRC00:12
topolayoung,  I got 10 to 1 odds that your patch wouldnt make it. Looks like my bookie is gonna take my thumbs :-)00:25
*** krsna has quit IRC00:27
*** browne has left #openstack-keystone00:30
morganfainbergayoung, +2 with a comment that we should say it is expirimental in the docs00:35
morganfainbergayoung, and get it really solid and lots of drive time for Juno00:36
morganfainberg..WARNING:: This extension is experimental, and will continue to see improvement over the next development cycle.00:37
morganfainbergor some such00:37
*** topol has quit IRC00:38
*** arborism is now known as amcrn00:40
*** henrynash has quit IRC00:41
*** derek_c has quit IRC00:46
*** stevemar has quit IRC00:51
*** lbragstad has joined #openstack-keystone00:52
ayoungmorganfainberg, Deal00:57
gyeeso we are going with experimental?00:58
gyeetopol, pay up!00:58
morganfainbergayoung, i really expect a lot of things to change as we spend time working with the revocation events01:01
morganfainbergayoung, both w/ revocation code and with the stuff that is associated to it / interacts with it01:01
ayoungmorganfainberg, dolphm  I'll ad that and hit the approve button?01:02
morganfainberghm. maybe "over the Juno development cycle"?01:02
morganfainbergayoung, also make that a separate review. but yeah +A is good if jenkins is happy w/ it (though you should wait for to land01:03
morganfainbergor rebase on it.01:03
ayoungwhat do we have in the queue right now...01:04
morganfainbergayoung, nothing except a stable/havana fix01:04
morganfainbergayoung, once 78030 passes check, it'll move to gate01:05
morganfainberggate is 54 deep01:05
ayoungmorganfainberg, OK.  I'll let mine wait.  No reason to have too much churn.01:05
morganfainbergbut only the sqlalchemy stable/havana fix01:05
ayoung'salright.  Just processing01:05
morganfainbergbut yeah add the expirimental as a new patch based on yours, that way nothing is needed to accept both. :)  easier / less churn on that massive patch01:06
morganfainbergcoffee time01:07
*** dstanek has joined #openstack-keystone01:08
*** ChanServ sets mode: +v dstanek01:08
*** wchrisj has quit IRC01:11
*** rwsu has quit IRC01:29
*** gokrokve_ has quit IRC01:30
*** harlowja has quit IRC01:31
ayoungmorganfainberg, if we have nothing else in the stack that is making config changes, I should be able to push the button, no>01:33
*** derek_c has joined #openstack-keystone01:33
*** nkinder has joined #openstack-keystone01:36
*** wchrisj has joined #openstack-keystone01:37
morganfainbergayoung, well if you press go and isn't in the gate qeueue it'll fail pep801:38
ayoungOK...I can certainly wait on that01:38
morganfainbergayoung, that one should finish in a minute or so01:38
ayoungmorganfainberg, that FAILURE on Python33 gives me a little startle every time01:42
ayoungmorganfainberg, its failing before our code even gets touched01:43
ayoung  File "/opt/stack/keystone/.tox/py33/build/eventlet/", line 301:44
morganfainbergexecpt exception, e01:44
morganfainbergnot valid in py3301:44
morganfainbergneeds to be "as e"01:44
ayoungis there a python33 eventlet fix yet?01:44
ayounghow would one go about fixing this thing?01:45
dstanekayoung: i'm pretty happy with the changes in the token extension - is the plan to fix the things that dolphm mentioned or proceed and fix in a later patch?01:45
ayoungwe would need to get eventlet from somewhere other than upstream01:45
ayoungdstanek, later patch01:45
ayoungtreat those as bugs for rc101:46
ayounghe and morganfainberg are willing to +2 it and we can get it merged and then move on01:46
*** devlaps1 has quit IRC01:56
*** marcoemorais has quit IRC01:57
*** topol has joined #openstack-keystone02:04
*** wchrisj has quit IRC02:11
jamielennoxhow do we get the openstackgerrit bot to show up in here?02:12
jamielennoxXXX proposed a change to XXX - it's spammy but useful02:14
*** gokrokve has joined #openstack-keystone02:16
*** harlowja has joined #openstack-keystone02:17
*** wchrisj has joined #openstack-keystone02:31
*** amcrn has quit IRC02:35
*** gokrokve has quit IRC02:35
*** wchrisj__ has joined #openstack-keystone02:37
*** wchrisj has quit IRC02:37
morganfainbergjamielennox, i'll propose it to infra if you want02:38
morganfainbergit's easy02:38
*** wchrisj__ has quit IRC02:41
*** derek_c has quit IRC02:41
*** derek_c has joined #openstack-keystone02:42
*** derek_c has quit IRC02:53
jamielennoxmorganfainberg: huh, cool thanks03:03
jamielennoxi assumed itd be an infra thing i just haven't done much with infraconfig03:04
bknudsonmorganfainberg: could do identity-api, too03:04
morganfainbergbknudson, ah sure i'll add that03:05
*** gokrokve has joined #openstack-keystone03:05
morganfainbergbknudson, added03:06
gyeemorganfainberg, I am trying to following the increasing user ID size thread, but having trouble understand the reasons behind it03:09
gyeewhy do we need to map users IDs?03:10
*** derek_c has joined #openstack-keystone03:12
morganfainberggyee, it's about ensuring that user_ids are unique across multiple backends03:13
morganfainberggyee, initially we were going to use user_id@@domain_id03:13
*** harlowja is now known as harlowja_away03:13
morganfainbergand varchar(255) is more friendly to a ton of data.03:13
gyeeis there a standard across OpenStack on the IDs?03:13
morganfainberggyee, we define it... we're the idp03:13
gyeeI can't tell by reading the thread03:13
morganfainberggyee, but we have defined our schema as 64 varchar03:14
gyeeI mean IDs in general03:14
morganfainbergand by and large we're only sending 32 bytes (uuid()03:14
morganfainberggyee, so everyone (except one place i nova) uses a varchar(64)03:14
morganfainberggyee, the standard on the type of data is a "string of <=64 characters"03:14
gyeeare we defining a new ID data type across OpenStack?03:14
morganfainberggyee, ideally we should be more picky about what we send as the user_id03:15
morganfainberggyee, i would like everything to be uuids but there are concerns about having to maintain a map for LDAP federated, etc03:15
gyeemorganfainberg, no need for map03:15
gyeefor LDAP and federation, users are managed outside of Keystone03:15
morganfainberggyee this is for assignment purposes03:16
morganfainbergif we take a DN of "cn=gyee,dc=hp,dc=com"03:16
morganfainbergand we turn that into an id03:16
morganfainbergwe get "gyee" today03:16
gyeemorganfainberg, nope03:16
gyeethat should be done dynamically03:16
morganfainbergwhen we map a role, the user_id is gyee03:16
gyeemap user to a group template after auth03:16
morganfainbergso in the grant table, it's gyee, <project_id>, has <role_id>03:17
gyeedo not allow direct role assignments or life will be miserable03:17
morganfainbergwe already allow it03:17
morganfainbergcan't really take it away03:17
gyeeI am saying do not support that use case for LDAP and Federation03:17
gyeeno customers that we've interact with have this requirement03:17
morganfainbergwell we can't take it away from LDAP we support it03:17
morganfainbergiirc CERN uses this03:17
morganfainbergamong a few other deployments03:18
gyeeCERN uses direct role assignment?!!!!03:18
gyeeoh god bless them03:18
morganfainbergi wasn't 100% clear on it03:18
morganfainbergbut i know places use direct role assignments w/ LDAP identity03:18
morganfainbergwe can't take it away03:18
gyeewhen interacting wit LDAP and Federations, customers just want their existing users to use OpenStack03:18
gyeethey don't want Keystone to manage their users03:19
morganfainbergsure, but id != assignment03:19
gyeeI am saying no need for assignment03:19
morganfainbergeven if we use groups in keystone, mapping users to those groups (what if ldap doesn't provide the group arrangement you want) needs an ID03:19
morganfainberggyee, if we didn't need to break support for something we already have i'd be on board with that03:19
gyeeall IdP supports groups03:20
morganfainbergbut since we support all of this, we need to uniquely identify users03:20
morganfainbergif you have multiple users with the same ID derivation bits03:20
morganfainberg(e.g. cn=gyee)03:20
morganfainbergor even group=hp_admin03:20
gyeecn=gyee is not an LDAP DN03:20
gyeeDN = distinguished name03:21
gyeeDN, by definition, is globally unique03:21
morganfainbergsure but that doesn't stop someone from doing something dumb and configuring ldap1 and ldap2 with the same data03:21
morganfainbergas seprate idenetity sources03:21
gyeemorganfainberg, not within an enterprise03:21
morganfainbergkeystone needs to protect against that.03:21
morganfainberggyee, it is far different from "what should be done" and "omg i did this and it's broken"03:22
morganfainberggyee, the latter is bad news for us. so we should prevent it from happening03:22
morganfainberggyee we don't trust external idps to be globally unique03:22
morganfainbergeven if they are supposed to be03:22
morganfainbergwhat stops someone from doing something malicious to get access to your account03:23
morganfainbergso we use our internal domain_id as part of the user_id.  something we control03:23
morganfainbergit's really not expensive to do so03:23
morganfainbergwe have 64 bytes of storage03:23
morganfainbergand it guarantees we can avoid cross-idp exploits / confusion of users / etc03:24
gyeemorganfainberg, if we do this right, there's no need to maintaining user IDs in Keystone for external users03:24
morganfainbergthink of it from interoperable clouds, maybe hp is providing id to a cloud operated by rax.03:24
gyeemorgainfainberg, the only reason HP needs the ID is for tracking03:24
gyeebilling, anti-fraud, etc03:25
morganfainbergand does it hurt us to provide good data back for that?03:25
gyeeI don't think other OpenStack services needs the user ID03:25
morganfainberguser_quotas in heat/nova/etc03:25
gyeemorganfainberg, tracking is outside of Keystone03:26
morganfainbergaudit in nova03:26
morganfainbergneeds user_id03:26
gyeefor tracking, it is at the discretion of the deployer03:26
morganfainberggyee, if we accept multiple sources providing ID to keystone, we need to uniquely map them to the domains03:26
gyeemorganfainberg, we can03:26
morganfainberggyee, ok and as it stands there is no option for the deployer to easily do that03:26
gyeefor LDAP, if DN=gyee,ou=engineering,dc=hp,dc=com03:27
gyeeyou can easily map "dc=hp,dc=com" to the "hp" domain03:27
gyeethose can be done dynamically03:27
morganfainberggyee, well #1, that isn't websafe, so uuencode it03:28
morganfainberggyee (that's easy)03:28
gyeewhy are we worry about urlsafe?03:28
morganfainberggyee, 2 what if you have a cloud with external id provided by two companies.  what if company B reconfigures their ldap server to serve up the _same_ id03:28
gyeeDN will never be part of the request03:29
morganfainbergwe allow queries based on user_id to the rest api03:29
morganfainbergfor sanity sake, lets just assume we make ids safe for people to use.03:29
morganfainbergi don't want to argue that point, it's a noop or minimal overhead03:29
gyeethat's what I was saying at the beginning, for 3rd party integration, no one will call Keystone's lookup user03:30
gyeeKeystone is strictly for authentication03:30
gyeeusers are managed outside of Keystone :)03:30
gyeeso don't worry about lookup03:30
morganfainberggyee, /users/{user_id}/roles03:30
morganfainbergit's an assignment call03:30
lbragstaddstanek: if you want to add me to the initial hacking review you can03:30
morganfainbergnot an identity call03:30
gyeemorganfainberg, nope03:30
morganfainbergyes it is.03:31
gyeemorganfainberg, /groups/group_id/roles yes03:31
gyeebut not users03:31
morganfainbergi'm looking at the routers03:31
morganfainbergit's there03:31
morganfainbergcurrent master03:31
gyeeit is there, but not a good use case03:32
morganfainbergbut we need to support it03:32
gyeefor LDAP and Federation, we have to do it right at the system level03:32
morganfainbergok so we can't trust that the LDAP server isn't being malicious if it's not managed by us03:32
morganfainbergif we have to provide an id, we should include enough data to make it 100% unique03:33
gyeemorganfainberg, that's up to the deployers03:33
gyeeID ain't gonna help if you don't trust LDAP03:33
morganfainbergso if i deploy a cloud and customer says i want ldap server 2 and ldapserver 1 to be separate domains03:33
morganfainbergbut they provide the same dc=blah,dc=com03:33
morganfainbergi have to tell them "sorry can't work"03:34
gyeemoranfainberg, not a chance03:34
morganfainberggyee, i don't get to control the LDAP servers03:34
morganfainbergwhat if someone reconfigures one to provide bad data?03:34
morganfainbergwhy are you against being defensive on this front03:34
morganfainbergand making it so we can't run into an issue due to it03:35
gyeemorganfainberg, we can defense against stupidity :)03:35
gyeewe can't03:35
morganfainberganother use case03:35
morganfainbergtrusts encode user_ids03:35
gyeewe need to extend trust for groups, not individual users03:36
morganfainberggyee, that is API incompatible03:36
morganfainberggyee, we already support user trusts03:36
morganfainberggyee, we can't take it away03:36
gyeenot taking it away03:37
morganfainbergand heat uses trusts _a lot_03:37
morganfainbergagain, i don't trust sources of id keystone doesn't control03:37
gyeefor 3rd integration, everything needs to be done by groups03:37
gyee3rd party03:37
morganfainbergsince we don't want to control it03:37
morganfainbergwe just make sure it's easy to not worry about people doing something dumb03:37
morganfainbergdeployers will do something dumb, i don't see why we shouldn't ensure we're guarding against that. vs failing in odd/strange/bad ways03:38
gyeemorganfainberg, maintaining two parallel identity system is a huge overhead that we can avoid03:38
morganfainberggyee, so you're saying don't support multiple id sources?03:38
morganfainbergno multiple ldap servers?03:38
morganfainbergsince id source for keystone03:39
gyeemorganfainberg, we can easily support multiple ID sources, purely by dynamic mapping03:39
morganfainbergok so how do we solve dynamic mapping?03:39
gyeefor LDAP, map partial DN to domain03:40
morganfainbergok for federation03:40
morganfainbergi'll stop arguing ldap (except that we don't store the whole DN, we store a very small bit right now)03:41
gyeesay two users, user1 with DN cn=gyee,ou=engineering,dc=hp,dc=com, and user 2 with DN cn=morganfainberg,ou=engineering,o=metacloud.com03:41
gyeeyou can have a rule that maps "dc=hp,dc=com" to the "hp" domain, map "ou=engineering,dc=hp,dc=com" to the "engineering" project03:41
gyeeyou can have a rule that maps "" to the "metacloud" domain03:42
*** chandan_kumar has joined #openstack-keystone03:42
gyeesome for federation, domain map to combination of attributes03:42
morganfainberggyee, you can't control federation servers or prevent them from sending the same exact informaiton for two users03:43
morganfainberggyee, we get what is in the assertion (SAML)03:43
gyeemorganfainberg, with federation, we deal with attributes/assertions03:43
gyeehow we map them is entirely up to us03:43
morganfainberggyee, ok so we map with something to derive ID and the domain03:43
gyeean identity is a set of attributes/assertions03:43
morganfainberggreat easy to lookup the domain03:44
gyeeif they are they same, then by definition it is the same identity03:44
morganfainberggyee, unless someone is doing something malicious. lets be secure about it03:44
morganfainbergback to your ldap server cn=morganfainberg,ou=admin,ou=special users,ou=contractor,ou=engineering,'03:44
gyeemorganfainberg, security is process, software is a tool03:44
morganfainbergnot an unreasonable DN03:44
gyeesecure design != secure implementation03:44
morganfainbergbut not really unreasonable03:45
gyeesecure implemenation != secure deployment03:45
morganfainbergif you store that ID outside of keystone03:45
morganfainberg64 characters03:45
morganfainbergyou end up at ou=en03:45
gyeewe are merely providing a piece of functionality to allow customers to implement their business process03:45
morganfainbergthat leaves ambigious matching03:45
morganfainbergvs. taking some unique element from the DN and the domain id (unique because keystone controls it)03:46
morganfainbergand use that to uniquely identify the suer03:46
*** chandan_kumar has quit IRC03:46
morganfainberggyee, sure. but if we lack security in our tools03:46
gyeemorganfainberg, I am saying we don't need any user ID03:47
morganfainberggyee, except... we do.03:47
morganfainberggyee, it's how we identify users, audit, etc etc03:47
*** wchrisj has joined #openstack-keystone03:47
gyeeyou have the user name and you have the domain map03:47
morganfainbergand internal to keystone how we handle grants, trusts03:47
gyeethose two pieces of information is all you need03:48
morganfainberggyee, sure, and given the name alone in cases how do tyou know the domain03:48
morganfainbergright now, the implementation says we have the name only03:48
gyeedomain is on the token data03:49
gyeein the token data03:49
*** wchrisj has quit IRC03:49
morganfainbergso, demand everyone store domain now too03:49
gyeeno, who uses user ID besides Keystone03:49
morganfainbergnova, heat, uhm ceilometer, cinder03:49
morganfainbergi'm sure others03:50
gyeenova uses user_id?03:50
morganfainbergthey provide user quotas03:50
morganfainbergin fact, they should only ever use user_id for anything that references the user03:50
morganfainbergthey shouldn't care what the user's name is. or domain03:50
morganfainbergthat is a keystone construct03:50
*** stevemar has joined #openstack-keystone03:50
*** ChanServ sets mode: +v stevemar03:50
morganfainberguser_id should be (and actually i think we say as much) be unique across the cloud03:51
gyeeyou have the url for the nova quota code?03:52
morganfainberglooking for the code that backs that, sec03:53
morganfainbergit's been a while since i poked at nova :P03:54
stevemarmorganfainberg, did it make it?03:55
stevemarmorganfainberg, did it landddd03:55
morganfainbergstevemar, hmm?03:55
gyeestevemar, yep, topol owns everybody beer!03:55
morganfainbergstevemar, not yet03:55
stevemaror was revoke revoked03:55
topolstevemar did you see my email03:55
morganfainbergbut it's approved03:55
stevemartopol, not yet, just turned on my laptop03:56
stevemaroh exciting times03:56
stevemarapproved by author!03:56
morganfainberggyee, ok i'm not seeing the code but i don't have my ide up i know they support user_quotas03:56
stevemartsk tsk03:56
morganfainbergstevemar, yeah it needed to wait for another patch to hit gate, told ayoung to +A when that happened03:56
topolayoung, I got 10 to 1 odds that your patch wouldnt make it. Looks like my bookie is gonna take my thumbs :-)03:56
gyeemorganfainberg, lemme do some more code diving03:57
*** david-lyle has joined #openstack-keystone03:57
morganfainbergthat one was needed first to be in gate pipeline03:57
ayoungtopol, you should know not to bet against me03:57
stevemarayoung, how could he resist with odds like that!03:57
morganfainberggyee, long and the short is, we can be defensive, and provide tools to prevent from malice (or bad deployments) from causing issues with crossed user_ids03:57
topolLike betting on the washington generals vs. the globetrotters... I thought they were due!!!03:58
topolstevemar the email I sent you is halarious03:58
stevemartopol, "He's spinning the ball on his finger! Just take it! Take it"03:59
gyeeI can't still put a -2 on it before jenkins right?03:59
gyeetopol, your luck may be changing03:59
morganfainberggyee, short of moving to a V4, which I think we could eliminate user_ids completely then (not sure if anyone would enjoy it, but doable), i think we need to be smart about how we handle user_ids and ensure that we can tell the domain a user is from based upon the "shared" id03:59
ayoungmorganfainberg, ++ audit is important04:00
morganfainberggyee, eh, i hope you require serious $$$ for that.04:00
topoloh gyee, oh dont pin that on me...04:00
morganfainberggyee, don't do it for cheap04:00
gyeetopol, show me the money!04:00
gyeestraight cash homie!04:00
topolayoung is trained with firearms... so no dice04:00
ayoungtopol, far more important is I know how to call in Indirect fire or an Airstrike04:01
ayoungwhy take out one person when you can take out a grid squar04:01
topolayoung, I used to work with a guy who was a sniper in the Korean Army.  Very nice guy.   You would never know it by looking at him04:02
topolgreat support tools builder04:02
ayoungWTF did a reverify put a patch back in the Check queue?  Did I miss a memo?04:02
gyeemorganfainberg, LDAP and federation have no concept of user_ids04:02
gyeeI think we can do better in Keystone04:03
gyeeanyway, time for dinner04:03
morganfainbergayoung, you can't succeed a gate w/o a recent check04:03
gyeeg'nite y'all04:03
ayoungbut it failed gate due to a bug04:03
*** gyee has quit IRC04:03
ayounghow recent is ....a forget it04:03
morganfainbergayoung, it's to mitigate gate churn because something like long +2/+2 item but doc bug04:03
morganfainbergso doc bug would force gate churn04:04
morganfainberg-2 from gate means you need a new +1 before it goes to gate04:04
ayoungfailed due to some tempest disagreement with cinder or something04:04
ayoungand back to check?04:04
morganfainbergyep. but it'll auto gate after check completes04:04
morganfainbergprovided check passes04:04
topolmorganfainberg, why a new +1? you cant just say reverify???04:05
morganfainbergtopol, jenkins needs a +1 to allow it in gate04:05
morganfainbergsince a gate failure erases the +1, gerrit / zuul can't know it was already good04:05
morganfainbergit only knows current score04:05
morganfainbergso recheck, check produces +1, now +1 verify means it can go to gate04:06
morganfainbergthe whole point is to prevent some stale code from making it's way into gate and causing gate churn04:06
topolmorganfainberg forgive my ignorance,  is this during a what used to be  a recheck or a reverfy???04:06
morganfainbergtopol, recheck is only for a +1 verify04:07
morganfainberga reverify issues what is equivalent to a "recheck" and if that passes, the previous functionality of "reverify"04:07
topoljenkins -1 correct?04:07
morganfainbergyou can technically recheck a -2 :P04:07
morganfainbergbut correct you would say recheck for a -104:07
morganfainbergyou woudl say reverify for -204:07
morganfainbergbut since there isn't a +1 verified, a "reverify" causes a check to run again before it tries to apply the +2 jenkins logic04:08
topolreverify was failure during merge. so now you have to do????04:08
morganfainbergtopol, "reverify" will work04:08
topol+1 then reverify??04:08
morganfainbergtopol, it just looks odd because jenkins automatically will try to +1, then try to gate it04:08
morganfainbergtopol, it happens aiutomatically04:09
morganfainbergno change in your workflow04:09
topoloh ok, so what changed???04:09
morganfainbergchange in what zuul does04:09
topolok good04:09
lbragstadtopol: I responded to your comments here:
morganfainbergbasically if there isn't a +1 that happened in the last 24 hours, approval (or any comment) will force a 'recheck no bug'04:09
* topol took dumbass brad long enough to learn the old workflow, glad it didnt change04:09
morganfainbergit's magic04:10
morganfainbergzuul just does it04:10
morganfainbergthis helps prevent issues like that doc bug, where the sphinx version is wrong04:10
morganfainbergfrom making it's way into gate, since some patch was +2 CR 2 months ago04:10
morganfainbergand some core approves it, not knowing the doc bug fix hasn't been merged04:11
morganfainbergthen you get 20 of these things failing in gate and doing constant resets making gate back up04:11
morganfainbergand each reset resets everything behind it, then fails and the chain continues for hours04:11
morganfainbergtopol, basically.. i makes some cases of approval / reverify take longer04:11
morganfainbergtopol, but it makes the gate less brittle04:11
morganfainbergtopol, and it doesn't change anyone's workflow04:12
* morganfainberg stops being wordy04:12
topolmorganfainberg, thanks for the clarification.04:13
topollbragstad, thanks for the response. I +1 the patch04:13
morganfainbergtopol, sorry if i wasn't clear initially. sometimes IRC makes that harder :P04:13
morganfainbergayoung, for the non-voting sample config change:
morganfainbergthat should at least warn us that sample is out of date on each/any check04:14
morganfainbergnext steps will to make it all publish via doc building (or similar)04:14
ayoungmorganfainberg, that is a direct copy of the new files, right?04:15
morganfainberg"direct copy"?04:15
ayoungis that new?04:16
morganfainbergyes new04:16
morganfainbergcreated for that review04:16
morganfainbergit is based on the file that is used to run unit tests04:16
morganfainbergbut specific for checking the config04:16
ayoungso...just cuz it passed their test, does it mean it could completely break out gate if it had a typo?04:17
morganfainbergit's configured as non-voting04:17
ayoungsez yoiu04:17
morganfainbergworst case, it would say failed like py3304:17
*** harlowja_away has quit IRC04:17
morganfainbergline 45404:17
morganfainbergto 45704:18
ayoungNo, I believe that is what the file says...just that I have no context for any of this04:18
morganfainbergsee where it says voting: false04:18
ayoungI mean, it looks right04:18
morganfainbergayoung, ah yeah04:18
morganfainbergayoung, zuul config stuff04:18
morganfainbergany check can be non-voting with that04:18
ayoungI'd prefer if there was a "lets test it out on a known good patch" part of the check04:18
ayoungif you don;t mind, lets hold off until the I3 stuff clears?04:19
morganfainbergayoung, not sure how you'd do an automatic test of a slave script04:19
ayoungrun it04:19
morganfainbergayoung, that wont clear tonight04:19
morganfainbergayoung, it'll go in long after revocation stuff04:19
ayoungnothing will clear tonight04:20
morganfainbergayoung, it's up for infra to review, that is there perogative to approve/not approve04:20
morganfainbergayoung, i think it'll hold till after i3 though04:20
morganfainbergayoung, based on other stuff :)04:20
ayoungyeah...lots to clear on the freeze date04:20
morganfainbergwhich reminds me...04:21
*** morganfainberg changes topic to "[ Icehouse RC blockers ][ Icehouse RC Target Date: March 27th, 2014 ]"04:22
topolwe have some???04:23
morganfainbergthings that didn't get fixed for I304:23
ayoungguess I need to find a way to sneak in compressed tokens04:24
ayoungah..but if it is a bug fix...I can add in a new config option, right?04:24
morganfainbergayoung, uhmmmmmmmmmmmmmmmm04:24
stevemartopol, a few bugs here and there04:24
ayoungnew token provider that makes use of compressed tokens04:24
morganfainbergayoung, errrr i think that is a tough sell.04:24
stevemarayoung, you just gotta keep pushing the envelope eh04:25
morganfainbergayoung, but i'd need to defer to ttx and dolphm on that one04:25
ayoungit will be off by default.  THe change needs to go into the client04:25
ayoungall hte server needs then is to be able to use it04:25
morganfainbergclient changes aren't released the same way as server is04:25
ayoungI want it to be deployed to the other services before we enable on Keystone04:25
morganfainbergyou can likely get the change into client04:25
ayoungbut I want a config option to use a client change on the server04:26
morganfainbergyeah i wouldn't worry about getting it into the client for FF etc04:26
morganfainbergisn't that just an option defined in keystoneclient (
ayoungI can rework the client patch tomorrow.  I need to go to bed now04:26
topolstevemar plz tell me you saw my email04:26
ayoungit needs to be an option passed to the cms call:  compress the token04:26
morganfainbergagain, client change, should be doable04:26
ayoungbut ATM needs to be able to handle first04:27
morganfainbergayoung, *shrug* still probably do able.04:27
*** ayoung is now known as ayoung-snore04:27
topolwhen ayoungs kids get a little older he'll be able to live on 4 hours asleep a night like me. Side effects are minimal..04:28
stevemartopol, reading it now!04:28
topollike giving poor lbragstad a totally undeserved -1 and not even remembering doing it...04:29
* topol what the hell was I thinking..04:29
morganfainbergtopol, hmmmmm.04:30
stevemartopol, nice, way to defend OSC :)04:30
morganfainbergtopol, maybe you were thinking "-1, time for beer"04:30
topolstevemar is that worth sharing with this crowd???04:30
lbragstadmorganfainberg: ++ :)04:31
topolI think the -1 was because lbragstad had not built his bar yet. Just the sign04:32
morganfainbergoh if you guys haven't done it (not that OFTC is 100%) make sure to go register your usernames on the OFTC irc network04:32
*** wchrisj has joined #openstack-keystone04:32
lbragstadhey I'm +2 on the bar for sure! just need to get the time to do it04:32
stevemartopol, i think morganfainberg would get a chuckle out of it04:32
stevemarlbragstad, yes, concentrate on the bar, i can live vicariously through you04:33
topolmorganfainberg how do we do that?  Are we really moving to OFTC?04:33
lbragstadstevemar: ++04:33
stevemartopol, given ttx's last email, i'd say it's unlikely04:33
stevemaror at least not happening for a while04:34
*** lbragstad is now known as lbragstad_04:34
topolmorganfainberg, just fwded you  a halarious email04:34
morganfainbergoh noes04:35
topolmorganfainberg, did you get it?04:36
*** wchrisj has quit IRC04:37
*** stevemar has quit IRC04:51
*** amcrn has joined #openstack-keystone04:55
*** stevemar has joined #openstack-keystone04:55
*** ChanServ sets mode: +v stevemar04:55
*** topol has quit IRC04:56
*** topol has joined #openstack-keystone04:56
*** amcrn_ has joined #openstack-keystone05:00
*** amcrn has quit IRC05:01
*** marcoemorais has joined #openstack-keystone05:07
*** marcoemorais has quit IRC05:09
dstanekmorganfainberg: i saw a review about shutting off the sample check - it that on its way to being merged?05:10
*** wchrisj has joined #openstack-keystone05:11
morganfainbergdstanek,. yeah it's in gate05:11
morganfainbergit's a ways down though05:12
*** ChanServ sets mode: -o morganfainberg05:15
dstanekmorganfainberg: well i got my nick just in case05:18
morganfainbergyeah same05:19
*** stevemar has quit IRC05:26
*** chandankumar_ has quit IRC05:28
*** amcrn_ is now known as amcrn05:30
*** amcrn is now known as DrKatz05:34
*** chandan_kumar has joined #openstack-keystone05:38
*** DrKatz is now known as amcrn05:42
topolI got my nick as well05:56
*** derek_c has quit IRC06:00
*** topol has quit IRC06:09
*** achampion is now known as slic06:09
*** slic is now known as achampion06:10
*** bvandenh has joined #openstack-keystone06:15
*** derek_c has joined #openstack-keystone06:15
*** wchrisj has quit IRC06:29
*** gokrokve has quit IRC06:37
*** saju_m has joined #openstack-keystone07:02
*** amcrn has quit IRC07:36
*** huats_ has joined #openstack-keystone08:04
*** david-lyle has quit IRC08:11
*** nkinder has quit IRC08:11
*** lbragstad_ has quit IRC08:11
*** huats has quit IRC08:11
*** saju_m has quit IRC08:11
*** chandan_kumar has quit IRC08:11
*** dstanek has quit IRC08:11
*** koolhead17 has quit IRC08:11
*** YorikSar has quit IRC08:11
*** florentflament has quit IRC08:11
*** haneef_ has quit IRC08:11
*** bknudson has quit IRC08:11
*** tellesnobrega has quit IRC08:11
*** ayoung-snore has quit IRC08:11
*** sudorandom has quit IRC08:11
*** dolphm has quit IRC08:11
*** jamielennox has quit IRC08:11
*** bvandenh has quit IRC08:11
*** jraim has quit IRC08:11
*** zhiyan has quit IRC08:11
*** derek_c has quit IRC08:11
*** dtroyer has quit IRC08:11
*** Daviey has quit IRC08:11
*** mfisch has quit IRC08:11
*** chmouel has quit IRC08:11
*** zigo has quit IRC08:11
*** mhu has quit IRC08:11
*** ChanServ has quit IRC08:11
*** morganfainberg has quit IRC08:11
*** marekd|away has quit IRC08:11
*** anteaya has quit IRC08:11
*** luisbg has quit IRC08:11
*** david-lyle has joined #openstack-keystone08:28
*** lbragstad_ has joined #openstack-keystone08:28
*** huats has joined #openstack-keystone08:28
*** david-lyle has quit IRC08:29
*** lbragstad_ has quit IRC08:29
*** huats has quit IRC08:29
*** nkinder has joined #openstack-keystone09:02
*** lbragstad has joined #openstack-keystone09:02
*** david_lyle_ has joined #openstack-keystone09:02
*** saju_m has joined #openstack-keystone09:02
*** bvandenh has joined #openstack-keystone09:02
*** chandan_kumar has joined #openstack-keystone09:02
*** dstanek has joined #openstack-keystone09:02
*** haneef_ has joined #openstack-keystone09:02
*** jraim has joined #openstack-keystone09:02
*** zhiyan has joined #openstack-keystone09:02
*** bknudson has joined #openstack-keystone09:02
*** koolhead17 has joined #openstack-keystone09:02
*** YorikSar has joined #openstack-keystone09:02
*** tellesnobrega has joined #openstack-keystone09:02
*** ayoung-snore has joined #openstack-keystone09:02
*** sudorandom has joined #openstack-keystone09:02
*** dolphm has joined #openstack-keystone09:02
*** marekd has joined #openstack-keystone09:02
*** jamielennox|away has joined #openstack-keystone09:02
*** luisbg has joined #openstack-keystone09:02
*** florentflament has joined #openstack-keystone09:02
*** mfisch has joined #openstack-keystone09:02
*** anteaya has joined #openstack-keystone09:02
*** Daviey has joined #openstack-keystone09:02
*** dtroyer has joined #openstack-keystone09:02
*** chmouel has joined #openstack-keystone09:02
*** zigo has joined #openstack-keystone09:02
*** mhu has joined #openstack-keystone09:02
*** morganfainberg has joined #openstack-keystone09:02
*** sets mode: +vovv dstanek dolphm jamielennox|away morganfainberg09:02
*** ChanServ has joined #openstack-keystone09:02
*** sets mode: +o ChanServ09:02
*** bvandenh has quit IRC09:02
*** leseb has joined #openstack-keystone09:15
*** jaosorior has joined #openstack-keystone09:16
*** tellesnobrega has quit IRC09:18
*** saju_m has quit IRC09:19
*** saju_m has joined #openstack-keystone09:35
*** leseb has quit IRC09:46
*** leseb has joined #openstack-keystone09:47
*** leseb has quit IRC09:51
*** dstanek has quit IRC10:08
*** leseb has joined #openstack-keystone10:25
*** bvandenh has joined #openstack-keystone10:51
*** gokrokve has joined #openstack-keystone10:52
*** henrynash has joined #openstack-keystone10:52
*** gokrokve_ has joined #openstack-keystone10:54
*** gokrokve has quit IRC10:57
*** gokrokve_ has quit IRC10:59
*** bvandenh has quit IRC10:59
*** florentflament has quit IRC11:15
*** leseb has quit IRC11:18
*** leseb has joined #openstack-keystone11:18
*** leseb has quit IRC11:22
*** chandan_kumar has quit IRC11:25
*** henrynash has quit IRC11:28
*** henrynash has joined #openstack-keystone11:30
*** gokrokve has joined #openstack-keystone11:52
*** gokrokve has quit IRC11:56
*** chandan_kumar has joined #openstack-keystone12:11
*** leseb has joined #openstack-keystone12:16
*** leseb has quit IRC12:21
*** stevemar has joined #openstack-keystone12:23
*** henrynash has quit IRC12:26
*** leseb has joined #openstack-keystone12:43
*** wchrisj has joined #openstack-keystone12:51
*** gokrokve has joined #openstack-keystone12:52
*** bvandenh has joined #openstack-keystone12:53
*** achampion has quit IRC12:53
marekddstanek, stevemar: o/ Do you mind taking look at this?
stevemarmarekd, sure12:55
marekddocstring fix, however not sure if keystone.conf.sample should be also included (tox made me generate one to pass 'docs' tests)12:56
*** gokrokve has quit IRC12:56
ayoung-snorestevemar, marekd should you be updating the sampleconfig in that patch?12:57
marekdayoung-snore: that's my concern :-) I am not sure.12:57
ayoung-snoreI think that change might have been due to an earlier patch....did you rebase on origin/master12:58
marekdyep, pulled masted, checkout'ed to my branch and fixed the docstring...12:58
ayoung-snoreanyway, I'm not here yet...just getting kids to school.  Nothing seems to be passing gate anyway12:58
marekdany specific bug, or 'recheck no bug' ?12:58
stevemarmarekd, i'm wondering why the conf file is updated, probably shouldn't be13:03
*** d0ugal has joined #openstack-keystone13:09
d0ugalIs there documentation somewhere describing how to make a new service auth with keystone?13:09
d0ugalI've figured out the client part, where it looks up the endpoint with keystone etc.13:10
d0ugalbut at the moment our API is completely open, it doesn't actually verify tokens :)13:10
stevemarmarekd, i might update it with a new patch, just to remove that conf part13:12
*** leseb has quit IRC13:14
*** leseb has joined #openstack-keystone13:14
*** leseb_ has joined #openstack-keystone13:15
*** leseb has quit IRC13:15
*** dstanek has joined #openstack-keystone13:16
marekdstevemar: up to you. rest is fine, i suppose.13:17
stevemaryeah, it's probably an actual artifact from running the config generation script, but that can be done in another patch13:18
stevemarmarekd, it's not your problem to handle :P13:19
*** david_lyle_ has quit IRC13:20
marekdstevemar: ok, i am off from now on.13:20
stevemarmarekd, see you13:20
marekdstevemar: tomorrow! :-)13:20
dolphmeveryone is awake early13:21
dolphmstevemar: in ~3 hours we won't be gating on sample config changes anymore13:21
*** marekd is now known as marekd|away13:22
dolphmd0ugal: drop keystoneclient.middleware.auth_token in front of your app13:24
d0ugaldolphm: aha! This is exactly what I was looking for. Thanks13:25
stevemardolphm, yeah, woke up early :\13:27
*** henrynash has joined #openstack-keystone13:32
dstanekdolphm: this last few days it has caused lots of pain13:37
dolphmdstanek: i'm still slightly sad to see it go13:38
dstanekdolphm: i haven't looked to see if my fears where realized, but i suspect autogen adds options that we don't even support13:41
*** leseb_ has quit IRC13:42
dolphmdstanek: i believe that's true -- i remember skimming past a few options thinking "that's probably useless.."13:42
*** browne has joined #openstack-keystone13:45
*** browne has quit IRC13:46
*** browne has joined #openstack-keystone13:48
*** leseb has joined #openstack-keystone13:48
*** gokrokve has joined #openstack-keystone13:52
*** gokrokve has quit IRC13:57
*** henrynash has quit IRC14:03
lbragstaddstanek: nice work on the hacking checks14:04
lbragstadreviewing now14:04
dolphmlbragstad: dstanek: link?14:04
dstanekstevemar: thinking about again; is there a way to know what the args are14:04
lbragstaddolphm: ^ starts there14:04
*** achampion has joined #openstack-keystone14:04
lbragstadseries with the last one being the addition of hacking14:04
dstaneklbragstad: there should be a few more today - i have to see which things require the least amount of fixes for right now :-)14:05
dstanekthese patches will likely churn a ton over time14:06
lbragstaddstanek: ok, I was thinking about that. So, I have a question. Are we going to always push up a patch fixing everything prior to adding the hacking check?14:07
lbragstador do it all in one commit?14:07
lbragstadwith one commit being the check and all the fixes for said check14:07
dstaneki'm doing each fix in a separate commit so it's easier to maintain (at least for me)14:08
dolphmdstanek: ++14:08
stevemardstanek, is awesome14:08
dstaneklbragstad: once the sample config check is out of the way i'll make sure all of my patches test OK in Jenkins14:08
dolphmdstanek: free +2 until then14:08
lbragstaddstanek: ok, sounds good. just looks like they are failing because of sample config14:09
lbragstadI have a real nit picky comment on the first one14:09
dstaneklbragstad: i didn't break the check up (yet), but i may have multple reviews of them14:10
stevemardstanek, you mean the kwargs for the consumer?14:11
*** joesavak has joined #openstack-keystone14:11
dstanekstevemar: yeah, not sure i know what kwargs those methods are expecting14:12
dstaneklbragstad: i responded to your comments14:14
dstaneklbragstad: i'm not sure about the extra spacing14:14
*** saju_m has quit IRC14:15
*** leseb has quit IRC14:17
*** bknudson has quit IRC14:18
lbragstaddstanek: yep, I forgot about the case with multiple comment lines and indentation14:19
dstaneklbragstad: if we need to add that later we can - we'll have to have a global tracking previous physical lines to know if we are the first line in a block comment14:20
dstaneklbragstad: good suggestion on the review #; i'll do that14:20
lbragstaddstanek: good point14:20
*** leseb has joined #openstack-keystone14:23
*** gokrokve has joined #openstack-keystone14:25
*** gokrokve has quit IRC14:28
*** gokrokve has joined #openstack-keystone14:33
*** bknudson has joined #openstack-keystone14:43
*** bvandenh has quit IRC14:48
*** henrynash has joined #openstack-keystone14:56
*** henrynash has quit IRC15:11
*** henrynash has joined #openstack-keystone15:21
*** derek_c has joined #openstack-keystone15:27
*** derek_c has quit IRC15:29
*** derek_c has joined #openstack-keystone15:29
*** derek_c has quit IRC15:29
*** derek_c has joined #openstack-keystone15:29
*** ayoung-snore is now known as ayoung15:32
ayoungyou guys wanna see something cool?15:32
ayoungdolphm, this is what happens when ... well , judge for yourself
dolphmayoung: lol15:37
ayoungmight not be a bad idea...if we can convince them it should  be mod_authz_keystone15:38
ayoungActually would be nice for Horizon to use something like that15:39
*** david-lyle has joined #openstack-keystone15:44
*** chandan_kumar has quit IRC15:51
*** zhiyan is now known as zhiyan_15:53
bknudsondolphm: ok... now rechecks... do we have a bug?15:54
bknudsonor just nobug since it's fixed.15:54
dolphmbknudson: i think recheck no bug has been disabled :)15:54
dolphmbknudson: file a bug and mark it invalid?15:55
dolphmbknudson: or fix committed and link to your change15:55
bknudsonI'll open a bug and fix committed it15:55
*** thedodd has joined #openstack-keystone15:55
dolphmbknudson: ping me with the bug number when it exists15:57
bknudsonI thought nova might have one but no15:57
dstanekthe title of the bug should be 'no bug'15:57
*** chandan_kumar has joined #openstack-keystone15:57
*** gordc has joined #openstack-keystone15:59
stevemari do enjoy it when dolphm goes on a -2 spree16:02
*** ayoung has quit IRC16:03
*** derek_c has quit IRC16:05
*** leseb has quit IRC16:07
*** leseb has joined #openstack-keystone16:07
*** gordc1 has joined #openstack-keystone16:09
*** ayoung has joined #openstack-keystone16:09
*** gordc has quit IRC16:10
*** leseb has quit IRC16:11
*** gordc1 is now known as gordc16:14
*** derek_c has joined #openstack-keystone16:23
*** leseb has joined #openstack-keystone16:25
*** richm has joined #openstack-keystone16:25
*** henrynash has quit IRC16:32
*** joesavak has quit IRC16:33
*** joesavak has joined #openstack-keystone16:35
*** jsavak has joined #openstack-keystone16:37
*** joesavak has quit IRC16:40
*** achampion has quit IRC16:43
*** gyee has joined #openstack-keystone16:47
*** henrynash has joined #openstack-keystone16:50
*** derek_c has quit IRC16:50
*** topol has joined #openstack-keystone16:53
*** henrynash has quit IRC16:54
*** rwsu has joined #openstack-keystone17:03
*** leseb has quit IRC17:05
*** finite has joined #openstack-keystone17:06
*** harlowja has joined #openstack-keystone17:07
*** jaosorior has quit IRC17:10
*** devlaps has joined #openstack-keystone17:13
dolphmayoung: dstanek: morganfainberg: topol: turned the warning into a big-red-box warning
*** amcrn has joined #openstack-keystone17:15
ayoungdolphm, thanks.  And thanks for not accidentally rebasing its parent17:16
*** chandan_kumar has quit IRC17:16
dolphmayoung: ++17:16
*** amcrn has quit IRC17:17
*** amcrn has joined #openstack-keystone17:18
topoldolphm:  Good Call.  I like it!17:18
*** henrynash has joined #openstack-keystone17:26
ayoungdolphm, so...priority now would seem to be compressed tokens, or some other way of dealing with the 500 in HTTPD17:27
dolphmayoung: and bugs ;)17:27
dolphmayoung: and yeah, that's a bug so ++17:28 compressed tokens:  we can't just drop in a new token format without breaking a lot of clients17:28
ayounghere's a thought17:28
ayoungadd a new token format to the client, and get Auth token to deal with it17:28
ayoungthen...make a config switch on the server17:28
ayoungits the second part I'm concerned with17:29
ayoungis that too big for RC?17:29
ayoungwe'd need to ensure that the new AT is present in any clients that get the new token format before flipping the switch17:29
ayoungdolphm, ?17:32
*** lbragstad is now known as lbragstad-lunch17:32
dolphmayoung: "a lot of clients" ?17:33
dolphmayoung: also, it's too late for new config options17:33
ayoungdolphm, either older versions of our clients or things like that 3rd party one I showed you17:33 I don't think I can do compressed without something like that.  It could possibly be a new token provider, which would not be a new option, but a new value for an existing optionb17:34
ayoungdolphm, something like  CompressedPKITokenProvider17:34
*** dims has quit IRC17:35
dolphmayoung: so, land support in auth_token for decompressing tokens first, release that in say 0.8.017:35
dolphmayoung: ensure all services require at least 0.8.017:35
dolphmayoung: when that's done, start producing compressed tokens by default17:36
dolphmayoung: it'll be juno, but it'll be safe17:36
ayoungdolphm, that is my thinking.   The server side piece will be a very small token provider, and we'll land for Juno.  If we  don't want to backport, I can find a way to make an out-of-tree version for people that desperately want it in an Icehouse based release17:37
*** dims has joined #openstack-keystone17:38
ayoungdolphm, as far as Kerberos and Horizon, one of my coworkers wrote up a pretty good howto:
ayoungthe idea is that you log in to Horizon, then Horizon does a Kerberos based delegation to get  the token from Keystone.  "Server For User  To Proxy"  or S4U2Proxy is pretty much like Keystone trusts:  You set up an agreement in the Kerberos server  that says "The Horizon service can use a service ticket from an end user to get a service ticket as that same end user for another service"17:42
ayoungI think that the doc he posted coveres MIT Kerberos in general.17:43
ayounggyee, ^^  might interest you as well17:44
ayoungtopol, you, OTOH have no interest in Kerberos I am sure17:44
*** leseb has joined #openstack-keystone17:46
topolayoung, have an interest but its not burning my fingers at the moment17:46
gyeeayoung, nice!17:47
topoldolphm, did you get my email from last night?17:47
ayounggyee, thought you would like.  Need to sync that up with Jose's work17:47
dolphmtopol: i get email?17:47
topolonly from people you respect and admire :-)17:48
dolphmtopol: oh yeah, the IRC log17:48
dolphmtopol: what channel was that? -dev?17:48
topolno just chatting privately17:49
gyeeayoung, I am much prefer doing Kerberos outside of Keystone, but if Jose can live with the performance problem with eventlet more power to him :)17:49
topoldolphm, thats different thanwhat was discussed in the irc, correct? Looked like a one off17:49
ayounggyee, I think there is something wrong with one of his assumptions17:49
dolphmtopol: termie's project is a one off17:49
topoldolphm, correct17:50
ayoungI think that Kerberos in HTTPD to get a token, and then use that token in a cookie makes more sense for what he is doing17:50
gyeeayoung, that token binding right?17:50
ayoung, heh, that too17:51
ayoungbut I mean if he doesn't want to pay multiple times for Kerberos17:51
ayoungput a separte auth URL under Keystone, only Kerberize that url, and then everything else uses a cookie17:51
ayoungthat said, I see no problem with coming up with a Kerberized solution for eventlet, so Long as I don't have to actually make it work17:52
dolphmokay i just finished going through *every* open keystone review and instantiated winter17:53
gyeeits an auth plugin so its optional for everybody else :)17:54
gyeedolphm, *every* review? god bless you17:54
dolphmTIME FOR LUNCH17:54
* dolphm going through 102 bugs after lunch17:55
*** jsavak has quit IRC17:55
*** jsavak has joined #openstack-keystone17:56
ayoungpost lunch bug triage?17:56
* stevemar thinks dolphm needs a beer with his lunch17:56
*** marcoemorais has joined #openstack-keystone17:58
dolphmstevemar: i was thinking something frozen to celebrate feature freeze17:59
stevemardolphm, really *really* cold beer? or ice cream18:01
stevemardolphm, just not both18:01
*** lbragstad-lunch is now known as lbragstad18:03
dolphmstevemar: why not both18:03
stevemardolphm, your stomach will thank me18:04
dolphmstevemar: rofl18:04
dolphmstevemar: i've never had one, but...
stevemardolphm, now you're thinking18:05
dolphmstevemar: needs to be some sort of stout, i think18:05
lbragstad++ to the guiness floats!18:08
lbragstadthat might actually be pretty good with a Vanilla porter18:08
*** marcoemorais has quit IRC18:12
ayoungI will spring for a round of Guiness Extra Stout Floats at the Summit if we can find a place that will make them.18:14
ayoungfor Keystone Core Devs , lbragstad and topol ]18:15
topolayoung, THANKS!!!18:15
ayoungtopol, we might end up making them ourselves, in which case I will spring for the makings18:16
topolayoung, either way works for me18:16
ayoungI think the second way sounds better...more scalable18:16
* ayoung starts researching places that sell beer and Icecream near the summit site18:16
*** marcoemorais has joined #openstack-keystone18:18
ayoungHey!  They even call them package stores!  I'll be making the packie run!18:18
*** leseb has quit IRC18:20
topolI love the picture at I want one now!18:22
lbragstadayoung: :)18:22
*** gokrokve has quit IRC18:22
ayounglbragstad, need to crossreference that with the Conference site18:23
topoldolphm, speaking of good food and beverages, I'll be in NYC at a panel next week 2 blocks from the carnegie deli.  If I dont make it to Atl its because I had a heart attack eating their corn beef sandwich18:23
lbragstadayoung: 12 minutes away from Red Brick18:24
ayounglbragstad, I have a lot of College Classmates in Atlanta.  I might use that site for a mini-reunion18:25
lbragstadsweetwater isn't far, 10 minutes from GWCC18:25
lbragstadayoung: winner -- Gordon Biersch Brewery 6 minutes...18:27
lbragstad2.1 miles18:27
ayoungMeh, Macrobrew now18:27
ayoungRed Brick sounds better18:27
lbragstadyeah, it does sound good18:29
ayoungLast time I was in Atlanta (short of plane changing) I was a New 2nd Lieutenant18:30
*** amcrn_ has joined #openstack-keystone18:32
*** amcrn has quit IRC18:32
gyeeayoung, S4U2Proxy only works with LDAP backend huh18:37
ayounglbragstad, 5 Seasons is pretty close18:38
ayounggyee, "only"  I don't think so18:38
gyeefor the MIT impl I mean18:38
ayoungHe did the FreeIPA setup which is LDAP based18:38
ayoungI can ask18:38
lbragstadyeah, that one looks good too18:39
ayounggyee, what backend would you use instead?18:39
gyeeayoung, for public cloud, we use MongoDB18:40
ayoungFor Kerberos?  Really?18:40
gyeefor private cloud, pretty much whatever customers ask18:41
ayoungneat...didn't know that was an option18:41
gyeeayoung, I mean we have our own mongo driver18:41
ayounggyee, that is beyond my knowhow18:42
*** jordant has joined #openstack-keystone18:45
ayounggyee, can you jump into #freeipa?18:49
stevemarayoung, i'm gonna +A the experimental patch :O18:49
ayoung  "Change has been successfully merged into the git repository."  and with that All BPs are complete for I319:00
lbragstad++ nice19:02
*** raenbakov has joined #openstack-keystone19:03
ayoungthanks to all involved....I will now collapse for 10 minutes19:03
topolayoung, last time you searched in your neighbors cube for something to have as your celebratory drink (trusts)19:05
topolI  remember it well19:05
ayoungtopol, Shh, he still doesn't know it was me.  It was good scotch, too19:05
luisbgayoung, +1 thanks to all triagers19:05
*** packet has joined #openstack-keystone19:09
*** gokrokve has joined #openstack-keystone19:23
*** joesavak has joined #openstack-keystone19:34
*** jsavak has quit IRC19:35
*** joesavak has quit IRC19:39
ayoungOn the compressed token format, I am uncomfortable using {} to distinguish the header of the token, as the braces are not URL safe.  Neither is ## or any of the other reserved character19:53
bknudsonpick something url safe, -s or _ or something19:57
*** marcoemorais has quit IRC20:02
*** marcoemorais has joined #openstack-keystone20:03
ayoungbknudson, I think I'm going to have to....just want to come up with something that doesn't trip us up in the future20:04
* dolphm back from lunch and happy to see icehouse-3 Implemented across the board20:06
*** raenbakov has quit IRC20:06
*** amcrn_ has quit IRC20:09
ayoungbknudson, here's the thing:  I really want to do something like state at each level what the format is;  the token really should just say _BASE64_  and then when you decod ethat, the prefix of the underlying data would be "_GZIP_"  and then when you gunzip it you get "_PEM_"  but...the only thing that is guaranteed to be characters is the BASE64 encoded version20:19
ayoungSo...I could stick it all in one header:20:20
ayoung(DER, not PEM)20:20
dolphmayoung: why not just version them sequentially?20:21
*** marcoemorais has quit IRC20:21
ayoungdolphm, ?20:21
dolphmayoung: if uuid tokens are unversioned but v1, and pki was unversioned v2, start with 3-*20:22
ayoungdolphm, one reason is that I am hoping to be able to use the same mechanism for data other than tokens20:22
ayoungdolphm, for instance, the revocation events, or any data out of keystone20:22
finiteHello again all, still trying to achieve success with Keystone SSL. Going through this doc to add SSL, I'm stuck at the "Files" section. I can't find a file that its referring to.
dolphmayoung: there's a lot more to the process than just the 4 steps you mentioned (like the arbitrary string manipulation that goes on)20:23
ayoungbut also, potentially for use with Oslo messaging20:23
ayoungdolphm, that string manip will go away20:23
ayoungthe process is:20:23
ayoung1 CMS sign to der format20:23
ayoung2 compress (z lib)20:23
ayoung3 base64_urlsafe encode (python library call)20:23
ayoungdolphm, and, implicit step 0 convert object to JSON20:24
dolphmayoung: so call the process token version '3'?20:25
*** arborism has joined #openstack-keystone20:25
dolphmayoung: or just PKIv2 or something20:25
ayoungdolphm, question is whether we want to be able to switch out the signing to handle the KDS stuff20:26
ayoungI'd like to be able to indicate that the rest is the same, but the message is mac'ed20:26
bknudsonfinite: is the file you're supposed to create according to the documentation20:26
bknudsonayoung: why is some kind of versioning needed?20:27
bknudsonthe client isn't going to be able to tell the difference?20:27
ayoungbknudson, Auth Token needs to know how to interpret what it is given20:27
ayoungbknudson, the approach for PKI thus far is sub-optimal20:28
ayoungto say the least20:28
bknudsonJust look for MII20:28
ayoungso, really, that is just...wrong20:28
bknudsonso your step 4 is stick some different prefix ahead of base64.20:29
ayoungMI  would be slightly better, but...the resulting code is not even real Base64 url safe20:29
ayoungbknudson, yeah....question is what to put there20:29
ayoungI was origianlly thinking CMSZ20:29
ayoungsince CMS is the signed document, and Z is compressed20:29
ayoungbut...someone pointed out {} is not url safe.20:30
bknudsonok. I'm not too picky as long as it doesn't start with MII20:30
ayoungbut it is the oslo messaging thing that got me thinking20:30
dolphmayoung: pkiz-<base64> (everyone knows what "pki tokens" are already, i'd rather not start calling it cms when it's not radically different)20:31
dolphmayoung: but really the implementation details don't need to be in the prefix20:31
ayoungdolphm, _pkiz64_ ?20:31
ayoungcan't use <> for the same reason as {}20:31
ayoungactaully, I probably *can*20:31
ayoungas I don't expect to actually put the whole body of the token in an URL, but only in a header20:32
bknudsondon't need the <>, it was just to indicate that it's replaced and not constant20:32
dolphmayoung: i really think pki2- or something, don't make it complicated20:32
ayoungdolphm, I was thinking that keystone client should be able to decode a token....and if a token, why not arbitrary data.  I wasthinking in terms of a KDS client20:33
bknudsonjust don't make the prefix too long otherwise the compressed token will be longer than an uncompressed one.20:33
dolphmayoung: and don't use too many unnecessary chars ;)20:33
ayoungand how CMS makes much more sense for pub sub in Oslo messaging20:33
*** marcoemorais has joined #openstack-keystone20:33
ayoungso if Oslo could use the keystone client to validate signed messages as well as tokens20:33
dolphmayoung: that's sort of the end goal for KDS already, no?20:33
ayoungand KDS does not have a client20:33
ayoungand putting in a new client would be annoying20:34
finitebknudson, thanks I didn't see where I was going to make that file. This document is confusing me really heh. The only lead I have going right now is that my wsgi-keystone file has entires for main and admin and they pint to the cgi-bin/keystone directory, but nothing about that python file.20:34
ayoungbut Keystone client is already pretty much everywhere20:34
bknudsonfinite: I think this is --
bknudsonfinite: so I think the docs are just saying to look for this file wherever you've got keystone installed.20:35
dolphmayoung: just in case
ayoungbknudson, if finite used an RPM or DEB, it probably ended up in /usr/share20:36
bknudsonmaybe the openstack-sdk will be far enough along by then.20:37
ayoungdolphm, can keystone the program support a separate project like Kite?  Does any program have multiple projects other than client/server splits?20:37
finitebknudson, ayoung, (wave @ ayoung) I used the rdo-release repo on centos 6.420:37
ayoungfinite, fairly certain it is in /usr/share/openstack-keystone20:37
dolphmayoung: yes and yes, sort of20:38
bknudsonI always use devstack20:38
dolphmayoung: keystone is in the identity program, "kite" could be as well20:38
finiteayoung, i have /usr/shave/keystone , but not /usr/share/openstack-keystone20:38
ayoungdolphm, I know we keep trying to stick KDS with Barbican, as Barbican was origianlly Cloud Keep and was going to be all things crypto20:38
bknudsonI think nova has several projects -- scheduler, etc.20:38
ayoungfinite, that is probably it20:38
ayoungbknudson, but those are all in one git repo20:39
finiteayoung, yea that dir doesn't have httpd in it at all :(20:39
ayoungrpm -q --list20:39
ayoungrpm -q --list openstack-keystone20:40
dolphmayoung: i'd rather just build the right technical solutions and the technical committee can be free to group them into programs for governance purposes20:40
ayoungdolphm, Oh,  I agree20:41
finiteayoung yup /usr/share/keystone, but no httpd dir in the list20:41
ayoungjust that the only people that seem at all concerned with getting KDS right are on Keystone...20:41
dolphmayoung: fwiw, i'm wearing the "Identity Program Technical Lead" hat now, not the "Keystone Project Technical Lead" hat20:41
ayoungfinite, I know that was an open bug, but20:41
ayoungyou can always use the upstream version20:41
dolphmayoung: ("PTL" was repurposed)20:42
bknudsonpower grab20:42
finiteayoung, aww borken packages :(20:42
ayoungfinite, maybe.20:42
ayoungfinite, I opened the BZ, but I thought it had been closed as fixed20:42
ayounglemme see if I can find the RPM spec file and see if it went elsewhere20:43
bknudsondolphm: is there a reason was blocked as a new feature and not a bug fix?20:43
*** marcoemorais has quit IRC20:43
dolphmbknudson: yeah, i wanted to talk about that one20:44
bknudsonI realize that the oslo-incubator db code did change significantly.20:44
dolphmbknudson: first and and foremost because it's +1186 / 056820:44
dolphmbknudson: second because it affects config options, obviously20:44
bknudsondolphm: y, I see there's new config options.20:45
bknudsondolphm: what do you think about cherry-picking the changes we need for oslo-incubator to fix the bug?20:45
ayoungfinite, I think this is it
dolphmbknudson: consider everything we do until RC1 to be a stable backport -- i think that would be a more backportable approach20:46
ayoungbut ... it says milestone 320:46
dolphmbknudson: would it be cherry picking from this patch, basically?20:47
bknudsondolphm: btw - there's another bug that could be fixed with an oslo-incubator change -- when you start the server it prints out a WARNING about mysql something.20:47
dolphmbknudson: i saw that on list -- we'll need that too20:47
ayoungfinite, it has to be accounted for in the spec file one way or another, either included or exclueded20:47
dolphmbknudson: WARNING mysql will eat all your data20:47
bknudsondolphm: but that's a config change, too...20:48
bknudsonI think it can be worked around with the code we've got too by passing something to db.20:48
dolphmbknudson: that's what i understood (it didn't affect every project as-is?)20:48
dolphmbknudson: keystone also wasn't named in the thread, so i wasn't sure20:48
dolphmbknudson: but every other core project was, IIRC20:49
dolphmbknudson: so i figured we were just forgotten about per usual20:49
finiteayoung, doing a rpm -qa I get openstack-keystone-2013.2.1-1.el6.noarch I assume this is the first milestone.20:49
finitenot the third20:49
ayoungfinite, RHOS4  would be Havana final20:49
bknudsondolphm: maybe they were thinking we'd be able to merge the oslo-incubator db changes since we seemed to be further along.20:49
ayoungthat is Ice220:50
bknudsondolphm: Even though we were up to date just a couple months ago it's still taken +1186 / -568 lines to re-sync!20:50
ayoungfinite, note
dolphmbknudson: i know :(20:51
ayoung  finite that one is stable Havana20:51
*** gokrokve has quit IRC20:51
stevemardolphm, so, theres a lot of references to tenant and keystoneclient in the docs, is that something we want to change?20:51
ayoungfinite, do you have openstack-keystone-sample-data20:51
finiteayoung, I see. Thanks for finding all that info. I'm pulling from here: [rdo-release] name=OpenStack Havana Repository baseurl=
dolphmstevemar: *and* keystoneclient? or in?20:52
finiteayoung, yes sir20:52
dolphmstevemar: (what's wrong with referencing keystoneclient?)20:52
stevemardolphm, trouble is, if we change just tenant to project, it'll muck up the keystoneclient examples, cause they use tenant-create20:52
stevemardolphm, ^20:52
finiteayoung I do have the openstack-keystone-sample-data20:52
ayoungfinite, ah..dang, itsin the wrong dir, though20:52
dolphmstevemar: oh yeah, be careful about it. if it's in the context of v2, it should still say "tenant"20:52
finiteayoung, its in /usr/bin/openstack-keystone-sample-data20:52
ayoungwe need20:53
dolphmstevemar: or tenant (i.e. project)20:53
stevemardolphm, correct, but for the most part it's used in a non-versioned way20:53
ayoungthat is also in %{buildroot}%{_datadir}  just like httpd is20:53
dolphmstevemar: and project in the context of v3 (or where there is no API version in context, go with project)20:53
ayoungI assume that is /usr/share/keystone or something like that20:54
stevemardolphm, my main points of concern:
finiteayoung, yup /usr/share/keystone20:54
ayounggrab the upstream20:55
dolphmbknudson: skimming through the patch i don't see anything risky20:55
ayoungits the same code anyway20:55
finiteinteresting. so much for packages.20:55
ayounggrab havana stables version if you want to be "in sync" though I don't think we've done anything special to it20:55
dolphmbknudson: i assume the config options coming out of oslo are backwards compatible20:55
stevemardolphm, and here: ctrl+f tenant that stuff, lots of references between the two links20:56
finiteayoung, awesome sir, thank you for helping me these past few days. Greatly appreciated.20:56
ayoungdependency.resolve_future_dependencies()  went in Icehouse...grab the Havana version20:56
dolphmstevemar: yeah, those should mostly be changed to reference projects or both20:57
ayoungfinite, I'll put it on your tab20:57
ayoungyou can help me pay for the Guiness Stout Floats at the summit20:57
bknudsondolphm: the "#slave_connection=" was removed... keystone never used it, and it's also a little insensitive.20:57
finiteayoung ;) you take amex/square heh20:57
finiteor will beer do20:57
dolphmbknudson: *this* sync doesn't fix the bug from the mailing list, right?20:58
ayoungSingle Malt Scotch is the preferred method of payment.20:58
bknudsondolphm: no, we'd need another sync20:58
bknudsondolphm: I was in the middle of doing that but got distracted20:58
finiteayoung niiiccee20:59
*** marcoemorais has joined #openstack-keystone21:00
ayoungfinite, I'm not super picky, but there have been some I've tasted that tast like rubbing alcohol.  I don't need 21 year old,  but ...  it needs to smell good.  There is a reason we call the candy Butterscotch21:01
ayoungMacAllen's and Balvenie 10 are both good enough for my palate.21:01
ayoungAh Macallan21:02
ayoungnew I had that wrong21:02
ayounganyway, back to software.21:02
dolphmbknudson: i just did a full code review, mostly ignoring the changes to keystone.openstack.common ... i'd be happy to land it if it has overwhelming support ASAP (because it still looks like a scary-sized patch on the road to RC)21:02
ayoungdolphm, I like _PKIZ64_21:02
ayounggonna go with that21:02
dolphmayoung: but the first underscore is unnecessary, and pki was already base 64 encoded21:03
bknudson64 like 64-bits?21:03
bknudsoncan I use it on my 32-bit system?21:03
* dolphm [openstack][keystone] trying to deploy to precise32, but unable to find _PKIZ32_ packages?21:04
ayoungdolphm, it wasn't really BASE64 more like Base64ish21:05
bknudsonayoung dstanek henrynash stevemar morganfainberg gyee jamielennox|away -- any opinion on getting oslo sync in -- ?21:05
dolphmayoung: base64_urlsafe isn't base64 either, it's just another convention being applied (and it's super convenient because it's stdlib)21:06
dolphmbknudson: ++21:06
ayoungbknudson, how important is 75549?21:06
stevemarbknudson, i'll play devils advocate, why do want it in?21:07
ayounglooks like IBM might want that21:07
dolphmayoung: ++21:07
ayoungDBDuplicateEntry not being translated for DB221:07
bknudsonayoung: without it we've got a regression with DB2.21:07
dolphmalthough i marked the bug as Low initially21:07
ayoungbknudson, I'm looking.21:07
ayoungseems like a lot of file to sync at once21:08
ayoungare they all SQL related?21:08
ayoungyeah..they are21:08
dolphmayoung: it's all common.db except for gettextutils21:08
ayoungI'm ok with the sync...21:08
stevemarthen it would make sense21:08
bknudsonayoung: yes, sadly it was a large change that the oslo team made to the db code :(21:08
ayounglooking at the effect on the keystone code21:08
dolphmayoung: stevemar: the only code worth reviewing in keystone is here
ayoungI wish "diff all side by side" didn't automatically mark all files as "reviewed"21:09
*** andreaf has joined #openstack-keystone21:09
ayoungis (sql.get_engine() going to mess us up on unit testing?21:10
bknudsonayoung: I updated tests/core.py21:10
ayoungbknudson, I'm just thinking about how we do the migrations for testing...nothing in this patch changes the rules there?21:11
bknudsonayoung: we really don't use get_engine often... there's only a couple of places where it's used.21:11
bknudsonayoung: no, everything really works the same way.21:11
ayoungbknudson, but a couple of tests do it specifically21:11
dolphmayoung: other than test_sql_upgrade?21:11
ayoungkeystone/tests/  for example21:11
dolphmayoung: ?? it does?21:12
ayoungand that will share the engine21:12
bknudsonayoung: the oslo code changed so that it doesn't have a global engine anymore.21:12
bknudsonwe used to use that global engine.21:12
bknudsonand now keystone has to have the global engine21:12
ayoungbknudson, yeah...I battled with that when trying to get migrations to work with an in-memory database21:12
ayoungit kept killing the engine and wiping out the database21:12
ayoungI really wanted in memory sqlite for testing21:13
bknudsonayoung: right, have to use the same engine all the time... that should work now.21:13
ayounginstead of having to mount the  ramdisk...but that is not going to happen21:13
ayounginteresting...I wonder if the migration code does that now>21:13
ayoungit was in the upstream code, not ourse that the engine was destroyed21:13
bknudsonayoung: in it's going to get the same engine both times.21:14
bknudsonayoung: in sqlalchemy-migrate?21:14
ayoungI think this code is fine...21:14
dolphmbknudson: this is also still new against every other project -- so is every project broken in this regard in icehouse?21:15
dolphmin progress on heat and nova, new on cinder, glance neutron21:16
dolphms/every other project/several other projects/21:16
finiteayoung, adding to my tab, is it a good idea to have both an SSL enabled keystone service and a swift proxy SSL enabled service talking to each other using a corporate signed PKI?21:17
bknudsondolphm: the bugs that are in oslo are kind of funny because you don't know if someone has merged the fix for it already...21:17
ayoungfinite, that question sounds rhetorical21:17
bknudsonI took on the keystone one because we actually hit it in our internal CI system.21:17
dolphmbknudson: oh true21:18
ayoungthe alternative is either a selfsigned cert (bad) or no SSL (worse)21:18
ayoungwhat are your really asking finite ?21:18
morganfainbergdolphm, for migration collapse do we want 2 cycles for upgrade? i'll keep where i'm at for J1 then21:18
dolphmmorganfainberg: yes, so collapse essex -> grizzly?21:18
bknudsonwhich hopefully our CI system will be able to start reporting to gerrit sometime soon.21:18
morganfainbergdolphm, for J, essex->H21:19
finiteayoung, apologies, I guess I'm trying to ask is it not dumb to try to ssl both keystone and a swift proxy on the same box using internally signed certs.21:19
morganfainbergso to migrate to J you need to be on H21:19
morganfainbergand in K we'll move that to I etc.21:19
dolphmmorganfainberg: so you should be able to upgrade from grizzly -> icehouse with the icehouse release, for example21:19
dolphmmorganfainberg: right21:19
morganfainbergdolphm, and since we're blocking the collapse (-2 for FF)21:19
morganfainbergi'll just aim for J121:19
dolphmmorganfainberg: oh, that's another -2 i wanted to check in on -- there's no benefit to nuking our work there right before release, right?21:20
ayoungfinite, finite if you have a corporate CA that can sign, you should use it.  Clients are going to be talking to Keystone, and you want all that to be properly authenticate and authorized21:20
dolphmmorganfainberg: but it'll save us maintenance effort over the next release cycle21:20
morganfainbergdolphm, correct21:20
ayoungselfsign is a blight.  I should never have written it21:20
morganfainbergdolphm, if we could have squeezed it in, great, but it will have 0 effect for I21:20
morganfainbergdolphm, so putting it in J is 100% good21:21
ayoungfinite, I'm trying to change things over to using certmonger21:21
dolphmmorganfainberg: is it tracked against a BP?21:21
morganfainbergdolphm, nope, going to open one for J21:21
dolphmmorganfainberg: "next"21:21
morganfainbergdolphm, ++21:21
dolphmmorganfainberg: i don't think we get J targets until april21:21
morganfainbergdolphm, right21:21
morganfainbergdolphm, i'll also open the "juno" named deprecation one21:21
morganfainbergbut tag it to "next"21:22
dolphmmorganfainberg: assign to Keystone Drivers21:22
morganfainbergdolphm, ++21:22
dolphmmorganfainberg: and put UUID tokens on the list for juno :)21:22
morganfainbergdolphm, ++21:23
morganfainbergdolphm, a massive ++21:23
finiteayoung, yeah I took a look at that project yesterday. I'm just trying to get a grasp on what was failing before I started looking at the doc that kicked off today's questioning heh. The keystone service was running using SSL, but then the proxy service started throwing 400s when trying to use the tokens.21:23
dolphmmorganfainberg: += sys.maxint21:23
morganfainbergdolphm, yes!!21:24
ayoungfinite, was keystone+SSL and nova/horizon working ok?21:25
finiteayoung, only using swift at this point. Near future adding nova/horizon, but right now the only other piece is swift21:26
*** leseb has joined #openstack-keystone21:27
ayoungfinite, so you can talk to keystone fine using the command line client, just not from swift?21:29
*** leseb has quit IRC21:32
finiteayoung, so yeah using curl I could get a token (with -k to ignore the ssl complaint about it not being a trusted CA) just fine, but when taking that token and pointing to our proxy end point, the proxy returns with a 40121:32
ayoungfinite, you see the problem right?21:33
morganfainbergayoung, i saw the notice... revocation events merged.21:34
morganfainbergayoung, gratz21:34
ayoungmorganfainberg, did you see my response?21:34
finiteayoung, yeah thats a whole other thing, but non-trusted CAs aside, assuming keystone service is running, the proxy service should be able to auth to it? no?21:34
ayoungfinite, I think that if you run with a non-trusted CA, you get a different error than the 401, but not sure21:35
ayoungI would assume it would be a non-http error21:35
morganfainbergayoung, no21:35
morganfainbergayoung, lots of scrollback - let me go looking *scrolls up*21:36
gyeebknudson, sorry missed your ping earlier, I am fine with oslo sync21:36
ayoungmorganfainberg, I am planning a night of making Guiness Stout Floats at the summit21:36
dolphmeasy review
morganfainbergayoung, ++21:36
dolphmayoung: lol i'm in21:37
ayoungdolphm, +221:37
morganfainbergdolphm, +2/+A21:37
gyeeayoung, *making* or *drinking*?21:37
ayoungdolphm, I figure I'll buy the fixings, we all make our own21:37
bknudsongyee: ok, thanks.21:37
ayoungmuch cheaper than spotting for them at a bar21:38
morganfainbergdolphm, i'm +A transifex stuff21:38
morganfainbergdolphm, unless you want me to wait21:38
dolphmayoung: where summit session does this fit into? i want to be sure to attend21:38
ayoungI mena, yeah, it iwll be caned guines, not fresh, but I figure if we are making floats out of them, who is going to be able to tell21:38
ayoungdolphm, I'm thinking Monday night21:38
ayoungkick the summit off right21:38
dolphmmorganfainberg: i wanted to double check against string freeze actually; but i think that particular change is safe21:39
morganfainbergdolphm, also, iirc generally it's accepted (discussed last summit) any core can +2/+A transifex as long as it looks good, no need for 2 cores21:39
dolphmmorganfainberg: otherwise translations are broken21:39
dolphmmorganfainberg: ++21:39
morganfainbergdolphm, string freeze is... what closer to RC?21:39
morganfainbergor am i confused21:40
dolphmmorganfainberg: today21:40
* morganfainberg is confused21:40
morganfainbergdolphm, yep21:40
morganfainbergdolphm, anyway, transifex should always be safe21:40
morganfainbergdolphm, it's translations, not strings :)21:40
dolphmmorganfainberg: yeah21:40
dolphmmorganfainberg: i'd be happy to +A myself, i just wasn't 100% sure when i looked at it21:41
morganfainbergdolphm, :)21:42
morganfainbergdolphm, cool21:42
ayoungso if pkiz64 is for tokens,m and we extended to kds...that would be, what?  something to indicate symmetric crypto21:47
*** arborism is now known as amcrn21:50
dstanekkeystone broke my inbox - when from from 'inbox 0' to 'inbox 2**16'21:50
morganfainbergdstanek, time to declare email bankruptcy21:51
dolphmdstanek: inbox 0 is on the list with unicorns21:52
dolphmi'm at 9322 unread21:53
bknudsonhere's the oslo-incubator sync to get rid of the mysql warning --
dolphmmorganfainberg: thoughts?
dolphmmorganfainberg: (see my comment this morning)21:55
bknudsonI thought there was a reason for truncating passwords? Something about the time to crypt.21:56
dolphmbknudson: that's exactly it21:56
dstanekdolphm: what does it do instead of truncate?21:56
dstanekhow is the max size globally mutable? does he mean malicious Python code?21:58
*** marcoemorais has quit IRC22:02
dstanekman, openstack is talking about moving off of freenode and onto oftc22:06
dstaneknot cool!22:06
dstanekit's like saying 'come on ohio (all of you), you need to go to maine'22:07
*** marcoemorais has joined #openstack-keystone22:07
morganfainbergdolphm, looking now22:11
morganfainbergdstanek, i think he's thinking bad code, malicious python, or bad config22:12
morganfainbergdolphm, ++ on your comment22:13
morganfainbergdolphm, 100% for that22:13
morganfainbergdolphm, if we want to not truncate, an option ot make it strict would be good22:13
morganfainbergwe can transition that to default next cycle if we like it22:13
morganfainbergdolphm, alternatively... we could make it a frozen value so one conf is loaded, you can't change the password_length value, settable only at conf read time22:14
morganfainbergdstanek, ^22:14
morganfainbergi'm not sure i agree with the "sky is falling" tone of the bug that globally mutable is bad in this case.  it would take some serious missteps to cause an issue i think.22:15
dstanekmorganfainberg: nah, i can just as easilty replace keystone.common.utils.hash_password and i can change an int22:15
dstanekin fact i can make a plugin to just automatically email me all the passwords22:15
morganfainbergdstanek, true22:15
morganfainbergdstanek, i do agree that password length enforcement is better as a 400.22:16
morganfainbergrather than truncating.22:16
morganfainbergbut eh, i think this is wishlist, J timeline and needs an option to change behavior22:16
dstanekIMO it's not a security issue that we can do much about22:17
ayoungdolphm, do we need "incubation permission" from the Technical commitee to spin up another project under Identity, or do we as core have the right to decide to do that? Say we thought we should spin off...the policy distribution into its own service and git repo, could we make that decision?22:17
morganfainbergdolphm, i vote -2 (FF), aim for J and go with your suggestion if we want that enforcement.22:17
morganfainbergayoung, if we want to increase scope, we need to get TC approval. We can't "incubate" a project, but can claim it under identity. Incubation still needs to be officially approved by TC22:19
morganfainbergayoung, based upon the KDS discussions (as far as i can tell)22:19
ayoungmorganfainberg, need to get kids...just realized the time...back in a few hours.22:20
*** derek_c has joined #openstack-keystone22:30
*** derek_c has quit IRC22:33
morganfainbergdolphm, rebased22:41
*** leseb has joined #openstack-keystone22:43
*** david-lyle has quit IRC22:46
*** leseb has quit IRC22:47
*** stevemar has quit IRC22:50
lbragstadmorganfainberg: thanks!22:51
morganfainberglbragstad, :)22:51
*** finite has quit IRC22:51
morganfainberglbragstad, was a very quick rebase22:51
lbragstad++ those are the good kinda22:51
*** gordc has quit IRC23:00
*** openstack has joined #openstack-keystone23:03
topolstevemar, fee; free to thank gyee for brow beating a +1 out of me :-)23:08
gyeetopol, I am non-violence :)23:09
topolgyee, you have your ways... :-)23:10
*** jamielennox|away is now known as jamielennox23:17
bknudsonjamielennox: you're going to have to start being up at night to keep the openstack-sdk going in the right direction.23:18
jamielennoxbknudson: ergh, yea23:18
jamielennoxi come back some days and can't believe everything i missed23:18
jamielennoxi used to go back through irc logs when i came online, but it just takes too long23:19
morganfainbergjamielennox, that bug (post merge) still seems to be hitting us.23:19
morganfainbergjamielennox, gate haas already seen one.23:19
jamielennoxmorganfainberg: which bug are we talking?23:19
morganfainbergjamielennox, so i thnk we need to get better logging so we know what is going on23:20
jamielennoxrelated-bug, right23:20
bknudsonso it wasn't the non-atomic write?23:20
morganfainbergi am open to better phrasing on the log23:20
morganfainbergbknudson, it probably was sometimes a non-atomic write23:20
morganfainbergbut we have no idea what the openssl error output is23:20
morganfainbergwe never capture / send that23:20
bknudsonI assume they're actually using the new code?23:20
bknudsondo they need a release?23:21
morganfainbergbknudson, yeah gate failed ~3hrs post merge23:21
morganfainberggate uses trunk clients for integration test23:21
jamielennoxmorganfainberg: i thought we logged that somewhere already23:21
bknudsondon't show dstanek he'll go ballistic with your use of % in a log.23:21
jamielennoxoh, that's in the calledproccess error23:21
morganfainbergbknudson LOL fair point let me fix that.23:22
morganfainbergjamielennox, yeah we drop it silently on the floor23:22
morganfainbergnot sure i want to include it in the exception23:22
morganfainbergbut it def needs to be logged.23:22
dstanekbknudson: :P23:22
morganfainbergupdated to not use % in log23:23
dstanekmorganfainberg: that's one of the checks i'm working on!23:23
morganfainbergdstanek, +++++23:23
jamielennoxmorganfainberg: yea, we should probably be attaching all these log messages to the exceptions and then doing consistent error messages higher up23:23
jamielennoxmorganfainberg: but that's so far down on the list of auth_token failures23:23
morganfainbergjamielennox, yep23:23
morganfainbergjamielennox, so if you want something else in there i can change it up, but i am fine with just logging for now23:24
morganfainbergjamielennox, i just have no way to know what is going on when infra asks "so why is this still broken"23:24
jamielennoxmorganfainberg: dumb question, but does it work?23:24
morganfainbergjamielennox, we use .output to look for the filename in "cert_file_missing"23:25
morganfainbergreturn (file_name in proc_output and not os.path.exists(file_name))23:25
bknudsonmorganfainberg: did you consider trying the cms_verify again?23:25
morganfainbergbknudson, this is 3rd attempt at cms_verify23:25
gyeemorganfainberg, jamielennox, is openstacksdk going to replace all the python-*client out there?23:25
morganfainbergbknudson, well, possibly 3rd23:25
bknudsony, but it's probably the first.23:26
morganfainbergbknudson, if cert file is missing, fetch cert, try again, ca .. same, then still fail, raise opaque error23:26
jamielennoxgyee: i think they want to23:26
gyeejamielennox, who's they?23:26
morganfainbergbknudson, do we really want to say "failed 1 time, try again" in auth_token?23:26
gyeeI am all for it btw23:26
morganfainbergbknudson, not opposed, not sure if that is a valid thing to do each time23:27
jamielennoxgyee: sdk people - i'm of the opinion they are biting off more than they can chew23:27
jamielennoxgyee: am keen to help, but i think they are tackling a big problem23:27
bknudsonjamielennox: I agree that this is a monster project they're taking on.23:27
morganfainbergbknudson, i'm more inclined to log and see what the heck is happening before we add more retry logic23:27
jamielennoxmorganfainberg: ++23:27
bknudsonjamielennox: gyee: they'll be lucky to be able to keep momentum23:27
jamielennoxit's a fairly rare problem and i don't know why it's happening23:27
morganfainbergjamielennox, exactly23:28
jamielennoxbknudson: they have a few big drivers behind it23:28
bknudsonmorganfainberg: I'm afraid that the output is going to be "error 1" or whatever that won't tell us anything.23:28
jamielennoxbknudson: but they face the same problem that OSC does and i don't think people will continue to update 2 sets of clients for every API they add23:28
morganfainbergbknudson, eh at least we have an actual OpenSSL error to go for then. it's a starting place23:28
morganfainbergbknudson, alternatives would be welcome23:29
morganfainbergbknudson, but i don't think retry logic will buy us much here.23:29
gyeebknudson, I do think a common client is beneficial, key is to have the right abstraction23:29
jamielennoxmorganfainberg, bknudson: yes, there is a problem that the only place where certificateConficError is raised is on status_code != 20023:29
jamielennoxgyee: i agree too, they have good goals23:29
gyeestuff that jamielennox did can easily be in the framework, especially session management23:30
bknudsongyee: I'm not convinced that we'll be able to get rid of the existing client libs... they're going for a "user" SDK... does that cover the "admin" SDK that we also need?23:30
morganfainbergbknudson, it would be nice if it did23:30
morganfainbergbknudson, doubtful23:30
bknudsongyee: I've been trying to convince them to look at jamielennox's code.23:30
jamielennoxbknudson: i still like the approach that the SDK relies on all the individual clients23:30
jamielennoxbknudson: if that means fixing the individual clients then that's great!23:30
bknudsonjamielennox: yes, that seems like a good goal, especially if you're not going to get rid of the existing clients anyways.23:31
jamielennoxi was disappointed by yesterday's meeting, nothing seemed to get resolved - and the vendor extensions topic is so far down the list that it should not be a concern yet23:31
gyeenot sure about that, one of its goal should be to reduce package dependency nightmare23:31
bknudsonjamielennox: lol -- yes, they seem to be off in the weeds already.23:31
gyeeyou want 1 client package, or n client package23:32
jamielennoxgyee: they have core python community members on that team, if they want to fix the package dep nightmare i would like to see them do it in pip23:32
bknudsongyee: seems like we could do that without rewriting the client.23:32
gyeebknudson, how?23:33
jamielennoxgyee: i'm still not convinced that the metapackage is a problem, on the other hand my solution to the windows problem is - people use that?23:33
bknudsonjust make one project with all the existing clients.23:33
jamielennoxbknudson: ++23:34
morganfainbergbknudson, python-openstack23:34
gyeebknudson, isn't that he purpose of openstacksdk? one project with all the clients23:34
morganfainbergor openstacksdk23:34
gyeethe rest are just framework stuff23:34
bknudsongyee: no, it's to write a "user" SDK23:34
gyeelike using session for session management23:34
gyeewtf's "user" sdk?23:35
gyeeis there even a distinction?23:35
gyeesdk is api calls, users is the context23:35
jamielennoxbknudson: reading over last nights sdk log - it's... painful23:36
morganfainbergbknudson, i wonder if it would be possible to convince the projects that python-*client should be moved out of the "programs" and into it's own program. client code, in theory, should be roughly all the same, and could be held to the same standards / core for one could in theory be core for others.23:36
jamielennoxbknudson: i've done half of that23:36
bknudsongyee: dolphm was asking about the "user" vs other SDK.23:36
jamielennoxbknudson: standardize discover across service - check23:36
*** henrynash has quit IRC23:36
bknudsongyee: was asking about it in the openstacksdk meeting (it's right after keystone meeting)23:36
morganfainbergbknudson, i don't think it would fly, but it might make consistent client code much much better / easier23:37
morganfainbergjamielennox, ^23:37
bknudsonmorganfainberg: I agree about making the clients more consistent would need a core team.23:37
gyeemorganfainberg, that's all there is23:37
gyeea framework23:37
morganfainberggyee, i mean seriously make openstack client libraries a core team23:38
morganfainberggyee, and the "programs" move their clients over to that new team23:38
gyeemorganfainberg, no argument here23:38
morganfainbergso keystoneclient would become openstack.identity23:39
jamielennoxgyee: i've been fighting this one23:39
morganfainbergnovaclient would be openstack.compute23:39
jamielennoxmorganfainberg: i even mentioned that on the ML in that huge thread23:39
morganfainbergit would be a beast to get going but i think it would solve a lot23:39
dstanekmorganfainberg: is my comment here correct?
dstaneki probably should have asked before posting23:39
morganfainbergdstanek, hmmm23:39
morganfainbergdstanek, you might be right23:39
morganfainberglet me 2xcheck23:40
bknudsongyee: I'd point you to the meeting logs for info about "user" sdk vs admin sdk, but I can't find them.23:40
morganfainbergactually... that might be a flaw in the current truncate code too23:40
dstanekmorganfainberg: origpasswd vs. passwd? yeah, that would be all fail23:41
*** thedodd has quit IRC23:44
dolphmdstanek: your comment is correct afaik23:49
dolphmdstanek: you'd get a 400 on auth23:49
jamielennoxgyee, maybe ayoung can you have a look at:
jamielennoxthat doesn't seem right to me23:50
jamielennoxif we use a trust then it _replaces_ the scope rather than add to it23:51
jamielennoxcan you not scope to a trust and a domain?23:51
dolphmjamielennox: no, but that's because you can't delegate domain-level authorization23:52
jamielennoxdolphm: ok, but a project then?23:52
dolphmjamielennox: i *believe* so23:52
jamielennoxor are you expected to get the trust and find the info from that/23:52
jamielennoxit would seem to definently be a regression:
dolphmjamielennox: oh this is building a request...23:53
dolphmjamielennox: if you specify a trust, then scope is determined implicitly based on what was delegated in the trust23:54
gyeejamielennox, the fix seem correct23:54
jamielennoxdolphm: hmm, right i guess that makes sense23:54
*** dims has quit IRC23:56
gyeethere should be a check on the server side to make sure we don't scope to more than one thing at a time23:56
jamielennoxgyee: i think there is and that's what was failing23:56
jamielennoxthe client was building a request for multiple scopes23:57
dolphmjamielennox: commented -- the problem is one of user expectations ... i'm not sure the proposed fix is any sort of improvement23:57
gyeejamielennox, perhaps the client should emit some warning as well23:57
dolphmjamielennox: it's just silently ignoring broken expectations23:57
*** topol has quit IRC23:57
dolphm(after the change)23:57
jamielennoxdolphm: indeed - but it is a regression that someone relies upon, so not much choice there23:58
dolphmjamielennox: before the change, it sounds like the server was balking at broken user expectations23:58
gyeedolphm, its a smart client, it's trying to read into what user wants :)23:58
jamielennoxno, looking at it was a pure replace silently23:59
dolphmjamielennox: bah... i missed the link to 0.6.023:59
dolphmgyee: no, that's just a bug23:59

Generated by 2.14.0 by Marius Gedminas - find it at!