Tuesday, 2015-02-03

raildostevemar: that a lot of patches, I'll will need more time to see the whole implementation, but its a great feature :D00:03
*** zzzeek has joined #openstack-keystone00:05
*** EmilienM is now known as EmilienM|afk00:11
*** markvoelker has quit IRC00:12
*** markvoelker has joined #openstack-keystone00:12
*** rm_work is now known as rm_work|away00:16
*** markvoelker has quit IRC00:17
*** ncoghlan has joined #openstack-keystone00:21
openstackgerritguang-yee proposed openstack/keystonemiddleware: Make v3 auth work for Swift  https://review.openstack.org/15228300:25
*** dims has joined #openstack-keystone00:27
gyeejamielennox, ^^^00:27
*** carlosmarin has quit IRC00:30
david-lylegyee: before I destroy all of django_openstack_auth, I'm correct in believing we support users with only domain role assignments and no project role assignments?00:32
david-lylethat is users that are members only of a domain and not a project00:32
david-lylemorganfainberg: ^^^ ?00:34
gyeethat's correct00:35
gyeeusers are a memeber of a domain, they access to a project via role assignment00:35
david-lylethat's what I would hope, but also what I was afraid of00:35
david-lylefew assumptions in the code to rework00:35
david-lyleand by few, I mean a heaping pile00:36
david-lylethanks for the sanity check, gyee00:36
gyeeyou can assign role to user for a project or domain, part of V3 api00:36
david-lyleright, that's what I though00:36
david-lyle*thought00:37
david-lylebut before I went and did open heart surgery I wanted to verify00:37
gyeehahaha00:37
morganfainbergdavid-lyle, what gyee  said00:37
david-lyleguess i picked the wrong week to stop sniffing glue00:38
david-lylealright, back at it. Thanks!00:38
gyeedude, you in Colorado, the shit's legal there00:38
*** Ephur has quit IRC00:39
david-lyleindeed, time to find a dispensary00:39
*** chipmanc has joined #openstack-keystone00:41
morganfainberghah00:41
*** Ephur has joined #openstack-keystone00:42
openstackgerritBrant Knudson proposed openstack/keystone: Consistently use oslo_config.cfg.CONF  https://review.openstack.org/14736700:43
*** oomichi has joined #openstack-keystone00:49
*** Ephur has quit IRC00:50
*** sumanth1991 has joined #openstack-keystone00:50
*** tsufiev is now known as tsufiev_00:51
*** raildo has quit IRC00:52
*** markvoelker has joined #openstack-keystone00:52
*** nellysmitt has joined #openstack-keystone00:55
*** nellysmitt has quit IRC01:00
*** markvoelker has quit IRC01:00
*** xxj has quit IRC01:00
*** junhongl__ has quit IRC01:00
*** wpf1 has quit IRC01:00
*** xxj has joined #openstack-keystone01:01
gyeemorganfainberg, https://review.openstack.org/#/c/150134/01:05
gyeecan you please address bknudson's concern?01:05
gyeeit's not a security patch, it will improve mankind01:06
morganfainbergwe *can* submit code that is outside of the official support cycle01:07
morganfainbergbug.01:07
morganfainbergbut*01:07
morganfainbergit would be better if we didn't01:07
morganfainbergthis is not a security fix. i'm tending to agree with bknudson here. feel free to ask dolphm and other stable-maint types01:08
*** serverascode has quit IRC01:08
morganfainbergwithout icehouse receiving extended support [afaik that isn't happening or hasn't be decided]01:08
morganfainbergwe shouldn't backport it01:08
gyeemeh, I like to improve mankind01:08
*** jraim has quit IRC01:09
bknudsonI'm not sure I agree with the stable maint rules but don't hate the player hate the game.01:09
*** ctracey has quit IRC01:09
morganfainbergbknudson, there was a wierd discussion on it at one point01:09
gyeeainners gonna ain't01:09
bknudsonwe should go off and make our own branch01:09
tqtranstevemar: ping, im ready for the setup if you have some time to spare01:09
morganfainbergso, just bug the stable-maint folks01:10
morganfainbergthey may say "yes!!"01:10
*** zhiyan has quit IRC01:10
bknudsonI don't know if there's a process for requesting an exception?01:10
gyeeto me, support policy are for CYA01:11
morganfainbergbknudson, i *think* it's ask the PTL and stable-maint01:11
gyeeopen source, everybody wins :)01:11
morganfainbergand i say, ask stable maint so we have clarity on the policy01:11
morganfainbergthere was a convo that seemed to counter-indicate that policy at some point01:11
*** briancurtin has quit IRC01:11
bknudsonwe really have very few bugs marked as critical...01:11
bknudsonit would have to be gate-breaking.01:11
morganfainbergbknudson, i'm so very happy that is the case01:11
morganfainbergbknudson, you know that right?01:11
morganfainbergso very very very happy01:12
bknudsonwell, it means that essentially nothing is going to be backported after 6 months.01:12
bknudsonother than a change to requirements or something... if we had a gate-breaking problem in icehouse that would be odd.01:12
gyeeforget backport, I'll do it for a nominal charge01:13
*** jraim has joined #openstack-keystone01:14
bknudsonso maybe "critical" in stable branch policy doesn't mean the bug priority01:14
*** serverascode has joined #openstack-keystone01:15
gyeebut seriously, only braveheart runs main branch in product01:16
gyeeso we don't fix anything after 6 months, we won't fix anything01:17
*** wpf1 has joined #openstack-keystone01:17
wanghongmorganfainberg, I want to work on this bp: https://blueprints.launchpad.net/keystone/+spec/model-timestamps, could I?01:17
*** junhongl__ has joined #openstack-keystone01:17
*** briancurtin has joined #openstack-keystone01:18
morganfainbergwanghong, i think this is probably quick and easy to get lined up. - mostly because oslo.db gives us it for freee01:18
morganfainbergwanghong, please do! :)01:19
wanghongmorganfainberg, and another thing. This review, https://review.openstack.org/#/c/130180/, what do you think about the last comment from David Stanek01:19
morganfainbergwanghong, some of it may already be done.01:19
* morganfainberg looks01:19
morganfainbergi'd like to remove it.01:19
morganfainbergthis may be a case where we merge it, backport the fix to juno then remove the driver01:19
morganfainbergin fact... that is probably the right answer.01:20
*** ctracey has joined #openstack-keystone01:20
*** zhiyan has joined #openstack-keystone01:21
*** zzzeek has quit IRC01:21
morganfainbergwanghong, approved. with comment to the effect of this is to be merged backported and removed as we do cleanup in kilo01:21
wanghongmorganfainberg, I think we don't remove it in this develop circle, right?01:21
morganfainbergwanghong, likely not01:22
stevemarmorganfainberg, should wanghong create a spec for the timestamp work?01:22
morganfainbergwanghong, well perhaps. to be seen01:22
wanghongmorganfainberg, OK01:22
morganfainbergstevemar, so i marked it as not needing a spec before.01:22
wanghongthanks01:22
bknudsonif the api is changing we'll need a spec.01:22
morganfainbergstevemar, do you see a benefit to adding a spec for it?01:22
wanghongmorganfainberg, I think it's better to create a spec01:22
morganfainbergi assume it would be backend-only not API impacting01:22
morganfainbergwanghong, please do then.01:22
morganfainbergwanghong, especially if impacting the API01:23
stevemaryeah, couldn't hurt01:23
stevemari assume it will change the return value of certain API calls?01:23
bknudsonwouldn't be able to or even really want to do it in ldap.01:23
morganfainbergbknudson, LDAP assignment is going away01:23
morganfainbergbknudson, ;)01:23
wanghongmorganfainberg, stevemar, I think we should implement filters in this bp01:23
morganfainbergfor users - yeah01:23
bknudsonthe spec was about users and groups, too.01:23
morganfainbergi don't think this goes to the wire01:24
bknudsonpersonally I don't see much use in continuing to enhance the SQL identity backend.01:24
morganfainbergthis is internal-data only01:24
bknudsonwe should move it off into a separate repo and deprecate it in keystone.01:24
morganfainbergbknudson, yes. we should01:24
morganfainbergbknudson, i want to propose that for next cycle for sure01:24
bknudsonif I get some time I'll work on it... or someone else could.01:24
morganfainbergwanghong, can we narrow the scope to just SQL assignment ?01:25
bknudsonshouldn't be too difficult since there's not much in identity anymore.01:25
wanghongmorganfainberg, yes, I think too.01:25
morganfainbergwanghong, great!01:25
wanghongmorganfainberg, do you mean that I just add timestamps for assignment?01:26
*** _cjones_ has quit IRC01:26
morganfainbergwanghong, yeah. don't worry about users/groups01:26
*** _cjones_ has joined #openstack-keystone01:26
wanghongmorganfainberg, OK, I will create a spec.01:27
morganfainbergbut changing the behavior to not nuke projects out of the DB might be a very good approach01:27
morganfainbergdo the nova thing w/ the soft-delete flag01:27
morganfainbergbetter for auditability and resolving cleanup for orphaned objects in other servers01:27
bknudsonI think nova is going away from soft-delete.01:30
bknudsonwe already have cadf for audit.01:31
*** _cjones_ has quit IRC01:31
morganfainbergbknudson, are they?01:31
morganfainberghm01:31
bknudsonmorganfainberg: that's my understanding... there have been lots of complaints about it (similar to the complaints we get for having to clear the token table)01:32
morganfainbergok so just the created_at/updated_at coliumns then01:32
morganfainbergwanghong, ^^01:35
wanghongmorganfainberg, Yes sir:)01:35
* wanghong going to do reviews.01:37
*** gyee has quit IRC01:45
*** diegows has quit IRC01:47
*** dims has quit IRC01:48
stevemarmorganfainberg, bknudson i'd appreciate some eyes on the notification work :)01:49
*** markvoelker has joined #openstack-keystone01:56
*** dims has joined #openstack-keystone01:58
bknudsonstevemar: review other changes then... it'll eventually get to the top of my list.01:59
*** markvoelker has quit IRC02:01
*** tqtran has quit IRC02:11
lhchengjamielennox: when is the next keystoneclient release?02:13
*** erkules_ has joined #openstack-keystone02:14
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577002:14
lhchengjamielennox: our test are failing, would like to pickup your fix :)  this one:  https://review.openstack.org/#/c/145981/02:14
*** dims has quit IRC02:15
morganfainberglhcheng targeted for monday02:15
lhchengmorganfainberg: cool, thanks!02:15
morganfainberglhcheng, we're waiting till post K2 to avoid breakign the gate unintentionally02:15
morganfainberglhcheng, but otherwise it'd be today ;)02:15
*** dims has joined #openstack-keystone02:15
*** erkules has quit IRC02:16
lhchengmorganfainberg: sounds good, yeah I prefer also  to do it after K2 :)02:16
openstackgerritSteve Martinelli proposed openstack/keystone: Add context to manager classes that send notifications  https://review.openstack.org/15186602:20
openstackgerritSteve Martinelli proposed openstack/keystone: WIP - Add CADF notifications for trusts  https://review.openstack.org/15186702:23
*** spandhe has quit IRC02:43
*** sumanth1991 has quit IRC02:44
jamielennoxayoung: still here?02:55
ayoungNope02:55
ayoungDamn02:55
ayoungYep02:55
*** nellysmitt has joined #openstack-keystone02:56
*** rushiagr_away is now known as rushiagr02:57
*** markvoelker has joined #openstack-keystone02:57
ayoungjamielennox, what's up?02:58
jamielennoxayoung: still s4u2 - had to duck out for a bit02:58
jamielennoxtrying to follow: http://adam.younglogic.com/2014/05/s4u2proxy-horizon/02:59
jamielennoxi also set up a sample phpinfo script that is under the same kerberos enforcement as horizon so i can look at the env headers02:59
jamielennoxturning on constraineddelegation seems to have done nothing noticable02:59
jamielennoxayoung: i assume that ldap constrained delegation that is mentioned is set up somewhere else? because it's not registered on my server03:00
ayoungI had to set it up following Alexander's blog post03:00
*** nellysmitt has quit IRC03:01
jamielennoxhttp://www.freeipa.org/page/Howto/Setting_up_S4U2Proxy_with_FreeIPA03:02
jamielennox:(03:02
ayoungjamielennox, its is one of the reasons why I thought we were going to punt on it03:02
ayoungbut getting it set up is not really that bad03:02
*** markvoelker has quit IRC03:02
ayoungI'm just not comfortable with the "complete impersonation" type of proxy it performs03:03
jamielennoxayoung: i'm guessing if i just followed the steps it would work - i was just hoping to understand it03:03
ayoungread ab's post.  It is pretty informatice03:03
ayoungtive03:03
jamielennoxayoung: i was under the impression we really don't have any choice here03:03
ayoungwell, the SAML approach is flawed too, just in different ways03:04
ayoungit all sucks at some point03:04
ayoungbut I thought that was what we were going for03:04
*** chipmanc has quit IRC03:04
ayounguse Kerberos to get a SAML assertion and hand that to Keystone is, I think, a little better.  But S4U2 approach will work for current IPA users, and there is a comparable AD set up03:05
jamielennoxi'm just trying to get the next step through the DOA plugins patch03:05
ayoungyeah.03:05
ayoungI wrote a simple wsgi server to confirm that S4U2 worked.  It just requestsed a token and dumped it to the response03:05
jamielennoxi expect that to be better longer term, but i haven't even tried to look at ipsilom yet03:06
ayoungyeah.03:06
ayoungso...all of this is wrong wrong wrong.  SAML is just another bearer token, and really what we should be doing is having the user authenticate directly with the services.03:07
ayoungit was why I was all over CORS back around the time of the summit03:07
jamielennoxthe straight kerberos vs ipsilom kerb for saml is going to be a big difference in workflow03:07
ayoungthe user should be authenticating directly to the thing he needs to do work for him03:07
jamielennoxas in the ksc-kerberos plugin won't handle that03:07
jamielennoxand so it seems stupid to try and make DOA work with it if ipsilom is the long term plan03:08
ayoungipsilon has other hurdles to clear03:08
jamielennox(not speaking for RH, just keystone)03:08
ayoungdiffernt use cases I think03:08
ayoungfor the in house cloud, I think S4U2 is probably the right way to go03:08
*** chipmanc has joined #openstack-keystone03:09
ayoungI mean, the horizon server really can only get a ticket for Keystone, so its not horrible03:09
ayoungthere are other issues, but I am willing to turn a blind eye to them today03:09
jamielennoxif we make horizon accept an existing token as auth - which it's supposed to have to do for federation anyway03:10
ayoungthis is one of those topics where "all the alternatives suck" and makes me want to turn to alcohol03:10
ayoungNeed to go to do more snow removal.  Back in a few minutes.03:11
*** ayoung is now known as ayoung-snowjob03:11
jamielennoxi was going to say that handles negotiation directly and then redirects to horizon - but we've discussed that and it's still got mostly the same limitation03:12
*** rushiagr is now known as rushiagr_away03:13
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve creation of expected assignments in tests  https://review.openstack.org/14454403:19
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Refactor check of targets and actors on RoleV3  https://review.openstack.org/14470203:19
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Check for invalid filtering on v3/role_assignments  https://review.openstack.org/14470303:20
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignment Tests  https://review.openstack.org/13702103:20
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignments Filters Performance  https://review.openstack.org/13720203:20
*** samueldmq has quit IRC03:26
*** tellesnobrega_ has joined #openstack-keystone03:31
*** markvoelker has joined #openstack-keystone03:33
*** lhcheng has quit IRC03:39
*** jbonjean has quit IRC03:45
openstackgerritMerged openstack/keystone: fix the wrong update logic of catalog kvs driver  https://review.openstack.org/13018003:46
*** jbonjean has joined #openstack-keystone03:46
*** davechen_ has joined #openstack-keystone03:48
*** davechen_ has quit IRC03:53
*** rushiagr_away is now known as rushiagr03:53
*** ayoung-snowjob is now known as ayoung03:56
*** richm has quit IRC03:59
*** cchipman has joined #openstack-keystone04:00
*** chipmanc has quit IRC04:01
ayoungGah..just realized I really don't want a "token" object in the access info.  a token is a pointer to an access info.04:06
* ayoung throws up hands and heads to bed04:06
*** ayoung is now known as ayoung-gnight04:06
*** harlowja has quit IRC04:08
*** dims has quit IRC04:13
*** _cjones_ has joined #openstack-keystone04:28
*** lhcheng has joined #openstack-keystone04:30
*** lhcheng_ has joined #openstack-keystone04:31
*** _cjones_ has quit IRC04:34
*** lhcheng has quit IRC04:34
*** cchipman has quit IRC04:41
*** nellysmitt has joined #openstack-keystone04:57
*** nellysmitt has quit IRC05:02
*** ajayaa has joined #openstack-keystone05:12
*** MasterPiece has joined #openstack-keystone05:18
*** dougwig has quit IRC05:38
*** dougwig has joined #openstack-keystone05:38
*** sumanth1991 has joined #openstack-keystone05:45
*** sumanth1991 has quit IRC05:47
*** rwsu is now known as rwsu-afk05:51
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/15185606:04
*** oomichi has quit IRC06:09
*** jaosorior has joined #openstack-keystone06:09
*** MasterPiece has quit IRC06:11
stevemaryay for websso tests06:19
*** abhirc_ has quit IRC06:25
*** abhirc has joined #openstack-keystone06:26
*** rushiagr is now known as rushiagr_away06:32
openstackgerritSteve Martinelli proposed openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617706:44
morganfainbergstevemar, just pushed through a bunch of work for the k2 milestone06:45
stevemarmorganfainberg, i saw that06:45
morganfainbergstevemar, also https://review.openstack.org/#/c/152337/4/specs/no-downward-sql-migration.rst06:45
morganfainberg:)06:45
stevemari always wondered wtf was downgrading06:46
*** avozza is now known as zz_avozza06:52
openstackgerritMerged openstack/keystone-specs: Address federated domain comments from 149071  https://review.openstack.org/15228106:52
morganfainbergstevemar, so i have a request from -infra [hard core users of keystone and openstack]06:56
morganfainbergmake it possible to know for a user what information is valid to authenticate with06:56
morganfainberge.g. "password", "x509", etcx06:56
morganfainbergit relates to the work RAX has been working on for MFA06:56
morganfainbergbut it's only a subset.06:57
stevemarmorganfainberg, yeah i caught some of that earlier in the day06:57
morganfainbergthey initially were thinking it's be global, i think that is incorrect and should be global or-user-by-user/group-by-group06:57
morganfainbergthoughts?06:57
stevemarclark is concerned that we chicken and egged ourself06:57
morganfainbergbut the idea seems sount06:57
morganfainbergsound*06:57
stevemartheir claims are not unsubstantiated06:57
morganfainbergeh. kindof. i mean we didn't really06:57
morganfainbergbecause you are told what to auth with when you get your account06:58
morganfainbergwhen we support various types of auth (real auth, not just "you could use X")06:58
morganfainbergthen it becomes more chicken-egg (not to be confused with hand-egg)06:58
stevemari immediately thought that a URL that says the supported auth types is really nice06:58
*** nellysmitt has joined #openstack-keystone06:58
morganfainbergso we should know 2 things: 1) what auth-types does the cloud support06:58
stevemarwhy do you say user-by-user or group-by-group06:59
morganfainbergthis should be totally discoverable06:59
morganfainbergthink the SP model06:59
morganfainbergmy support team must login with X restrictions (aka x509)06:59
morganfainbergbut i don't require all my customers to do so06:59
morganfainbergin many cases it'll be toggled globally.06:59
morganfainberghowever we can't ignore SP-type models06:59
morganfainbergomg look at the keystone team: http://status.openstack.org/zuul/ consuming all the gate pipeline at the moment...07:00
morganfainbergWHO DO THEY THINK THEY ARE!?07:00
stevemarmorganfainberg, those handsome devils07:01
stevemarmaybe i'm not seeing the difference between the SP-types and the global auths, when would they be different? wouldn't one always be a super set of the other07:01
morganfainbergthe difference is what happens when i try and login07:02
morganfainbergi try and login with support user07:02
stevemaralso, i did that thing you voluntold me for: https://review.openstack.org/#/c/152018/ :)07:02
morganfainbergbut i use a password/and username07:02
stevemarmorganfainberg, hmm, i can see how that is confusing07:02
morganfainbergi'm not a customer so - i need to be told "NO go use XXX auth" or "only supporting XXX auth" or even "xxx auth is not allowed for user x"07:02
morganfainbergdepending on security concerns07:02
* morganfainberg isn't concerned with the data returned this early in the convo07:03
morganfainbergstevemar, yay nice!07:03
*** nellysmitt has quit IRC07:03
*** zz_avozza is now known as avozza07:04
stevemarmorganfainberg, so how do you plan on figuring out what auth mechanisms are valid on a per-user basis?07:07
morganfainbergstevemar, it'd have to be a user-level (or group level?) authentication thing07:07
morganfainbergsome kind of administrative toggle07:07
stevemarmorganfainberg, we could default it to whatever is in cfg.CONF.auth, but ...07:08
morganfainbergstevemar, that would be my choice, you default and then allow reducing it to a smaller list07:09
stevemarif the admin updated the [auth] section, then those changes have to propagate (or you add to the list)07:09
*** avozza is now known as zz_avozza07:10
openstackgerritguang-yee proposed openstack/keystonemiddleware: Make v3 auth work for Swift  https://review.openstack.org/15228307:14
*** abhirc has quit IRC07:18
*** nkinder has joined #openstack-keystone07:22
*** mzbik has joined #openstack-keystone07:23
openstackgerritMerged openstack/keystone: Service Providers API for OS-FEDERATION  https://review.openstack.org/10462307:23
openstackgerritMerged openstack/keystone: Create K2K SAML assertion from Service Provider  https://review.openstack.org/15204607:23
openstackgerritMerged openstack/keystone: Drop URL field from region table  https://review.openstack.org/15012207:23
openstackgerritMerged openstack/keystone: Update federation config to use Service Providers  https://review.openstack.org/15226007:28
openstackgerritMerged openstack/keystone: add circular check when updating region  https://review.openstack.org/13047407:28
openstackgerritMerged openstack/keystone: Implements subtree_as_ids query param  https://review.openstack.org/14861807:28
openstackgerritMerged openstack/keystone: Remove local conf information from paste-ini  https://review.openstack.org/13412507:28
stevemaryay merges!!!!!!!!07:29
*** pnavarro has joined #openstack-keystone07:33
Qlawy5th of february is comming ;)07:41
openstackgerritMerged openstack/keystone: Add positive test case for content types  https://review.openstack.org/13059107:42
openstackgerritMerged openstack/keystone: Refactor role assignment assertions  https://review.openstack.org/14454307:42
stevemarlaunchpad died07:43
stevemarthat means i sleep now07:43
*** afazekas has joined #openstack-keystone07:52
*** stevemar has quit IRC07:53
*** chlong has quit IRC07:56
*** erkules_ is now known as erkules08:01
*** ncoghlan has quit IRC08:01
*** lhcheng_ has quit IRC08:08
*** pnavarro has quit IRC08:12
*** zz_avozza is now known as avozza08:15
*** nellysmitt has joined #openstack-keystone08:24
*** wpf1 has quit IRC08:25
*** wpf1 has joined #openstack-keystone08:26
*** MasterPiece has joined #openstack-keystone08:28
*** andreaf has joined #openstack-keystone08:33
morganfainbergmarekd, re: x-service-url08:33
morganfainbergmarekd, headers: https://tools.ietf.org/html/rfc664808:33
morganfainbergmarekd, we might want to rename those before we start relying on them to something that conforms to ^^08:33
marekdmorganfainberg: looking.08:33
*** henrynash has joined #openstack-keystone08:34
*** ChanServ sets mode: +v henrynash08:34
marekdmorganfainberg: so, SP-URL and SP-AUTH-URL ?08:34
morganfainbergmarekd, well probably OPENSTACK-SP-URL and OPENSTACK-AUTH-URL or KEYSTONE-SP-URL and KEYSTONE-AUTH-URL ?08:34
morganfainbergif i'm reading this correctly08:35
marekdmorganfainberg: ok, i will take a closer look at the doc, just managed to see 'dropping X- preffix in HTTP headers'08:35
marekdactually, I will re-think if we can avoid it.08:35
morganfainbergmarekd, to adhere to that doc, it would be a rename not a drop the headers08:36
morganfainbergand i'm fine with the headers (it merged ;)08:36
marekdas my understading is you prefer to have as little headers as possible.08:36
morganfainbergwe do08:36
morganfainbergif we can avoid it great, but this is a case where it feels like the right kind of break that convention08:36
marekdmorganfainberg: the whole k2k seems to be openstacky (not super general) in the end, so maybe we can rely on service catalog. Let me go through this today again.08:38
morganfainbergmarekd, ++08:39
* morganfainberg goes to bed.08:39
marekdmorganfainberg: in fact, maybe we could store SP-URL, SP-AUTH-URL when reading data from service catalog.08:39
marekdmorganfainberg: yep, it's after midnight in SoCal, right?08:39
morganfainbergalmost 108:40
*** bjornar has joined #openstack-keystone08:42
marekdso, good night08:42
*** henrynash has quit IRC08:46
*** henrynash has joined #openstack-keystone08:49
*** ChanServ sets mode: +v henrynash08:49
*** spandhe has joined #openstack-keystone08:50
*** henrynash has quit IRC08:51
openstackgerritChangBo Guo(gcb) proposed openstack/keystone: Use dict comprehensions instead of dict constructor  https://review.openstack.org/14384208:57
*** jistr has joined #openstack-keystone08:58
*** spandhe has quit IRC09:03
*** spandhe has joined #openstack-keystone09:03
*** _tziOm has joined #openstack-keystone09:05
*** _tziOm has quit IRC09:05
openstackgerritMerged openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/15185609:08
*** spandhe has quit IRC09:09
*** junhongl__ is now known as junhongl09:18
*** krykowski has joined #openstack-keystone09:26
*** henrynash has joined #openstack-keystone09:29
*** ChanServ sets mode: +v henrynash09:29
openstackgerritwanghong proposed openstack/keystone: fix another normal user can get other user's ec2 credential  https://review.openstack.org/15244409:48
*** krykowski has quit IRC09:48
*** MasterPiece has quit IRC09:49
*** henrynash has quit IRC10:05
*** krykowski has joined #openstack-keystone10:16
*** MasterPiece has joined #openstack-keystone10:30
*** samueldmq-away is now known as samueldmq10:31
*** MasterPiece has quit IRC10:43
*** nellysmitt has quit IRC10:50
*** krykowski has quit IRC10:50
*** aix has joined #openstack-keystone10:51
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve creation of expected assignments in tests  https://review.openstack.org/14454410:56
*** MasterPiece has joined #openstack-keystone10:56
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Refactor check of targets and actors on RoleV3  https://review.openstack.org/14470210:57
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Check for invalid filtering on v3/role_assignments  https://review.openstack.org/14470310:58
*** krykowski has joined #openstack-keystone10:58
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignment Tests  https://review.openstack.org/13702110:59
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignments Filters Performance  https://review.openstack.org/13720211:00
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve creation of expected assignments in tests  https://review.openstack.org/14454411:06
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Refactor check of targets and actors on RoleV3  https://review.openstack.org/14470211:06
*** krykowski has quit IRC11:06
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Check for invalid filtering on v3/role_assignments  https://review.openstack.org/14470311:07
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignment Tests  https://review.openstack.org/13702111:14
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignments Filters Performance  https://review.openstack.org/13720211:15
*** jistr has quit IRC11:21
*** aix has quit IRC11:27
openstackgerritwanghong proposed openstack/keystone: fix normal user can delete other user's ec2 credential  https://review.openstack.org/15247711:27
*** jistr has joined #openstack-keystone11:27
*** aix has joined #openstack-keystone11:28
*** amakarov_away is now known as amakarov11:33
samueldmqdolphm, I'm writing a spec for HMT on horizon... I'll use a few sentences from http://dolphm.com/hierarchical-multitenancy/ as motivation, ok?11:35
*** diegows has joined #openstack-keystone11:44
*** pnavarro has joined #openstack-keystone11:44
*** pnavarro has quit IRC11:45
*** pnavarro has joined #openstack-keystone11:45
*** pnavarro has quit IRC11:49
*** pnavarro has joined #openstack-keystone11:49
*** pnavarro has quit IRC11:58
*** chlong has joined #openstack-keystone12:06
samueldmqamakarov, thanks for your comment on review #144702, just replied12:06
*** EmilienM|afk is now known as EmilienM12:08
*** avozza is now known as zz_avozza12:15
amakarovsamueldmq, please use six.iteritems - in it will save us a bug in py3 :)12:17
amakarovs/in//12:17
samueldmqamakarov, six.iteritems(kwargs) works as well, will use it thanks12:20
*** boris-42 has quit IRC12:22
*** boris-42 has joined #openstack-keystone12:22
*** aix has quit IRC12:24
*** mflobo has quit IRC12:26
*** mflobo has joined #openstack-keystone12:29
*** mflobo has quit IRC12:29
*** mflobo has joined #openstack-keystone12:29
*** MasterPiece has quit IRC12:31
*** tellesnobrega__ has joined #openstack-keystone12:31
*** tellesnobrega_ has quit IRC12:32
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone-specs: Reseller  https://review.openstack.org/13982412:36
*** aix has joined #openstack-keystone12:37
*** zz_avozza is now known as avozza12:39
*** markvoelker has quit IRC12:45
*** markvoelker has joined #openstack-keystone12:46
*** markvoelker has quit IRC12:50
*** diegows has quit IRC12:50
*** josecastroleon__ has quit IRC12:52
*** Qlawy_ has joined #openstack-keystone12:53
*** alex_xu_ has joined #openstack-keystone12:53
*** Qlawy has quit IRC12:54
*** Qlawy_ is now known as Qlawy12:54
*** Qlawy has quit IRC12:55
*** Qlawy has joined #openstack-keystone12:55
*** markvoelker has joined #openstack-keystone12:56
*** g4rg4m3|_ has joined #openstack-keystone12:57
*** jasondotstar has quit IRC12:57
*** alex_xu has quit IRC12:57
*** wanghong has quit IRC12:57
*** htruta has quit IRC12:57
*** htruta has joined #openstack-keystone12:57
*** wanghong has joined #openstack-keystone12:58
*** diegows has joined #openstack-keystone13:08
*** avozza is now known as zz_avozza13:14
*** gtt116__ has joined #openstack-keystone13:20
*** gtt116_ has quit IRC13:23
*** jasondotstar has joined #openstack-keystone13:28
*** gtt116_ has joined #openstack-keystone13:31
*** gtt116__ has quit IRC13:35
*** bknudson has quit IRC13:38
*** gordc has joined #openstack-keystone13:39
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Refactor check of targets and actors on RoleV3  https://review.openstack.org/14470213:40
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Check for invalid filtering on v3/role_assignments  https://review.openstack.org/14470313:40
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignment Tests  https://review.openstack.org/13702113:40
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignments Filters Performance  https://review.openstack.org/13720213:41
samueldmqamakarov, ^addressed13:44
*** wanghong has quit IRC13:45
*** wanghong has joined #openstack-keystone13:46
*** raildo_away is now known as raildo13:50
*** obutenko has quit IRC13:57
*** raildo has quit IRC14:01
*** htruta has quit IRC14:01
*** tellesnobrega has quit IRC14:01
*** samueldmq has quit IRC14:01
*** bknudson has joined #openstack-keystone14:02
*** ChanServ sets mode: +v bknudson14:02
*** zz_avozza is now known as avozza14:03
*** ajayaa has quit IRC14:04
*** avozza is now known as zz_avozza14:05
*** jasondotstar has quit IRC14:08
*** mzbik has quit IRC14:15
*** markvoelker has quit IRC14:16
*** josecastroleon has joined #openstack-keystone14:16
*** markvoelker has joined #openstack-keystone14:16
*** samueldmq has joined #openstack-keystone14:18
*** jasondotstar has joined #openstack-keystone14:20
*** markvoelker has quit IRC14:21
*** timcline has joined #openstack-keystone14:26
*** richm has joined #openstack-keystone14:28
*** boris-42 has quit IRC14:32
*** dims has joined #openstack-keystone14:36
*** obutenko has joined #openstack-keystone14:38
*** afazekas has quit IRC14:45
*** rushiagr_away is now known as rushiagr14:49
*** zz_avozza is now known as avozza14:50
*** abhirc has joined #openstack-keystone14:54
*** mattfarina has joined #openstack-keystone14:55
bretondstanek started a patch-hunt on sample config changes14:58
*** mattfarina has quit IRC14:58
dstanekbreton: i created and little script that is searching for them :-)14:58
openstackgerritBrant Knudson proposed openstack/keystone: Move eventlet server options to a config section  https://review.openstack.org/13096215:00
*** markvoelker has joined #openstack-keystone15:01
*** mattfarina has joined #openstack-keystone15:01
*** ajayaa has joined #openstack-keystone15:02
openstackgerritAndrey Pavlov proposed openstack/keystone: Handle SSL termination proxies for version list  https://review.openstack.org/13223515:02
openstackgerritBrant Knudson proposed openstack/keystone: Regenerate sample config file  https://review.openstack.org/15256315:05
*** krykowski has joined #openstack-keystone15:05
openstackgerritBrant Knudson proposed openstack/keystone: Regenerate sample config file  https://review.openstack.org/15256315:05
bknudsonhttps://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+file:etc/keystone.conf.sample,n,z15:08
bknudsongerrit can query on file names.15:08
dstanekbknudson: exactly15:08
dstaneki'm actually doing something more like https://review.openstack.org/changes/?q=status:open+project:openstack/keystone+branch:master+file:etc/keystone.conf.sample15:10
*** rm_work|away is now known as rm_work15:10
*** mattfarina has quit IRC15:11
*** carlosmarin has joined #openstack-keystone15:12
*** topol has joined #openstack-keystone15:12
*** ChanServ sets mode: +v topol15:12
openstackgerritAlexander Makarov proposed openstack/keystone: LDAP additional attribute mappings description  https://review.openstack.org/11859015:14
openstackgerritAlexander Makarov proposed openstack/keystone: LDAP additional attribute mappings description  https://review.openstack.org/11859015:15
*** dims has quit IRC15:15
*** dims has joined #openstack-keystone15:17
*** dims has quit IRC15:20
*** baffle_ is now known as baffle15:20
*** mattfarina has joined #openstack-keystone15:20
*** gabriel-bezerra has quit IRC15:21
*** zzzeek has joined #openstack-keystone15:22
*** gabriel-bezerra has joined #openstack-keystone15:23
*** nellysmitt has joined #openstack-keystone15:27
*** samueldmq_ has joined #openstack-keystone15:28
*** htruta has joined #openstack-keystone15:28
*** raildo has joined #openstack-keystone15:28
*** tellesnobrega has joined #openstack-keystone15:28
*** mattfarina has quit IRC15:28
*** abhirc has quit IRC15:34
*** tellesnobrega__ has quit IRC15:40
*** joesavak has joined #openstack-keystone15:41
*** krykowski has quit IRC15:44
*** krykowski_ has joined #openstack-keystone15:44
*** stevemar has joined #openstack-keystone15:44
*** ChanServ sets mode: +v stevemar15:44
bretonhow do you do -Code-Review?15:46
*** avozza is now known as zz_avozza15:48
samueldmqbreton, I think it is when you had a -1 and you remove it with a 015:49
*** zz_avozza is now known as avozza15:49
*** diegows_ has joined #openstack-keystone15:53
stevemarsamueldmq, you are correct15:55
*** diegows has quit IRC15:57
*** thedodd has joined #openstack-keystone16:00
*** atiwari has quit IRC16:01
*** abhirc has joined #openstack-keystone16:01
*** samueldmq has quit IRC16:03
*** avozza is now known as zz_avozza16:04
bretonok, thank you16:06
*** ayoung-gnight has quit IRC16:09
*** samueldmq_ is now known as samueldmq16:10
samueldmqstevemar, :-)16:10
samueldmqbreton, np16:10
*** dkingshott has joined #openstack-keystone16:11
*** diegows has joined #openstack-keystone16:14
*** remote_morgan_ has joined #openstack-keystone16:16
*** zz_avozza is now known as avozza16:18
bknudsonI'm using keystone in devstack -- how do I disable debug mode?16:20
*** abhirc_ has joined #openstack-keystone16:24
*** abhirc has quit IRC16:26
stevemarbknudson, asking the hard questions16:28
stevemarbknudson, isn't there a setting in the apache config16:33
htrutabknudson: I guess it's /etc/keystone/keystone.conf16:34
htrutathere should be some 'debug' or 'log_level' property16:34
htrutaI used it in ubuntu, btw16:35
bknudsonI set the debug option to false and it still says debug mode is on.16:36
htrutadid you restart keystone after it?16:36
bknudsonyes.16:38
bknudson2015-02-03 10:38:54.278 DEBUG keystone.openstack.common.service [-] debug                          = True from (pid=30872) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py:206516:39
bknudsonthat should be false... how to configure...16:39
bknudsonsetting debug=False in config file doesn't do it.16:41
dstanekbknudson: what about the logging configuration?16:45
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577016:46
rodrigodsbknudson, thanks for the reviews. There were some comments that I didn't get, so I replied in patchset 20 ^16:47
marekdanybody  knows what is 'maneta'  in openstack world?16:48
marekdi know there is monasca16:48
marekdmoneta16:48
*** diegows_ has quit IRC16:48
*** diegows has quit IRC16:49
*** krykowski_ has quit IRC16:49
rodrigodsmarekd, never heard of (but in portuguese has a really fun meaning) heh16:49
raildohahaha16:50
marekdi don't even wanna know.16:50
rodrigodslol16:50
htrutamarekd: Moneta is an application to make some types of conversions to financial metrics16:51
marekdhtruta: in openstack, right? Do you have any links? Google seems to be silent about that.16:51
htrutalast time I've heard (in paris Summit), it wasn't in stackforge yet16:51
marekdhtruta: Moneta has something to do with Monasca, right?16:52
htrutamarekd: I watched a talk about it in summit... let me see if I find it16:52
marekdhtruta: thanks.16:52
*** abhirc_ has quit IRC16:52
htrutamarekd: not really... it was at the moment integrated with ceilometer16:52
marekduh16:52
htrutamonasca would be something in the future16:52
marekdhtruta: monasca is easy to find and there is some rading, but one can find nothing about Moneta.16:53
marekdthat's why i am asking here.16:53
htrutalet me see16:53
htrutafound it!16:56
htrutahttps://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/billing-integration-enablement-for-ceilometer16:56
marekdthanks!16:56
*** lhcheng has joined #openstack-keystone17:00
*** abhirc has joined #openstack-keystone17:00
*** dims has joined #openstack-keystone17:01
*** boris-42 has joined #openstack-keystone17:02
*** abhirc has quit IRC17:03
*** mattfarina has joined #openstack-keystone17:07
openstackgerritMerged openstack/keystone: Remove TODO comment which has been addressed  https://review.openstack.org/14805317:13
*** diegows has joined #openstack-keystone17:14
*** rwsu-afk is now known as rwsu17:15
*** _cjones_ has joined #openstack-keystone17:21
*** nkinder has quit IRC17:25
*** topol has quit IRC17:30
*** abrito has joined #openstack-keystone17:31
openstackgerritSteve Martinelli proposed openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617717:33
*** mattfarina has quit IRC17:34
*** diegows has quit IRC17:37
*** jistr has quit IRC17:38
*** atiwari has joined #openstack-keystone17:45
*** krtaylor has quit IRC17:48
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577017:51
morganfainbergmarekd, https://blueprints.launchpad.net/keystone/+spec/k2k-service-providers is complete right? except what we discussed earlier today? / late laste night?17:53
*** krtaylor has joined #openstack-keystone17:54
marekdmorganfainberg: apart from the headers i need to toss a patch extending service catalog with service_providers object.17:54
morganfainbergmarekd, if that patch isn't in flight today i need to move this to k317:54
morganfainbergmarekd, should i move this bp to k3?17:55
openstackgerritMerged openstack/keystone-specs: Update doc for generating SAML2 assertion  https://review.openstack.org/15208317:55
*** gyee has joined #openstack-keystone17:55
*** ChanServ sets mode: +v gyee17:55
marekdwait please17:55
marekdif i don't manage to do it in few hours we can move to k3.17:56
*** nellysmitt has quit IRC17:58
*** henrynash has joined #openstack-keystone18:01
*** ChanServ sets mode: +v henrynash18:01
*** spandhe has joined #openstack-keystone18:03
*** krykowski has joined #openstack-keystone18:05
*** topol has joined #openstack-keystone18:07
*** ChanServ sets mode: +v topol18:07
*** abhirc has joined #openstack-keystone18:10
*** harlowja has joined #openstack-keystone18:15
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577018:21
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577018:26
*** cburgess has joined #openstack-keystone18:29
*** jsavak has joined #openstack-keystone18:32
*** joesavak has quit IRC18:33
*** thedodd has quit IRC18:42
*** andreaf has quit IRC18:43
*** andreaf has joined #openstack-keystone18:44
*** joesavak has joined #openstack-keystone18:50
*** tqtran has joined #openstack-keystone18:52
*** tqtran is now known as tqtran_afk18:52
*** jsavak has quit IRC18:53
openstackgerritMerged openstack/keystone: Explicit Unscoped  https://review.openstack.org/14252118:55
*** rushiagr is now known as rushiagr_away18:57
*** aix has quit IRC18:59
*** krykowski has quit IRC19:00
lbragstado/19:00
dolphmkrtaylor: i assume that was the wrong review link?19:00
stevemaro/19:00
stevemardolphm, i think so19:00
morganfainbergkrtaylor, yeah looks like the wrong review link19:00
dolphmrelevant link, but not as advertised :P19:00
jamielennoxkragniz: i'm pretty sure what you're testing there is the python interpretter19:01
krtayloroops19:01
lbragstadso, if something fails on powerkvm due to a keystone patch (we add a new dep thats unsupported by powerkvm for example). How do we go about fixing?19:01
jamielennoxthat's not right19:01
jamielennoxkragniz: ignore - sorry19:01
samueldmqhenrynash, hi, you still around?19:01
lbragstador is it more a tool for internal teams?19:01
krtaylormorganfainberg, https://review.openstack.org/#/c/148567/19:02
henrynashsamueldmq: yes, although I’m actually on vacation today….just popped in for keystone IRC meeting19:02
jamielennoxI would like to request everyone to have a look at the keystoneclient and middleware reviews - particularly those mentioned in the gist in topic so we can release on monday19:02
rodrigodsjamielennox, I'd appreciate if you could review the HMT changes as well19:02
samueldmqhenrynash, np, we can talk tomorrow (or whenever you get back)19:03
krtaylordolphm, morganfainberg, the former was a patch to make this a requirment for all CI systems  :)19:03
samueldmqhenrynash, :-)19:03
dolphmkrtaylor: is there something interesting about the deployment configuration you're using for keystone?19:03
jamielennoxrodrigods: ok - i haven't been looking at those because i wasn't sure we had it ready from a server perspective19:03
henrynashsamueldmq: back in tomorrow...19:03
rodrigodsjamielennox, they are... https://review.openstack.org/#/c/115770/ and the follow up one19:03
dolphmhenrynash: vacation harderer19:04
samueldmqhenrynash, ack19:04
rodrigodsjamielennox, both changes are already merged in server. thanks in advance :)19:04
*** ajayaa has quit IRC19:04
krtaylorlbragstad, it would be good for us to document a process for that, I don't have an exact answer, but it will prob come up again19:04
morganfainbergkrtaylor, ^ dolphm's question is really what i'm looking for an answer to19:04
krtaylordolphm, deployment configuration, I guess I need to understand what you mean by that19:05
krtaylorwe do a default deployment, devstack, just what upstream infra does for their CI testing19:05
dolphmkrtaylor: can we see the keystone.conf, keystone-paste.ini and policy.json that you're using?19:06
lbragstadso there should be anything different19:06
krtaylorexcept test on non-x86 architecture19:06
dolphmkrtaylor: then i have no interest at all in test results from powerkvm19:06
morganfainbergthis sounds like you're testing python then?19:06
morganfainbergand python libs19:06
morganfainbergnot keystone19:06
krtaylordolphm, sure, but it will be exactly the same as infra CI19:06
dolphmkrtaylor: right, so i have no interest in the extra noise19:06
dolphmkrtaylor: so please don't leave comments19:06
morganfainbergif it is the same as infra. we're adding extra noise vs signal something is broken.19:07
krtaylormorganfainberg, like I said in email, it is really a matter of quality, to assure that someone wanting to run keystone on a different platform knows that some set of tests have been run19:07
jamielennoxrodrigods: with https://review.openstack.org/#/c/115770/25/keystoneclient/v3/projects.py if i set subtree_as_list that will change the return type of the function to a list rather than a single project?19:07
morganfainbergas stated by stevemar if this is using db2 or something that is different than infra it has interesting aspects we might want to be aware of19:07
dolphmkrtaylor: you can show your test results elsewhere then - they provide no value to keystone reviewers19:08
morganfainbergkrtaylor, this sounds like a marketing thing - "we tested keystone on our platform lookat the results"19:08
morganfainbergkrtaylor, i mean, not trying to say it is, but that is what i'm feeling from it here.19:08
krtaylordolphm, except like lbragstad mentioned, the developer woul dget to see that the code they pushed failed on our platform19:08
dolphmkrtaylor: the odds of that happening and providing distinguishing value appears to be zero19:09
dolphmkrtaylor: further, you're not asking the community to support your platform, so it's just useless noise and will degrade the review process19:09
krtaylordolphm, I agree that it is less likely to happen with keystone19:09
krtaylordolphm, there is this concept of supported hypervisors, with nova19:10
morganfainbergkrtaylor, if the deployment is materially different than -infra's i think your case has more merit (especially since keystone is very unlikely to run into something we can benfit from)19:10
rodrigodsjamielennox, no.. it will be project object with an attribute that will be a list of projects19:10
krtaylorband it will come again, with ARM, maybe Hyper-V19:10
morganfainbergkrtaylor, the key difference here is we are compltely hypervisor agnostic19:10
morganfainbergwe don't need to support kvm, or xen, or hyper-v.19:10
dolphmor os x ;)19:11
morganfainbergwe're actually service agnostic19:11
lbragstadI guess something I meant by that was, as a developer and reviewer I would find value in the comments iff I had the ability to supply a fix. But if its a black box then it hard to say it useful because can't do anything to help you fix the problem.19:11
morganfainbergdolphm, shhhh i'm bitter about that19:11
krtaylormorganfainberg, but isnt it useful to know if it works or not on those platforms?19:11
dolphmkrtaylor: no?19:11
dolphmkrtaylor: if there's a failure, it's a downstream issue19:11
morganfainbergkrtaylor, does python work on that platform? openssl? i think we're talking testing a few layers down in the stack.19:11
*** pnavarro has joined #openstack-keystone19:12
krtaylorit is just easier to fix before the merge19:12
krtayloras you all know19:12
morganfainbergkrtaylor, i don't know what we'd be fixing.19:12
krtaylorbut I agree, less likely to find a problem in keystone19:12
lbragstadbut we can't fix powerkvm code19:12
morganfainbergkrtaylor, what would we be fixing? a python interpreter issue?19:12
dolphmkrtaylor: the odds of a patch to keystone breaking your CI is unrealistically low when compared to the odds of your system producing transient failures19:13
krtaylordolphm, we certainly have transient failures :)19:13
amakarovmorganfainberg, Is it OK for Keystone to use LUA scripts to implement Redis lock?19:13
morganfainbergamakarov, i. uh.. wait what?19:13
dolphmkrtaylor: we have enough of those already with a single CI19:14
krtaylorlbragstad, agreed, but we can help get it fixed19:14
amakarovmorganfainberg, I'm working on redis cache backend19:14
morganfainbergkrtaylor, so here is my stance - if you're doing a deployment that differs from -infra base deployment materially19:14
amakarovour kvs is incompatible with redis locks19:14
morganfainbergin a way that could provide value to deployers19:14
morganfainbergamakarov, look at how dogpile does it19:14
dolphmamakarov: using dogpile or no?19:15
amakarovdogpile uses redis locks19:15
krtaylordolphm, morganfainberg, we want to test all Level 1 projects, and some maybe all Level 219:15
morganfainbergamakarov hook into dogpile for it if needed.19:15
morganfainbergkrtaylor, but right now i'm not seeing anything besides duplicating -infra.19:15
dolphmkrtaylor: go for it - but the results are your business19:15
dolphmamakarov: have a patch or a failure or something to share? i'm curious19:16
amakarovmorganfainberg, I've read both dogpile and redis-py code - there is a strait-forward locks with polling19:16
krtaylormorganfainberg, infra runs on x86, not ppc64 or ARM, etc19:16
stevemarkrtaylor, yeah, as dolphm says, any failures are your own, and the results should be non-voting19:16
morganfainbergkrtaylor, please do not comment (add noise) unless we have something that is likely to have something we can fix.19:16
amakarovmorganfainberg, yes, I have a failure. moment...19:16
stevemarkrtaylor, yeah, but there is no arch-specific code in keystone :(19:16
krtaylorstevemar, agreed, non-voting, not asking for that19:17
morganfainbergkrtaylor, your results are your own, test away19:17
lbragstaddoesn't infra also have a requirement that ci can't be voting unless it's open?19:17
dolphmkrtaylor: your test results do not sound valuable to keystone developers or reviewers, period19:17
morganfainbergkrtaylor, please do not comment unless there is a material (testing the python interpreter is working doens't classify for me) - we have no arch depended code in keystone19:18
amakarovmorganfainberg, https://review.openstack.org/#/c/15084419:18
morganfainbergdependent*19:18
krtaylormorganfainberg, dolphm - ok, thanks everyone, I appreciate the time19:18
jamielennoxrodrigods: so subtree_as_ids will be {'id': Project, 'anoter_id': Project} ?19:19
amakarovdogpile actually uses lock implemented by lua19:19
morganfainbergamakarov, we rely on dogpile19:19
morganfainbergamakarov, so if there is an issue there we either a) fix what we can or b) get dogpile fixed19:19
morganfainbergzzzeek is the maintainer of dogpile19:19
rodrigodsjamielennox, something like that... (I'm currently updating both patches, small refactoring)19:19
jamielennoxrodrigods: it's more just i haven't played with it from the server side19:19
*** edmondsw has joined #openstack-keystone19:19
morganfainbergkrtaylor, if you start doing a varied deployment (e.g. db2, some custom webserver/wsgi container) etc, it becomes more valuable to have external comments19:20
amakarovmorganfainberg, problem is on our side :)19:20
amakarov if self.mutex.lock_timeout == 0:19:20
morganfainbergkrtaylor, this isn't a locked door.19:20
morganfainbergamakarov, there are ways to override how that all works.19:20
amakarovredis LuaLock has no lock_timeout19:20
rodrigodsjamielennox, we have some nice docstrings: https://github.com/openstack/keystone/blob/master/keystone/resource/core.py#L24819:20
dolphmamakarov: is the problem that we're assuming there's a lock_timeout when it's actually optional?19:20
morganfainbergkrtaylor, so if things change please come back and let us know and we will re-evaluate19:21
krtaylormorganfainberg, I appreciate that, we have talked about incorporating more19:21
morganfainbergdolphm, probably19:21
morganfainbergso we likely need to be smarter on redis locking iirc i implemented a way to do that within the crazy driver stuff in there19:22
amakarovdolphm, the problem occurs when we try to discover whether it specified19:22
dolphmmorganfainberg: amakarov: http://dogpilecache.readthedocs.org/en/latest/api.html#dogpile.cache.backends.redis.RedisBackend.params.lock_timeout19:22
amakarovso it can be easily fixed with 'if hasattr(...'19:22
morganfainbergdolphm, but i think this is hitting the mutex19:22
morganfainbergdolphm, directly19:22
morganfainbergwhich is the issue19:22
marekdA question: Can class inheriting from manager.Manager be decorated with @dependency.optional() ?19:23
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577019:23
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Implements subtree_as_ids and parents_as_ids  https://review.openstack.org/15007819:23
dolphmamakarov: what version of dogpile is running in tempest?19:23
rodrigodsbknudson, jamielennox ^ there :)19:23
morganfainbergdolphm, yeah we're hitting the mutex directly19:23
dolphmamakarov: (i assume 0.5.6)19:24
*** thedodd has joined #openstack-keystone19:25
raildomorganfainberg, hey, I just change a few part following a gyee's comment, if you can review :) https://review.openstack.org/#/c/139824/19:25
*** Farhan_ has joined #openstack-keystone19:25
amakarovdstanek, dogpile.cache==0.5.319:25
jamielennoxrodrigods: reading parents_as_ids, that dict is going to always have one element and keep getting more deeply nested right?19:25
dstanekamakarov: ?19:26
jamielennoxyou can only have one parent19:26
amakarovdstanek, it's from pip freeze19:26
morganfainbergamakarov, dolphm, so https://bitbucket.org/zzzeek/dogpile.cache/src/a75835875b9c94bcc018f38d4fc829ec673c9371/dogpile/cache/backends/redis.py?at=master#cl-136 this is where we're running into issues19:26
morganfainbergwe're hitting the redis lock and looking for the timeout there19:26
amakarovdstanek, sorry, my mistake )19:27
morganfainbergin memcache it works like that19:27
amakarovdolphm, dogpile.cache==0.5.319:27
rodrigodsjamielennox, yes19:27
openstackgerritMarek Denis proposed openstack/keystone: Add ``service_providers`` in Service Catalog.  https://review.openstack.org/15265919:27
morganfainbergamakarov, so the answer is what does the lua lockobject thing look like?19:28
stevemarmarekd, nice19:28
morganfainbergamakarov, is there a way to grab the lock info directly?19:28
marekdstevemar: sadly, wip :(19:28
jamielennoxrodrigods: i know i'm way too late to be coming up with this now, but why not just use a list?19:28
stevemarmarekd, oh noes19:28
amakarovmorganfainberg, I'll find a link to the source19:28
morganfainbergamakarov, i think its: https://github.com/andymccurdy/redis-py/blob/master/redis/lock.py#L919:29
rodrigodsjamielennox, we wanted the clients (not necessarily openstack services) to handle both in the same way19:29
amakarovmorganfainberg, https://github.com/andymccurdy/redis-py/blob/master/redis/lock.py#L18619:29
marekdstevemar: got minute?19:29
stevemarmarekd, for you, i have 319:29
marekd:-)19:29
morganfainbergamakarov, it looks like we need to not ask the mutex for the timeout19:30
marekdhttps://review.openstack.org/#/c/152659/1/keystone/catalog/core.py,cm so i want to do something like that19:30
jamielennoxrodrigods: i don't follow - list is a json structure19:30
marekdstevemar: ^^19:30
morganfainbergamakarov, and it's Lock() not LuaLock() lualock is a subclass that layers in the lua magic19:30
jamielennoxrodrigods: oh, you mean child and parent19:30
marekdstevemar: but eventually tox complains there is no attribute like federation_api19:30
*** kfox1111 has joined #openstack-keystone19:30
*** jasondotstar has quit IRC19:30
marekdstevemar: i am wondering if such construction is even possible.19:30
amakarovmorganfainberg, ++19:30
rodrigodsjamielennox, yep :)19:30
marekdbknudson: you are Keystone internals master too, https://review.openstack.org/#/c/152659/1/keystone/catalog/core.py,cm19:31
marekdbknudson: line 83 is possible?19:31
morganfainbergamakarov, so this is an issue where we need to extract (capture) the timeout above the mutex and use that to calculate timedout19:31
bknudsonmarekd: y, that should work.19:31
amakarovmorganfainberg, I want 2 things: 1) get it working; 2) try to use blpoprpush to avoid polling we suffer in memcache lock19:31
morganfainbergamakarov, a lot of this code should be simplified down to just using dogpile-isms with a thin wrapper over the top19:31
morganfainbergamakarov, rather than carrying the heavy cache/kvs overlay19:32
morganfainbergamakarov, right now it needs a lot of work (and should also be done pushing to oslo.cache)19:32
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Implements subtree_as_ids and parents_as_ids  https://review.openstack.org/15007819:32
amakarovmorganfainberg, me too, I'm lazy :P19:32
jamielennoxrodrigods: is list_project_parents sorted?19:32
morganfainbergamakarov, more than anything i don't have time :(19:33
morganfainbergi am not lazy/uninterested here19:33
jamielennoxrodrigods: like is my immediate parent parents[0] then its parent parents[1] etc19:33
stevemarmarekd, thats weird, it should work19:33
jamielennoxoh, that's a dict...19:33
marekdstevemar: bknudson maybe there is some race condition...19:34
marekdor my stupid mistake.19:34
amakarovmorganfainberg, either way I'm intended to run it in our scale-test lab, so it will be some sort of research - so I want to stay in touch with community somehow...19:34
morganfainbergamakarov, of course19:34
morganfainbergamakarov, so yes lets fix that - get smarter about figuring out how to know if a mutex is timed out19:35
morganfainbergbknudson, dstanek, henrynash, ayoung, jamielennox, topol, dolphm, gyee, https://launchpad.net/keystone/+milestone/kilo-2 any spec that has not had all code reviewed/in flight to the gate by tonight will be bumped to k319:35
amakarovmorganfainberg, ok, I'll get my CR up-to-date, WIP, and tell when finish19:36
morganfainbergstevemar, ^19:36
morganfainbergamakarov, this is def. a bug19:36
rodrigodsjamielennox, it is... but we do not guarantee that the full list of projects will be returned19:36
morganfainbergamakarov, please split the bug fix for this into it's own review / file the bug19:36
rodrigodsjamielennox, we filter them with the projects the user has access to (list_projects_for_user())19:36
morganfainbergadding the redis backend as the dependant change.19:36
*** lhcheng has quit IRC19:36
stevemarmorganfainberg, fwiw, the 'cadf-everywhere' work is all up, just waiting on reviews19:36
jamielennoxrodrigods: i posted what i had on patch 25, let me think about what the api should look like from the client19:36
*** lhcheng has joined #openstack-keystone19:36
morganfainbergstevemar, i moved that one to k3, if the code lands we can re-target19:36
amakarovmorganfainberg, fix compatibility bug first - got it19:36
stevemarmorganfainberg, yup, figured19:37
* morganfainberg needs to go get food / coffee pre x-project19:37
jamielennoxideally i'd like to be a bit smarter than just passing through the raw API19:37
samueldmqmorganfainberg, we still need to have list-role-assignments-performance bp approved, spec is already merged19:37
samueldmqmorganfainberg, :-)19:37
jamielennoxi'm not sure if a consumer is really ever going to want to work with the parents_as_ids dict or we should handle that in client19:37
rodrigodsjamielennox, thanks19:38
morganfainbergsamueldmq, done, target k319:38
samueldmqmorganfainberg, so quick :) thanks19:39
morganfainbergmarekd, let me know on https://blueprints.launchpad.net/keystone/+spec/k2k-service-providers19:39
morganfainbergmarekd, so i can retarget if needed.19:40
marekdmorganfainberg: let's move to k3. I pefer to move it now rather than push piece of sh**19:40
morganfainbergk19:40
morganfainbergdone19:40
marekdthanks19:40
rodrigodsjamielennox, regarding urllib comment, I've tried some combinations here and googled about key only query params without success... =(19:40
*** kfox1111 has quit IRC19:40
marekdstevemar: bknudson re: https://review.openstack.org/#/c/152659/1 this is what tox -epy27 complains about: http://pasteraw.com/27m0jyi2pp9vqlktr8n2py9pdvofl5219:41
morganfainberghenrynash, https://review.openstack.org/#/c/149178/15 this needs a rebase19:41
jamielennoxrodrigods: oh, right19:41
jamielennoxrodrigods: does key only matter, parents_as_id=1 is generally the more correct way to do it anyway19:42
morganfainberghenrynash, https://bugs.launchpad.net/keystone/+bug/1415268 is moved to k3 because the whole chain it depends on is k319:42
TempLPBugBot`Launchpad bug 1415268 in Keystone "Testing of backend list_role_assignments needs to be improved" (affected: 1, heat: 6) [Medium,In progress] - Assigned to Henry Nash (henry-nash)19:42
rodrigodsjamielennox, yes, but bknudson was worried about not following the API spec :(19:42
rodrigodsjamielennox, we were using subtree_as_ids=True (which keystone accepts), but in the spec we state that it is key only, so...19:43
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Basic AccessInfo plugin  https://review.openstack.org/14333819:43
stevemarmarekd, oh... which test is it running?19:43
stevemarany test?19:43
morganfainberghenrynash, this needs rebase: https://review.openstack.org/#/c/148995/19:43
morganfainberghenrynash, so it can land in k219:43
marekdstevemar: eg. keystone.tests.test_v3_catalog.TestCatalogAPISQLRegions.test_get_catalog_returns_proper_endpoints_with_region19:43
jamielennoxrodrigods: from memory query strings are supposed to be key value pairs, just having key is the anomaly - but so long as the server side works with both i don't really mind19:44
stevemarmarekd, try using `if hasattr(self, 'federation_api'):` instead19:44
jamielennoxbecause ?parents_as_ids=False should really do what you expect19:44
morganfainbergdolphm, bknudson, stevemar, henrynash, jamielennox, gyee, dstanek, topol: https://review.openstack.org/#/c/131516/ https://review.openstack.org/#/c/62275/ needs eyes for review (today)19:45
stevemarthe dependency guy might not have loaded things yet19:45
rodrigodsjamielennox, ++ maybe we need to do a cleanup in the API someday...19:45
marekdstevemar: i was also thinking there may be some race condition.19:45
topolmorganfainberg, OK will do19:46
dstanekmorganfainberg: i'm still fine with https://review.openstack.org/#/c/62275/19:47
dstanekmorganfainberg: i'll go ahead and A+119:48
*** nellysmitt has joined #openstack-keystone19:48
morganfainberglbragstad, https://review.openstack.org/#/c/142440/19:48
morganfainberglbragstad, needs love19:48
lbragstadmorganfainberg: yep19:49
morganfainbergmoving the removed-as-of-kilo spec to k319:49
*** raildo has left #openstack-keystone19:49
morganfainbergthere is a lot of love still needed there19:49
*** raildo has joined #openstack-keystone19:49
morganfainbergso the only spec really needing love to land is https://blueprints.launchpad.net/keystone/+spec/remove-role-metadata19:50
morganfainbergsomeone needs to rebase/fix the second review there19:50
samueldmqmorganfainberg, will do19:50
morganfainbergsamueldmq, https://review.openstack.org/#/c/148995/19:50
morganfainbergit was WIP'd because of a bug the underlying patch exposed19:51
topolbknudson, https://review.openstack.org/#/c/62275/ is absolute craftmanship!  You took something god awful an broke it up into readable chunks!19:51
morganfainbergit *should* be fixed19:51
morganfainbergcheck with henrynash19:51
morganfainbergbut that is the last outstanding "to be fixed" i want to land this milestone19:51
samueldmqmorganfainberg, yep, but the underlying patch already works correctly (it's mine) :p19:51
rodrigodsjamielennox, replied your comment regarding the subtree and parents attributes (patchset 25)19:51
*** mattfarina has joined #openstack-keystone19:51
morganfainbergunless other things magically work land like cadf everywhere19:51
samueldmqmorganfainberg, but this one depends on the list role assignments refactoring ... at least as henry put19:52
morganfainbergsamueldmq, ah so that pushed this spec to k319:52
morganfainbergok19:52
*** amakarov is now known as amakarov_away19:52
samueldmqmorganfainberg, from what I heard from him, he would like to have this asap19:53
stevemarmorganfainberg, i really want gordc to give the a-okay to cadf everywhere first19:53
morganfainbergstevemar, that's fine, it's k3 for now19:53
openstackgerritMarek Denis proposed openstack/keystone: Add ``service_providers`` in Service Catalog.  https://review.openstack.org/15265919:53
samueldmqmorganfainberg, I think that chain is mature enough, but we can revisit this tomorrow maybe19:53
samueldmqhenrynash, ^19:53
*** mattfarina has quit IRC19:53
stevemargordc, meet the underside of the bus, bus meet gordc19:53
morganfainbergsamueldmq, well i moved the spec to k3 if we can land the stuff needed for it so it can land by tonight19:53
morganfainbergi'll move it back to k219:53
morganfainbergbut if it's not gating by 23:59 tonight (pacific)19:53
morganfainbergit's next milestone19:53
openstackgerritMarek Denis proposed openstack/keystone: Add ``service_providers`` in Service Catalog.  https://review.openstack.org/15265919:54
morganfainbergs/gating/ready to gate/19:54
marekdeh, will investigate it later.19:54
samueldmqmorganfainberg, ok so it will stay for k3, I dont think we'll get enough reviews, since henrynash is on vacancy19:54
topoldstanek, https://review.openstack.org/#/c/131516/8 was pretty good too :-). I mean its not brant-like like  https://review.openstack.org/#/c/62275/  but certainly deserves an honorable mention :-)19:55
morganfainbergtopol, stevemar, bknudson, dstanek, jamielennox, gyee, dolphm, henrynash, https://bugs.launchpad.net/keystone/+bugs?search=Search&field.status=New any bugs there we need to hit before m2? please take a quick look.19:57
morganfainberganything hyper critical should be bubbled up as "do today"19:57
morganfainbergi don't see any right this second.19:57
samueldmqmorganfainberg, what about a @expected(exception.Foo) annotation for those skipped methods we need to move away from?19:58
morganfainbergsamueldmq, something we should do. not required for today19:58
samueldmqmorganfainberg, ++19:58
* gordc drops19:59
dstaneksamueldmq: that already exists in a different way - with self.assertRaises(exception.Foo)19:59
morganfainbergstevemar, marekd: https://bugs.launchpad.net/keystone/+bug/140572619:59
TempLPBugBot`Launchpad bug 1405726 in Keystone "Federation, getting scoped token results in error. " (affected: 1, heat: 6) [Undecided,New]19:59
morganfainberggordc, the scary thing is steve parked that bus on quicksand20:00
morganfainberggordc, hurry before you sink too far!20:00
morganfainberg;)20:00
morganfainberggyee, is this the DIT bug you were tyring to backport to icehouse: https://bugs.launchpad.net/keystone/+bug/1409635 ?20:00
dstaneksamueldmq: see the code here: https://docs.python.org/2/library/unittest.html#basic-example20:00
TempLPBugBot`Launchpad bug 1409635 in Keystone "keystone fails to authenticate users when LDAP project_id_attribute is not CN" (affected: 3, heat: 14) [Undecided,New] - Assigned to Adam Young (ayoung)20:00
gordcmorganfainberg: i've been told to stay still on quicksand... and that it's fake.20:01
gordcstevemar: what you want me to look at?20:01
stevemargordc, just wanted you to revisit that CADF patch, you raised a concern about using the same event_types with different payloads20:02
*** shakamunyi has joined #openstack-keystone20:02
stevemargordc, but i believe morganfainberg wants to go completely CADF, as soon as possible... and drop the other format20:02
stevemargiven the usual 2 cycle period20:02
samueldmqdstanek, hmm, yes I knew that .. just was wondering if with an annotation it wouldnt be simpler20:03
samueldmqdstanek, maybe not... looking deeper on the @wip annotation, I think it should be really used for exposing a bug20:04
dstaneksamueldmq: same #lines of code without having to support something new20:04
samueldmqdstanek, before fixing it, am I right?20:04
samueldmqdstanek, yes, I agree20:04
gordcstevemar: i see... i mean it's not the end of the world if they both send on same event_type... it'd really only be an issue from consumer pov if they sent both (dup or alternating)20:04
gordcstevemar: if it's just one or the other consistently i guess it's fine.20:04
dstaneksamueldmq: yes, it's for annotating a test as work in progress20:04
samueldmqdstanek, like tdd20:04
samueldmqdstanek, k20:05
stevemargordc, yep, which is why i wanted to ensure that the config option was there, and still defaults to the old format too20:05
dstaneksamueldmq: i've used something like this in a past life to write tests i know won't pass (but should) to pass off the code development to someone else20:05
*** dims has quit IRC20:05
*** chlong has quit IRC20:05
samueldmqdstanek, hmm, looks great20:06
samueldmqdstanek, need to try it by myself :)20:06
gordcstevemar: cool cool. i'll take a quick look agagin20:06
gordcagain*20:06
*** vhoward has left #openstack-keystone20:07
*** dims has joined #openstack-keystone20:08
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577020:08
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Implements subtree_as_ids and parents_as_ids  https://review.openstack.org/15007820:08
*** vhoward has joined #openstack-keystone20:08
gordcstevemar: what's the notify_event_callbacks? that has to be called no matter what?20:08
stevemargordc, right, that's what handles the token revocation if a user is deleted, all internal callbacks20:10
stevemargordc, we totally over-used the concept of notifications, and as a result the notifications.py file is super messy20:11
stevemari plan on refactoring it a bit when this is all in20:11
gordcstevemar: yeah i just read the note... the code is super easy to read.lol20:11
stevemargordc, yeah i tried to break things up into logical components to make it easier to read20:11
*** boris-42 has quit IRC20:12
gordcstevemar: cool cool. i'm ok with how it is (factoring in the existings reviews)20:12
gordcit might make sense to append the resource_id to both backward compat resource_info and to a proper location (ie. in target?)20:14
gordcyou'll be duplicating for a bit but i think the resource_id is more related to target (correct me if i'm wrong)20:15
stevemargordc, i like that suggestion20:15
stevemarany suggestion on what the 'key' should be the target?20:15
*** tellesnobrega_ has joined #openstack-keystone20:15
stevemarresource_id? resource_info? project/user/etc_id?20:16
gordcstevemar: uhh... what's 'key' in your question?20:17
*** timcline_ has joined #openstack-keystone20:17
stevemargordc, currently target is: "target": {20:19
stevemar "typeURI": "service/security/account/user", "id": "openstack:1c2fc591-facb-4479-a327-520dade1ea15"20:19
stevemar },20:19
*** joesavak has quit IRC20:19
*** jsavak has joined #openstack-keystone20:19
stevemarand we can extend it with our our keys/properties20:20
*** afazekas has joined #openstack-keystone20:21
stevemari think target has a "name" property we can use20:21
*** afazekas is now known as afazekas_drunk20:21
*** timcline has quit IRC20:22
gordcstevemar: right. i would think you would want to put id=resource_id (assuming resource_id is the id of target)20:22
*** shakamunyi has quit IRC20:23
stevemargordc, hmm, doesn't pycadf do something funky with the id?20:23
gordcstevemar: it prepends a namespace to it... if you don't put one in (it just auto generates a uuid with the namespace)20:24
stevemarhmm okay, cause i thought we were doing that with users, anyway... another discussion20:25
gordcname is an optional attribute but you could throw the resource_id there if you wanted.20:25
*** jasondotstar has joined #openstack-keystone20:25
gordcyeah, basically when you define resource (target, observer, initiator) you just need typeuri and id. it's best that the id is not autogenerated so you can actually group by a common id when querying20:26
gordcthat's assuming you have a stable id you can reference. ie. the primary key from db20:27
*** jorge_munoz has joined #openstack-keystone20:28
*** anteaya has quit IRC20:34
stevemargordc, we definitely have a key to use, maybe i'm getting mixed up with the namespaced uuid auto-gen thing20:36
*** samueldmq_ has joined #openstack-keystone20:37
gordcstevemar: i see. yeah. put your key as id. you really shouldn't be using the autoget id.20:37
stevemargordc, ughhh https://github.com/openstack/keystone/blob/master/keystone/notifications.py#L266-L26720:38
stevemarthats a defect20:38
*** afazekas_drunk has quit IRC20:44
*** timcline_ has quit IRC20:44
gordcstevemar: yep20:44
*** timcline has joined #openstack-keystone20:44
*** timcline has quit IRC20:47
*** timcline has joined #openstack-keystone20:48
*** timcline has quit IRC20:48
*** timcline has joined #openstack-keystone20:48
*** openstackgerrit has quit IRC20:50
*** jasondotstar has quit IRC20:50
*** openstackgerrit has joined #openstack-keystone20:50
*** afazekas has joined #openstack-keystone20:53
*** anteaya has joined #openstack-keystone20:53
*** tellesnobrega_ has quit IRC20:54
openstackgerritMerged openstack/keystone: Refactor keystone-all and http/keystone  https://review.openstack.org/6227520:56
openstackgerritMerged openstack/keystone: Adds a wip decorator for tests  https://review.openstack.org/13151620:56
*** afazekas is now known as fazekas_drunk20:57
*** fazekas_drunk is now known as afazekas_drunk20:57
*** tellesnobrega_ has joined #openstack-keystone20:59
*** tellesnobrega_ has quit IRC20:59
*** timcline has quit IRC21:02
*** diegows has joined #openstack-keystone21:02
*** timcline has joined #openstack-keystone21:03
*** raildo is now known as raildo_away21:06
*** abhirc has quit IRC21:07
*** timcline_ has joined #openstack-keystone21:09
*** nellysmitt has quit IRC21:09
*** timcline has quit IRC21:10
*** abhirc has joined #openstack-keystone21:10
*** timcline_ has quit IRC21:13
gyeemorganfainberg, back to my desk, yes, that was the bug21:14
*** timcline has joined #openstack-keystone21:14
*** topol has quit IRC21:15
*** ayoung has joined #openstack-keystone21:16
*** ChanServ sets mode: +v ayoung21:16
*** josecastroleon has quit IRC21:18
*** kfox1111 has joined #openstack-keystone21:20
morganfainberggyee ok21:30
bknudsonmarekd: you might need to define an __init__ method in order for the DI injecting to work at all... others have run into this.21:30
*** joesavak has joined #openstack-keystone21:31
gyeemorganfainberg, also, about the credential API, say if we store the ec2 keys in barbican, don't we still need to change the ec2 code to use barbican rest API instead?21:31
gyeeec2 or shared secrets21:31
*** jsavak has quit IRC21:32
*** obutenko has quit IRC21:39
*** obutenko has joined #openstack-keystone21:41
*** obutenko has quit IRC21:42
*** jsavak has joined #openstack-keystone21:43
*** joesavak has quit IRC21:46
*** samueldmq_ has quit IRC21:47
*** avozza is now known as zz_avozza21:48
jamielennoxgyee: in which case i think barbican should own the ec2 code21:57
jamielennox.. or maybe i should have thought about that a bit more before typing21:57
gyeejamielennox, my understanding is that they are key management, not crypto operations22:00
*** afazekas_drunk is now known as afeakas|oyua22:00
*** zz_avozza is now known as avozza22:02
jamielennoxec2 middleware is just taking a local key and making an auth request with it right/22:03
*** jsavak has quit IRC22:03
*** jsavak has joined #openstack-keystone22:04
*** pnavarro has quit IRC22:04
*** nkinder has joined #openstack-keystone22:04
gyeejamielennox, no, the shared secret/key never transfer over the wire22:06
gyeeso we essentially have a chicken-n-egg problem22:07
*** avozza is now known as zz_avozza22:07
gyeewe can't talk to barbican to retrieve the key without a token22:07
gyeethere's where trust come in handy I suppose22:07
gyeeunless we store all the keys under one account22:08
jamielennoxgyee: i really needed to look over how ec2 works again before getting into this :p22:10
*** lhcheng has quit IRC22:10
gyeejamielennox, I heard heat also have its own implementation of ec222:10
gyeethe stuff is all over the place it seem22:10
jamielennoxi know they rely on ec2 for some things, i hvaen't seen a custom implementation of it22:11
gyeeme neither, I was hearing rumors :)22:12
*** nkinder has quit IRC22:12
gyeeunconfirmed22:12
bknudsonnova has an ec2 api22:14
gyeebknudson, right, but it uses keystone ec2 middleware I think22:15
*** edmondsw has quit IRC22:17
gyeebknudson, my bad, I mean it calls keystone ec2 api, https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py#L27922:18
*** rm_work is now known as rm_work|away22:19
bknudsongyee: you probably need an ec2 token to use it?22:20
gyeebknudson, ec2 token is keystone token22:20
gyeekeystone ec2 api results in a token being issued22:20
*** jasondotstar has joined #openstack-keystone22:20
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.serialization to oslo_serialization  https://review.openstack.org/14802522:20
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.i18n to oslo_i18n  https://review.openstack.org/15188022:20
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.config to oslo_config  https://review.openstack.org/14525022:20
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.db to oslo_db  https://review.openstack.org/14802922:20
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.messaging to oslo_messaging  https://review.openstack.org/14802822:20
openstackgerritSteve Martinelli proposed openstack/keystone: Use oslo_log instead of incubator  https://review.openstack.org/15269922:21
gyeejamielennox, thanks for chiming in https://review.openstack.org/#/c/152283/22:21
gyeejamielennox, my understanding is that without this patch, Swift can't use v322:21
jamielennoxgyee: i've been playing with it myself22:21
jamielennoxin conjunction with flapper's problem for glance22:21
gyeeor least not in a backward compatible way22:21
jamielennoxright22:22
jamielennoxgyee: these patches will get us some support in oslo.config: https://review.openstack.org/#/c/143423/22:23
jamielennoxthat's how i was going to deal with glance22:23
jamielennoxi don't know if that's an option for swift or not22:23
gyeeI am not sure either, we can ask them22:24
gyeeI don't know how easier for them to upgrade22:24
jamielennoxgyee: i talked to swift - essentially they don't want to start using oslo.config22:25
jamielennoxthey configure the whole swift system via paste22:25
gyeeoh22:25
gyeeI see22:25
*** lhcheng has joined #openstack-keystone22:25
jamielennoxhowever as oslo.config is a dependency of keystonemiddleware they are getting it whether they like it or not22:25
gyeejamielennox, what was the reason they don't want to go with oslo.config22:26
gyeestability?22:26
jamielennoxso possibly we could do a wrapper for them22:26
jamielennoxgyee: more like history i think22:26
jamielennoxand they don't see the benefit in having everyone figure out all the deprecations they would have to do to transition22:26
gyeeif the are getting oslo.config regardless then wrapper make sense22:27
gyeeso as long as it is seamless to them22:27
*** harlowja is now known as harlowja_away22:28
jamielennoxso glance has the problem that it doesn't use the global CONF object, but makes it's own22:29
jamielennoxso i was wondering if we could rewrite the middleware to accept a CONF object rather than use the global22:29
jamielennoxi guess from there we could handle swift by having a function that takes all the **kwargs, construct a CONF object from it and then pass it into the middleware22:30
jamielennoxthat's where my thought process has been heading anyway22:30
*** amerine has joined #openstack-keystone22:31
jamielennoxi tried to rewrite it so AuthProtocol or whatever took only the CONF as a parameter, it's harder than i thought - but mostly just requires some fiddling22:31
*** abhirc has quit IRC22:31
gyeehow does that work? we can't change the paste interface right?22:32
jamielennoxno, but we can essentially extract a base class from it22:32
jamielennoxwhere the superclass would take all the options that it used to take and construct the CONF object for it22:32
jamielennoxI was also wondering about going the other way, like have the AuthProtocol object take the kwargs and have a load_from_conf() method that handles that22:33
jamielennoxthere are a lot of options though.....22:34
gyeeyou mean load_from_conf take both local and global conf?22:34
jamielennoxwell local and global conf are from the paste factory22:34
jamielennoxwhich is just a function that combines them and constructs the object22:34
gyeerigh22:34
gyeeright22:34
jamielennoxso we could handle that in the factory function22:34
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.i18n to oslo_i18n  https://review.openstack.org/15188022:35
openstackgerritTom Cameron proposed openstack/keystone: Add docstrings to remaining functions  https://review.openstack.org/14731322:36
gyeejamielennox, but it is already that way right? https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L197422:36
jamielennoxgyee: ok - so my feeling is that AuthProtocol should take either a CONF object or a kwargs but not both, then we can have helper functions to handle the conversion from one to the other22:37
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.db to oslo_db  https://review.openstack.org/14802922:37
jamielennoxi just don't know which yet22:38
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.config to oslo_config  https://review.openstack.org/14525022:38
openstackgerritSteve Martinelli proposed openstack/keystone: Change oslo.i18n to oslo_i18n  https://review.openstack.org/15188022:38
openstackgerritSteve Martinelli proposed openstack/keystone: Use oslo_log instead of incubator  https://review.openstack.org/15269922:38
jamielennoxi kind of like that we could do a keystonemiddleware that didn't have a direct dependency on oslo.config - however it's a fair bit of work for not much gain, and i wrote a whole bunch of auth.load_from_conf helpers with keystonemiddleware in mind that i could no longer use22:39
gyeeman that global CONF voodoo22:40
gyeeis voodoo22:40
bknudsonso there could be a config option in auth_token which is the name of a function to call to get the conf object?22:40
gyeebknudson, actually that's not a bad option22:40
bknudsonsimilar to how there's a conf option for the swift cache22:40
gyeelet the projects to decide themselves22:41
jamielennoxbknudson: so i was thinking classmethods22:41
jamielennoxAuthProtocol.load_from_conf() and if you don't provide a param it takes global22:41
jamielennoxbecause the main thing we want to support is the paste factory22:42
bknudsonthen the application would need to import AuthProtocol.22:42
jamielennoxbknudson: many do22:42
gyeebknudson's idea is to make it completely independent from keystonemiddleware or oslo.config22:42
jamielennoxbknudson: i want the existing paste etc to work as they do, however the new projects like sahara that don't use paste generally call AuthProtocol directly22:42
gyeebknudson, so the service will have to write extra code, which may not be completely seamless22:43
bknudsonnasty!22:43
gyeebusiness22:44
openstackgerritBrant Knudson proposed openstack/keystone: Cleanup tests to not set multiple workers.  https://review.openstack.org/15151122:45
openstackgerritBrant Knudson proposed openstack/keystone: Move eventlet server options to a config section  https://review.openstack.org/13096222:45
*** jasondotstar has quit IRC22:46
*** andreaf has quit IRC22:46
*** tellesnobrega has quit IRC22:47
*** samueldmq has quit IRC22:47
*** abrito has quit IRC22:47
*** gabriel-bezerra has quit IRC22:47
*** htruta has quit IRC22:47
*** raildo_away has quit IRC22:47
dolphmpublic service announcement: creating AE tokens just benchmarked as 433% faster than creating UUID tokens when deployed against a global galera cluster22:48
lbragstad... wut22:48
gyeesweeeeet!22:48
bknudsonI thought AE tokens were -2?22:48
lbragstadI did a poc of it locally22:49
lbragstadjust to see what performance would be22:49
*** abrito has joined #openstack-keystone22:49
*** samueldmq has joined #openstack-keystone22:49
*** tellesnobrega has joined #openstack-keystone22:49
gyeebknudson, the only concern there is the potential variable size22:49
bknudsonit doesn't support federation tokens.22:50
*** gabriel-bezerra has joined #openstack-keystone22:50
gyeebut even for federation, we have at most 1 group right now22:50
*** htruta has joined #openstack-keystone22:50
dolphmand they're 48% faster under heavy load, in terms of request per second22:50
bknudsonhow about authenticating AE tokens?22:51
bknudsonare you using rally?22:51
*** raildo_away has joined #openstack-keystone22:51
lbragstadbknudson: you mean validating AE tokens?22:51
bknudsonlbragstad: yes, on the auth_token side22:51
dolphmeven token validations are noticably faster (~6%)22:51
gyeelbragstad, I think he mean both sign and encrypt22:51
dolphmbknudson: using apachebench to create load and measure client side performance metrics https://gist.github.com/dolph/02c6d37f49596b3f4298/revisions22:52
dolphmthe latest revision shows the diff between UUID and AE tokens22:52
dolphmthis is also an apache + mariadb deployment as tuned by an idiot22:54
gyeefaster on validation is a bit of pleasant surprise to me22:54
openstackgerritSteve Martinelli proposed openstack/keystone: Use oslo_log instead of incubator  https://review.openstack.org/15269922:54
bknudsondolphm: revocation events?22:54
dolphmbknudson: not doing anything to produce revocation events22:55
gyeeI would expect validation is on par with uuid if not a bit worst22:55
lbragstadbknudson: only did auth and validate22:55
dolphmgyee: that's what we expected too22:55
bknudsonit needs to rebuild the catalog... what do you use for catalog backend?22:55
dolphmbknudson: sql22:55
lbragstadeverything is backed by sql22:55
lbragstadwe're just not storing the token22:55
*** wanghong has quit IRC22:55
bknudsonI bet the templated backend would be super fast22:55
dolphmbknudson: https://github.com/dolph/keystone-deploy/blob/galera/playbooks/roles/http/templates/keystone.conf22:56
gyeedolphm, are you using the same user for all your tests? faster could be the result of caching the lookups22:56
dolphmbknudson: but that probably wouldn't represent a realistic deployment for our customers22:56
*** wanghong has joined #openstack-keystone22:56
dolphmgyee: yes - trying to avoid too many variables22:56
*** wanghong has quit IRC22:56
gyeek, that may explain it22:56
dolphmgyee: it's just taking the same code path over and over22:56
gyeecache is on by default right?22:57
dolphmgyee: no, see the keystone.conf above (it's enabled)22:57
*** wanghong has joined #openstack-keystone22:57
gyeelooks pretty good22:57
gyeelgtm! :)22:57
*** wanghong has quit IRC22:58
bknudsondolphm: where's the config to use AE tokens?22:58
dolphmgyee: if we were going to introduce cache misses into the benchmark scenario, we'd need to create hundreds of thousands of users before starting the test lol22:58
dolphmbknudson: oh, that's a separate playbook. lbragstad ?22:58
lbragstadbknudson: same playbook, different branch22:59
*** wanghong has joined #openstack-keystone22:59
dolphmbknudson: this is the base deployment for UUID, then lbragstad ran a playbook to convert it to AE22:59
lbragstadhttps://github.com/dolph/keystone-deploy/tree/ae-tokens22:59
*** leseb- has joined #openstack-keystone22:59
lbragstadthe only real change is provider = keystone.tokens.providers.ae.Provider23:00
lbragstadand some keyczar stuff23:00
dolphmbknudson: it's sort of arbitrary because it's deploying keystone from lbragstad/keystone instead of openstack/keystone, etc23:00
dolphmwith ae support "merged"23:00
*** wanghong has quit IRC23:00
gyeelooks pretty simple23:01
*** wanghong has joined #openstack-keystone23:01
lbragstadit's POC...23:01
*** wanghong has quit IRC23:01
*** bknudson has quit IRC23:02
dolphmlbragstad: ship it23:02
gyee++23:03
*** EmilienM is now known as EmilienM|afk23:03
gyeemark it experimental23:03
* gyee hides23:03
* lbragstad ducks23:03
*** wanghong has joined #openstack-keystone23:03
dolphmthe BEST part of AE tokens:23:04
dolphm> select * from token;23:04
dolphmEmpty set (0.00 sec)23:04
dolphmLOOK AT THAT RESPONSE TIME23:05
gyeeheh23:05
lbragstadlol23:05
*** rm_work|away is now known as rm_work23:06
*** jsavak has quit IRC23:07
*** briancurtin has quit IRC23:08
*** zhiyan has quit IRC23:08
*** kfox1111 has quit IRC23:08
*** ctracey has quit IRC23:09
*** nellysmitt has joined #openstack-keystone23:10
*** jraim has quit IRC23:10
*** serverascode has quit IRC23:12
*** Ephur has joined #openstack-keystone23:14
*** nellysmitt has quit IRC23:14
*** jasondotstar has joined #openstack-keystone23:15
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/15271423:16
openstackgerritOpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/15271523:16
*** jaosorior has quit IRC23:16
*** kfox1111 has joined #openstack-keystone23:16
*** ctracey has joined #openstack-keystone23:17
*** dims has quit IRC23:17
*** timcline has quit IRC23:18
*** timcline has joined #openstack-keystone23:18
*** dims has joined #openstack-keystone23:19
*** ctracey has quit IRC23:20
*** ctracey has joined #openstack-keystone23:20
*** gordc has quit IRC23:20
*** kfox1111 has quit IRC23:21
*** jraim has joined #openstack-keystone23:21
*** zhiyan has joined #openstack-keystone23:21
openstackgerritOpenStack Proposal Bot proposed openstack/pycadf: Updated from global requirements  https://review.openstack.org/15272223:22
*** timcline has quit IRC23:22
jamielennoxayoung: do you want to unabandon https://review.openstack.org/#/c/115463/ or should i start again23:24
jamielennoxit's completely different now anyway23:24
*** carlosmarin has quit IRC23:25
leseb-hey all, I'm getting a lot of "DBConnectionError: (OperationalError) (2006, 'MySQL server has gone away')" error logs23:26
leseb-this happens quite randomly23:27
leseb-i'm using haproxy but even while pointing at a specific keystone server I'm regularly getting this message23:27
leseb-any idea will be highly appreciated :)23:27
morganfainbergleseb-: there is a version of oslo.db that had an issue. What version of Oslo.db (and what version of keystone) are you using.23:28
leseb-morganfainberg: hum I'm running ubuntu cloud archive juno23:29
*** serverascode has joined #openstack-keystone23:30
morganfainbergdolphm: yes. Non persistent tokens. Yesssss23:30
leseb-morganfainberg: not sure if this helps but dpkg says python-oslo.db 1.0.0-0ubuntu1~cloud0....23:30
dolphmmorganfainberg: https://twitter.com/dolphm/status/56275043730955059223:30
leseb-morganfainberg: how can I precisely check the version?23:31
*** harlowja_away is now known as harlowja23:32
*** briancurtin has joined #openstack-keystone23:33
morganfainbergIf you're installing from apt. There is a dpkg cmd to do it. But I need to get back to my desk to type it / look it up23:35
leseb-morganfainberg: thanks23:36
morganfainbergdolphm: hehe.23:39
morganfainbergleseb-: that version of Oslo.db is your issue. You need (iirc 1.0.2 or later)23:40
*** thedodd has quit IRC23:41
*** jasondotstar has quit IRC23:45
leseb-morganfainberg: upgrading to 1.0.2 breaks keystone...23:46
morganfainbergreally? shouldn't23:46
morganfainbergoh. crud, it might23:46
morganfainbergbecause juno23:46
morganfainbergbut still it shouldn't23:47
leseb-now I'm getting: ImportError: cannot import name i18n when I try to start keystone23:47
morganfainbergthat is wierd23:47
leseb-not sure, maybe pip broke something23:47
morganfainbergyeah this sounds like pip doing something weird23:47
*** henrynash has quit IRC23:48
*** timcline has joined #openstack-keystone23:49
leseb-morganfainberg: arf it broke everything23:50
morganfainberg:(23:50
leseb-pip...23:50
morganfainbergsorry :(23:50
morganfainbergpip ! bad pip! no cookie!23:51
leseb-enough for today, thanks for your time morganfainberg ;)23:52
*** timcline has quit IRC23:54
*** rm_work is now known as rm_work|away23:54

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