Wednesday, 2014-12-17

*** marcoemorais has joined #openstack-keystone00:01
*** _cjones_ has joined #openstack-keystone00:04
*** andreaf has quit IRC00:05
*** lufix has quit IRC00:05
*** andreaf has joined #openstack-keystone00:22
*** dims has quit IRC00:27
*** dims has joined #openstack-keystone00:28
*** _cjones_ has quit IRC00:30
*** dims has quit IRC00:32
*** _cjones_ has joined #openstack-keystone00:39
*** lhcheng_ is now known as lhcheng00:50
*** _cjones_ has quit IRC00:51
*** _cjones_ has joined #openstack-keystone00:55
*** timcline has joined #openstack-keystone00:57
*** Tahmina has quit IRC00:58
*** dims has joined #openstack-keystone00:59
*** rm_work is now known as rm_work|away01:05
*** nellysmitt has joined #openstack-keystone01:13
*** nellysmitt has quit IRC01:18
*** _cjones_ has quit IRC01:20
*** _cjones_ has joined #openstack-keystone01:29
*** _cjones_ has quit IRC01:38
*** timcline has quit IRC01:40
*** marcoemorais has quit IRC01:41
openstackgerritMerged openstack/keystone: Check and delete for policy_association_for_region_and_service  https://review.openstack.org/14012201:43
openstackgerritwanghong proposed openstack/keystone: set endpoint enabled default to True if not specified(kvs)  https://review.openstack.org/13995801:45
*** gordc has joined #openstack-keystone01:46
*** mitz has quit IRC01:47
wanghong@bknudson, still here?01:47
*** mitz has joined #openstack-keystone01:52
*** dims has quit IRC01:55
*** dims has joined #openstack-keystone01:56
*** gyee has quit IRC01:57
openstackgerritwanghong proposed openstack/keystone: don't allow user to add role on disabled project or domain  https://review.openstack.org/14174601:58
*** _cjones_ has joined #openstack-keystone01:58
*** dims has quit IRC02:00
*** _cjones_ has quit IRC02:03
*** erkules_ has joined #openstack-keystone02:05
*** erkules has quit IRC02:07
*** diegows has quit IRC02:09
openstackgerritwanghong proposed openstack/keystone: invalidate cache when updating catalog objects  https://review.openstack.org/14207902:11
openstackgerritwanghong proposed openstack/keystone: remove assignments for foreign actors when deleting domain  https://review.openstack.org/12743302:18
*** gordc has quit IRC02:21
*** gokrokve has joined #openstack-keystone02:24
*** LinstatSDR has joined #openstack-keystone02:27
*** mitz has quit IRC02:37
*** mitz has joined #openstack-keystone02:37
*** hdd has quit IRC02:56
*** arif-ali has quit IRC02:58
*** zzzeek has quit IRC03:00
*** arif-ali has joined #openstack-keystone03:01
*** timcline has joined #openstack-keystone03:04
*** timcline has quit IRC03:04
*** timcline has joined #openstack-keystone03:04
openstackgerritwanghong proposed openstack/keystone: Can't update catalog objects when using kvs driver  https://review.openstack.org/13018003:05
*** timcline has quit IRC03:08
*** timcline has joined #openstack-keystone03:10
openstackgerritwanghong proposed openstack/keystone: set endpoint enabled default to True if not specified(kvs)  https://review.openstack.org/14231603:12
*** Krast has quit IRC03:13
*** LinstatSDR has quit IRC03:14
*** nellysmitt has joined #openstack-keystone03:14
*** timcline has quit IRC03:14
*** timcline has joined #openstack-keystone03:15
*** Shohei has quit IRC03:16
*** timcline has quit IRC03:17
*** Shohei has joined #openstack-keystone03:17
*** timcline has joined #openstack-keystone03:17
*** nellysmitt has quit IRC03:19
*** Shohei has quit IRC03:21
*** lhcheng has quit IRC03:22
*** harlowja is now known as harlowja_away03:25
*** richm1 has quit IRC03:27
*** timcline has quit IRC03:28
openstackgerritwanghong proposed openstack/keystone: add circular check when updating region  https://review.openstack.org/13047403:30
openstackgerritwanghong proposed openstack/keystone: add circular check when updating region  https://review.openstack.org/13047403:32
*** Shohei has joined #openstack-keystone03:33
openstackgerritMerged openstack/keystone: Fix update role without name using LDAP  https://review.openstack.org/14118603:34
openstackgerritMerged openstack/keystone: Add tests for enabled attribute ignored  https://review.openstack.org/14089503:35
openstackgerritMerged openstack/keystone: Fix disabling entities when enabled is ignored  https://review.openstack.org/14110103:35
openstackgerritMerged openstack/keystone: Add a test for modifying a role to set the name the same  https://review.openstack.org/14123403:35
openstackgerritMerged openstack/keystone: Fix modifying a role with same name using LDAP  https://review.openstack.org/14123503:35
*** timcline has joined #openstack-keystone03:37
*** timcline has quit IRC03:38
openstackgerritMerged openstack/keystone: Remove XML support  https://review.openstack.org/12573803:43
*** chrisshattuck has joined #openstack-keystone03:46
*** gokrokve has quit IRC03:50
*** mitz has quit IRC03:50
openstackgerritSteve Martinelli proposed openstack/keystone: Update docs to no longer show XML support  https://review.openstack.org/12575303:51
stevemarlbragstad, your patch just -1'ed everyone's stuff03:53
stevemarhehe03:53
stevemarmerge conflicts for all!03:53
lbragstadstevemar: muahahah03:53
stevemarlbragstad, so that was your plan all along03:53
* lbragstad has been planning that for *months*03:54
stevemar!!!!03:54
openstackstevemar: Error: "!!!" is not a valid command.03:54
stevemarscrew you openstack03:54
lbragstadlol03:54
stevemarlbragstad, now review https://review.openstack.org/125753 :P03:54
lbragstadstevemar: if patches lived in trees, and branches were failures, 125738 hit every single one on the way down03:55
stevemaroh yeah03:55
stevemarlbragstad, oh this one is super easy too03:56
stevemarhttps://review.openstack.org/#/c/142192/03:56
*** _cjones_ has joined #openstack-keystone03:57
lbragstadstevemar: looks good03:58
stevemaryee haw03:58
lbragstad.. weird...03:59
lbragstadwe no longer have XML03:59
*** mitz has joined #openstack-keystone03:59
stevemarlbragstad, that's a good thing04:01
*** Shohei_ has joined #openstack-keystone04:05
*** Shohei has quit IRC04:07
*** mitz has quit IRC04:15
*** mitz has joined #openstack-keystone04:16
*** _cjones_ has quit IRC04:23
*** _cjones_ has joined #openstack-keystone04:24
*** stevemar has quit IRC04:30
*** hdd has joined #openstack-keystone04:34
*** mitz has quit IRC04:42
*** hdd_ has joined #openstack-keystone04:42
*** hdd has quit IRC04:43
*** mitz has joined #openstack-keystone04:45
*** andreaf has quit IRC04:45
*** andreaf has joined #openstack-keystone04:46
morganfainberg!!!!04:50
openstackmorganfainberg: Error: "!!!" is not a valid command.04:50
morganfainberg!!04:50
openstackmorganfainberg: Error: "!" is not a valid command.04:50
morganfainberg!omg04:50
openstackmorganfainberg: Error: "omg" is not a valid command.04:50
*** lvh has quit IRC04:55
*** gabriel-bezerra has quit IRC04:57
*** jamiec has quit IRC04:57
*** lvh has joined #openstack-keystone04:58
*** gabriel-bezerra has joined #openstack-keystone04:58
*** jbonjean has quit IRC04:58
*** jbonjean has joined #openstack-keystone04:58
*** jamiec has joined #openstack-keystone05:02
*** tellesnobrega has quit IRC05:03
*** tellesnobrega has joined #openstack-keystone05:04
*** wpf1 has quit IRC05:07
*** _cjones_ has quit IRC05:10
*** mitz has quit IRC05:12
*** mitz has joined #openstack-keystone05:13
*** mitz has quit IRC05:14
*** nellysmitt has joined #openstack-keystone05:15
*** lhcheng has joined #openstack-keystone05:15
*** mitz has joined #openstack-keystone05:16
*** hdd_ has quit IRC05:19
*** nellysmitt has quit IRC05:19
*** mitz has quit IRC05:20
*** mitz has joined #openstack-keystone05:21
*** sluo_wfh has joined #openstack-keystone05:23
*** lhcheng has quit IRC05:23
*** lhcheng has joined #openstack-keystone05:23
*** mitz has quit IRC05:31
*** _cjones_ has joined #openstack-keystone05:32
*** mitz has joined #openstack-keystone05:34
*** jaosorior has quit IRC05:43
*** rushiagr_away is now known as rushiagr05:47
*** mitz has quit IRC05:51
*** mitz has joined #openstack-keystone05:52
*** ajayaa has joined #openstack-keystone05:53
*** mitz has quit IRC06:00
*** mitz has joined #openstack-keystone06:00
*** mitz has quit IRC06:03
*** hdd has joined #openstack-keystone06:03
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/13624306:06
*** wanghong has quit IRC06:16
*** chrisshattuck has quit IRC06:17
*** ajayaa has quit IRC06:30
*** avozza is now known as zz_avozza06:32
*** wanghong has joined #openstack-keystone06:34
*** dims has joined #openstack-keystone06:34
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Cleanup exceptions  https://review.openstack.org/14224306:37
*** dims has quit IRC06:39
*** hdd has quit IRC06:41
*** rm_work|away is now known as rm_work06:43
*** _cjones_ has quit IRC06:48
*** _cjones_ has joined #openstack-keystone06:49
*** marcoemorais has joined #openstack-keystone06:52
*** _cjones_ has quit IRC06:53
*** marcoemorais1 has joined #openstack-keystone06:54
*** marcoemorais has quit IRC06:56
*** ajayaa has joined #openstack-keystone06:57
*** nellysmitt has joined #openstack-keystone07:16
*** pcaruana has joined #openstack-keystone07:16
*** ncoghlan has joined #openstack-keystone07:17
*** abhirc has quit IRC07:20
*** rm_work is now known as rm_work|away07:20
*** nellysmitt has quit IRC07:21
*** lhcheng has quit IRC07:25
*** lhcheng has joined #openstack-keystone07:26
*** lhcheng has quit IRC07:30
openstackgerritMarek Denis proposed openstack/python-keystoneclient: Standardize token scoping workflow.  https://review.openstack.org/14237608:00
*** Shohei_ has quit IRC08:01
*** Shohei has joined #openstack-keystone08:02
*** Shohei_ has joined #openstack-keystone08:03
*** Shohei has quit IRC08:04
openstackgerritwanghong proposed openstack/keystonemiddleware: support micro version if sent  https://review.openstack.org/13091608:07
rushiagr!time08:08
openstackrushiagr: Error: "time" is not a valid command.08:08
*** erkules_ is now known as erkules08:11
*** wanghong has quit IRC08:17
*** rushiagr is now known as rushiagr_away08:20
*** nellysmitt has joined #openstack-keystone08:23
*** wanghong has joined #openstack-keystone08:31
*** lhcheng has joined #openstack-keystone08:34
*** lhcheng has quit IRC08:38
openstackgerritwanghong proposed openstack/keystonemiddleware: fallback to online validation if offline validation fails  https://review.openstack.org/13103608:39
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Cleanup exceptions  https://review.openstack.org/14224308:45
*** Shohei_ has quit IRC08:57
*** ncoghlan has quit IRC08:59
*** lhcheng has joined #openstack-keystone09:08
*** marcoemorais1 has quit IRC09:16
*** zz_avozza is now known as avozza09:23
*** rushiagr_away is now known as rushiagr09:27
*** f13o has quit IRC09:47
*** lhcheng has quit IRC09:53
*** avozza is now known as zz_avozza09:59
*** jamielennox is now known as jamielennox|away10:04
*** sluo_wfh has quit IRC10:07
*** zz_avozza is now known as avozza10:08
openstackgerritDave Chen proposed openstack/keystone: Reference with the correct region id in `Region` table {WIP}  https://review.openstack.org/14241110:14
*** aix has joined #openstack-keystone10:21
*** jamielennox|away is now known as jamielennox10:21
*** diegows has joined #openstack-keystone10:26
*** f13o has joined #openstack-keystone10:34
*** jamielennox is now known as jamielennox|away10:51
bretonhow do I get my bp approved?11:37
samuelmsbreton, hi11:53
samuelmsbreton, so you have to submit a spec to keystone-specs11:53
samuelmsbreton, and then you will get reviews on that11:54
samuelmsbreton, as we do for code11:54
samuelmsbreton, an example is https://review.openstack.org/#/c/133855/11:54
*** dims has joined #openstack-keystone11:55
bretonsamuelms: so, when spec gets merged, bp is automatically accepted?12:08
bretonI'm also not sure that a spec is needed12:09
bretontoo bad I wrote it today, not before yesterday's meeting :(12:09
samuelmsbreton, well, once a spec is accepted, we still need to define the bp milestone12:13
samuelmsbreton, and then get it accepted12:13
samuelmsbreton, but spec merged is a prerequisite12:13
*** afazekas has joined #openstack-keystone12:21
*** jorge_munoz has quit IRC12:29
*** jorge_munoz has joined #openstack-keystone12:30
*** jasondotstar has quit IRC12:31
*** aix has quit IRC12:42
*** lhcheng has joined #openstack-keystone12:54
openstackgerritLance Bragstad proposed openstack/keystone: Implement validation on the Identity V3 API  https://review.openstack.org/13212212:55
*** lhcheng has quit IRC12:58
openstackgerritLance Bragstad proposed openstack/keystone: Add positive test case for content types  https://review.openstack.org/13059113:16
*** rushiagr is now known as rushiagr_away13:19
*** rushiagr_away is now known as rushiagr13:19
*** afazekas has quit IRC13:20
openstackgerritLance Bragstad proposed openstack/keystone: Tests assert 200 on POST operations instead of 201  https://review.openstack.org/14244013:23
lbragstadbknudson: I did some checking in test_content_types.py and there are several POST operations that assert 200 instead of 201.13:24
lbragstadbknudson: is that something about the v2.0 that I just don't know about?13:25
*** afazekas has joined #openstack-keystone13:26
openstackgerritLance Bragstad proposed openstack/keystone: Tests assert 200 on POST operations instead of 201  https://review.openstack.org/14244013:33
*** aix has joined #openstack-keystone13:35
*** jbonjean has quit IRC13:35
*** rushiagr is now known as rushiagr_away13:39
*** rushiagr_away is now known as rushiagr13:40
samuelmsbreton, but spec merged is a prerequisite13:44
*** rushiagr is now known as rushiagr_away13:44
samuelmsbreton, well.. sorry, just repeated last message :p13:44
*** rushiagr_away is now known as rushiagr13:46
*** hdd has joined #openstack-keystone13:50
*** radez_g0n3 is now known as radez14:11
morganfainbergso we have a K1 tag14:14
raildomorganfainberg, great :)14:15
morganfainbergraildo thanks to everyone working so hard on the HMT stuff14:15
rodrigodsmorganfainberg, raildo \o/14:16
raildomorganfainberg, no problem :) Thank you for the help all this time!14:16
raildorodrigods, \o/14:16
rodrigodsmorganfainberg, heard that we are close to a client release? Can be this considered: https://review.openstack.org/#/c/115770/12 ?14:23
thiagopmorganfainberg: Our team also have this urge to bring HMT stuff to the end user on Horizon ASAP. Maybe you can take a look on this^ to help speed things up14:24
*** richm1 has joined #openstack-keystone14:26
*** richm1 has left #openstack-keystone14:27
*** richm1 has joined #openstack-keystone14:28
*** hdd has quit IRC14:36
*** ajayaa has quit IRC14:41
*** gordc has joined #openstack-keystone14:41
*** pcaruana has quit IRC14:51
openstackgerritBrant Knudson proposed openstack/keystone: Fix tests using extension drivers  https://review.openstack.org/12460314:51
openstackgerritBrant Knudson proposed openstack/keystone: Avoid multiple instances for a provider  https://review.openstack.org/12459914:51
raildodstanek, I answered your questions in the reseller spec, and I asked a few questions to you in the spec.  https://review.openstack.org/#/c/139824/8/specs/kilo/reseller.rst14:53
openstackgerritBrant Knudson proposed openstack/keystone: Move eventlet server options to a config section  https://review.openstack.org/13096214:55
marekddstanek: gabriel-bezerra can you please look into /var/log/shibboleth/signature.log files and tell me if you have anything there?14:56
marekddstanek: gabriel-bezerra provifing you have used pysaml2 as idp only.14:56
morganfainbergthiagop: hi. I am planning on reviewing that today.14:56
dstanekmarekd: i'll all good now - i just never got the mapping completed - assuming that there are attributes in the assertion14:56
dstanekraildo: looking now14:56
thiagopmorganfainberg: glad to hear it. Thanks14:56
raildodstanek, thanks14:57
morganfainbergrodrigods: I am going to start the process of the client release in a few minutes. Basically If it hasn't merged in an hour or so, I don't think it'll be in there.14:57
marekddstanek: but still without validating assertion signature, right?14:57
rodrigodsmorganfainberg, ok... will ask for reviews :)14:57
dstanekmarekd: no, i'm validating OK14:57
morganfainbergI'm looking at it now.14:58
rodrigodsdstanek, bknudson, have a moment to take a look the client HMT part? https://review.openstack.org/#/c/115770/1214:58
marekdmorganfainberg: do you think Service Providers spec will also land in K1 ?14:59
marekdmorganfainberg: it's https://review.openstack.org/#/c/135604/15:00
morganfainbergNot in k115:00
marekddeadline is not tmrw?15:00
morganfainbergK1 is tomorrow officially. We have a tag already.15:00
dstanekraildo: i don't understand you comment about two tables? can a project with domainness hold resources like any other project or does it just act like a domain?15:00
*** stevemar has joined #openstack-keystone15:00
*** ChanServ sets mode: +v stevemar15:00
morganfainbergmarekd: well if it's gating yes. But spec approval in k1 or shortly after is no big deal.15:00
morganfainbergK2 is our spec proposal deadline.15:01
marekdmorganfainberg: ok then.15:01
morganfainbergmarekd: so I'm not rushed to squeeze a spec in last minute just for it to be in k1 :)15:01
morganfainbergNot that I would say it can't be in k115:01
raildodstanek, project with domainess will working like a "normal' project but can working like a domain too15:01
marekdmorganfainberg: SPs are already lots of +1 and two +2s so it's a matte of +A i guess15:01
marekdbut its up to you15:02
morganfainbergOh. Hm. Let me 2x check then15:02
morganfainbergWhen I get to the coffee shop I'm camping at today, I'll take a look. Might press +a before doing client release then.15:02
dstanekraildo: hmmm, i thought that it didn't - do a project can have users, vms and other projects that contains vms?15:03
raildodstanek, yes :)15:03
morganfainbergmarekd: the only question I have is your answer to the question to ecp vs SSO.15:04
raildoa project with the domainess flag enabled can do that15:04
morganfainbergI think it's fine as is, but I'd like a response to that comment before I +a15:04
dstanekraildo: :-( confusing15:05
samuelmsmorganfainberg, I've found a bug on inherited functionality15:05
samuelmsmorganfainberg, bug #140353915:05
uvirtbotLaunchpad bug 1403539 in keystone "Can't create both inherited and direct role assignment on same entities" [Undecided,New] https://launchpad.net/bugs/140353915:05
raildodstanek, hahaha maybe I can explain better15:05
samuelmsmorganfainberg, it affects inherited functionality on both domains and (now) projects15:05
samuelmsdstanek, please also take a look at this bug ^15:06
samuelmsrodrigods, ^15:06
rodrigodssamuelms, ++15:07
dstanekraildo: i don't think you need to explain it anymore - it feels weird form a consumer standpoint because you are reselling something to me that doesn't act like a domain or a project. so blogs/docs/etc will be confusing for me15:07
dstaneksamuelms: do you really need to grant it twice? would it be better to have the inherited value of the existing assignment?15:08
dstaneksamuelms: i'm just thinking from an admin's point of view looking at horizon15:09
samuelmsdstanek, inherited flag just applies to subtree/projects under domain15:09
samuelmsdstanek, it doesnt apply to the target itself15:09
*** timcline has joined #openstack-keystone15:09
raildodstanek, I'm reselling for you a project/domain, So you can use this to user management(create user, groups and roles) and for control your resources. Is this weird?15:09
*** ayoung has joined #openstack-keystone15:11
*** ChanServ sets mode: +v ayoung15:11
openstackgerritBrant Knudson proposed openstack/keystone: Remove test PYTHONHASHSEED setting  https://review.openstack.org/13659315:12
openstackgerritBrant Knudson proposed openstack/keystone: Correct version tests for result ordering  https://review.openstack.org/13892315:12
stevemarrodrigods, marekd, confirmed that the k2k user name issue was a bad mapping15:12
stevemari'll send an email with a good mapping15:13
rodrigodsstevemar, ++15:14
rodrigodsthanks15:14
stevemarnp15:14
dstaneksamuelms: then it's probably a valid bug - i'm interested to see how horizon shows it to the user because having a role on a thing that doesn't apply to the thing feels like it will be hard for users15:14
dstanekraildo: in that it can act like both yes15:14
rodrigodsdstanek, about the horizon part, you may refer to thiagop15:15
marekdstevemar: can you be more specific?15:15
rodrigodsdstanek, we are working in a design to better handle those cases (currently I *think* Horizon doesn't support inherited roles)15:15
thiagoprodrigods dstanek no, it doesn't.15:16
openstackgerritAlexander Makarov proposed openstack/keystone: LDAP additional attribute mappings description  https://review.openstack.org/11859015:16
stevemarmarekd, the mapping should look like this: http://paste.openstack.org/show/152289/15:16
dstanekstevemar: my plan today was to finish up what i have completed on federation so i can push it (still work to be done) and then move the automating a k2k setup so that i can help debug the assertion signature issue15:16
samuelmsdstanek, I guess horizon will show a tree, where a user should be able to select a project but the root one (except if he has an explicit role assignment there)15:17
samuelmsdstanek, but yes, that sounds strange15:17
stevemarmarekd, instead of: http://paste.openstack.org/show/152290/15:17
thiagopwe are working on a way to do that in way that it clarify for the users more than confuses them15:18
stevemardstanek, nice, i had a guy internally try it all out, i was surprised he did it so quickly15:18
openstackgerritBrant Knudson proposed openstack/keystone: Avoid multiple instances for a provider  https://review.openstack.org/12459915:18
dstanekstevemar: would it be OK if they ran on the same some and shared everything except keystone.conf?15:19
dstanekstevemar: same certs, etc...15:19
dstanekstevemar: different DBs, of course15:19
amakarovayoung, hi! I hope we can continue with trusts :) Can you please take a look at the spec? https://review.openstack.org/#/c/131541/15:19
stevemardstanek, oh good question, i'm not sure, we used two VMs15:20
dstanekstevemar: ok, well i guess i'll let you know then :-)15:20
marekdstevemar: yeah, that's why i opened this bug: https://bugs.launchpad.net/keystone/+bug/140105715:23
uvirtbotLaunchpad bug 1401057 in keystone "Direct mapping in mapping rules don't work with keywords" [Undecided,New]15:23
stevemarmarekd, good description ++15:27
*** jbonjean has joined #openstack-keystone15:30
*** hdd has joined #openstack-keystone15:32
stevemarthere seems to be a bug in a bunch of the python-*clients15:35
stevemarhttp://logs.openstack.org/79/142379/1/check//gate-python-openstackclient-python33/9de9d8a/console.html unable to build py33, related to docutils15:36
*** tellesnobrega has quit IRC15:38
*** topol has joined #openstack-keystone15:41
*** ChanServ sets mode: +v topol15:41
morganfainbergok i'm about to release python-keystoneclient15:42
morganfainbergis there *anything* we're waiting on here?15:42
lbragstadwhat about https://review.openstack.org/#/c/130159/15:42
morganfainbergayoung, dolphm, dstanek, jamielennox|away, bknudson, topol, stevemar, rodrigods, marekd, lbragstad, ^15:42
morganfainberglbragstad, no bug/no bp and it's not clear to me why it's needed15:43
lbragstadmorganfainberg: it's on dolphm's gist https://gist.github.com/dolph/651c6a1748f69637abd015:43
morganfainbergwe can release again once we get it.15:43
lbragstadok15:43
lbragstadcurious15:43
stevemarmorganfainberg, things aren't exactly building at the moment15:43
morganfainbergstevemar, gate?15:43
morganfainbergstevemar, or broken ksc?15:44
topolmorganfainberg, 130159? It has two -1's on it.15:44
stevemarmorganfainberg, no, something is hitting all clients, py33 jobs15:44
stevemarhttps://review.openstack.org/#/q/project:openstack/python-keystoneclient,n,z15:44
stevemarmorganfainberg, it doesn't stop you from releasing, but it'll be a PITA if theres something wrong, and we are still stuck here15:45
morganfainbergstevemar, http://logs.openstack.org/44/141944/1/check//gate-tempest-dsvm-neutron-src-python-keystoneclient/c3b4bb9/console.html#_2014-12-16_21_05_56_45015:45
morganfainbergstevemar, i can wait to push the tag. nbd15:45
bknudsonhttps://review.openstack.org/#/c/132240/15:45
morganfainbergi've already staged everything for the release so it's now just tag + release.15:45
marekdmorganfainberg: i don't wait with anything close-to-be-merged to hold the release15:46
morganfainbergmarekd, well sometimes there is something critical that is gating15:46
morganfainbergso worth checking :)15:46
marekdmorganfainberg: i will need to drag some attention to few aspects in keystoneclient but not now.15:46
marekdmorganfainberg: sure, i am just not shouting STOP15:46
morganfainbergbknudson, that one would be worth grabbing.15:46
morganfainbergmarekd, ack15:46
dstanekmarekd: try that link again15:46
bknudsonhttps://review.openstack.org/#/c/118383/15:46
marekddstanek: sure15:46
dstanekmarekd: that should be my current working config15:47
morganfainbergbknudson, ++ ok reviewing those two now.15:47
dstanekmarekd: i've changed so much all over the place that i'm trying to gather everything together so i can reproduce this on another node using only the automation15:47
*** LinstatSDR has joined #openstack-keystone15:47
bknudsonhttps://review.openstack.org/#/c/131408/ maybe15:47
morganfainbergbknudson, both look like they're worth seeing if we can land before the release.15:48
marekddstanek: thanks a lot15:48
marekdi am going to check it now.15:48
*** diegows has quit IRC15:48
morganfainbergbknudson, hmm15:48
LinstatSDRGood morning guys.15:48
dstanekmarekd: let me know :-)15:48
marekddstanek: sure.15:48
morganfainbergbknudson, if we can land the last one i'll wait for it. if we can't i'm ok with another release in early jan to inclue it.15:49
morganfainbergbknudson, same with the HMT client code15:49
bknudsony, no reason we can't have another release tomorrow.15:49
morganfainbergwe can15:49
morganfainberg:)15:49
morganfainbergbut the first two you linked i think are worth really trying to land before this release15:50
dstanekmorganfainberg: i have nothing specific that i'd like in the release15:51
morganfainbergdstanek, thanks.15:51
marekddstanek: i owe you a beer15:52
marekdwhenever we meet next time :-)15:53
morganfainbergstevemar, on,y +1  on https://review.openstack.org/#/c/118383/18 ?15:53
dstanekmarekd: i love it when a plan comes together15:53
marekd:D15:53
* marekd stupid15:53
stevemarmorganfainberg, because i like it but need to look at it more15:54
morganfainbergah.15:54
stevemarmorganfainberg, meh, i'll send an email out to the list about the client failures, i can't seem to get any traction on the channels15:57
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Adds inherited column to RoleAssignment PK  https://review.openstack.org/14247215:58
samuelmsmorganfainberg, ^15:58
morganfainbergsamuelms, oh boy15:58
dstanekbknudson:  looking at the new test in https://review.openstack.org/#/c/118383/18/keystoneclient/tests/v3/test_service_catalog.py and i have no idea what cases are being tested15:59
samuelmsmorganfainberg, catch that when working on tests improvement for list role assignments16:00
bknudsondstanek: the monkey-patching is weird!16:00
samuelmsmorganfainberg, looks like we always had this bug, since Jul 5, 2013 when inherited role assignments to domains were introduced16:02
marekdstevemar: https://bugs.launchpad.net/keystone/+bug/1401057 do you think my comment (and the proposition for the solution at the same time) is valid?16:02
uvirtbotLaunchpad bug 1401057 in keystone "Direct mapping in mapping rules don't work with keywords" [Undecided,New]16:03
morganfainbergbknudson, i've been staring at the monkeypatching16:03
stevemarmarekd, i think so, when i first saw the mapping i thought it was invalid, so i was expecting a 40X error16:04
morganfainbergmarekd, stevemar, just responded to the email as well.16:05
morganfainbergdstanek, yeah i am unsure about those tests16:06
lbragstadin case anyone's looking for an easy review https://review.openstack.org/#/c/125753/16:10
morganfainbergooh boy16:11
morganfainberglooks like zuul is backed up16:12
morganfainbergnot sure why though16:12
lbragstadlol http://gatewatch.dolphm.com/16:14
lbragstadwell that escalated quickly16:14
dstanekraildo: so are you saying that any project with domain-ness will have a corresponding domain of the same name?16:19
*** gordc has quit IRC16:23
ayoungmorganfainberg, sorry, was in a meeting...as far as I am concerned, there is nothing we are waiting on for a new release.  The Client has the most important changes to support V3 everywhere:  non-default-domains for service users.  I'd like to get that out there ,as there is going to be deployment work that needs to be done based on it16:24
morganfainbergayoung, no worries16:24
ayoungthere will always be more client work to be done, so  lets not hold up this bus;  the next bus is coming16:24
morganfainbergayoung, just was asking before doing the release. i'm giving a couple of patches chances to merge before tagging (and waiting for the gate to get below "wedged" looking)16:25
ayoungsounds good to me16:25
morganfainbergayoung, if something is already gateing it sometimes is worth waiting.16:25
ayoungmorganfainberg, jamielennox|away and I explicitly discussed this yesterday.  The things we need are in the client already.16:25
morganfainbergayoung, so that was more of a "do we have something that you're pushing into gate now and we should wait for"16:25
morganfainbergworst case i release it tonight16:25
morganfainbergayoung, great16:25
morganfainbergayoung, i've staged client and middleware milestones16:25
ayoungvery good16:26
morganfainbergayoung, i'm bumping ksc to 1.0.0 as a procedural thing16:26
ayoung++16:26
morganfainbergayoung, i'll put 2.0.0 as a new release for future "if we're breaking compat" things and SDK doesn't end up being the place we go16:26
ayoungyep16:26
marekdstevemar: https://review.openstack.org/#/c/130564 please :-)16:27
morganfainbergnkinder, i really want to get no-rescope tokens in kilo16:27
morganfainbergnkinder, (re: the scoped token provides no benefit)16:27
stevemarclassic nkinder, affected versions: ALL THE VERSIONS16:31
nkinderstevemar: :)16:31
ayoungmorganfainberg, you mean "explicitl request unscoped tokens"?16:32
nkindermorganfainberg: I really want that too16:32
morganfainbergayoung, no the "you can't rescope a scoped token"16:32
nkinderayoung: restricting scope changes16:32
ayoungmorganfainberg, we need the other first16:32
nkinderyes, they are hand-in-hand16:32
morganfainbergayoung, the explicit unscoped token fix may be needed as well, but the one i am more interested in seeing (from a security perspective) is restricted rescoping16:32
ayoungmorganfainberg, the horizon code needs to know that it is getting an unscoped token, and not revoke that when switching projects16:33
morganfainbergdolphm, ping - I can't change the active development series in ksc16:33
morganfainbergdolphm, in LP16:33
morganfainbergdolphm, any thing you can do?16:33
morganfainbergayoung, i realize it ;) i think we're in vehement agreement here :P16:33
ayoungThe thing we needed to nail down was how to specify that we were requesting an unscoped token.  I think it is important that the Scope portion of the request be there, so that an older Keystone server that doesn't support can report the error16:33
ayoungOK...I can focus on that for a bit.16:34
morganfainbergayoung, don't let that take you away from something you're elbow deep in. We can work on the scoped/unscoped stuff over k2, it's not a drop everything to get it done thing :)16:35
morganfainbergayoung, i know sometimes jumping around makes it harder to get things landed (even when the gate isn't... wonky)16:35
ayoungmorganfainberg, nah, its on my list, and important for our teams priorities16:35
morganfainbergayoung, ack16:36
ayoungI have a bunch of the policy work under way, and so can continue to revise as I get this going.16:36
morganfainbergayoung, just tyring to lookout for both your bandwidth as well as what is needed - you scale about as well as I do :P16:36
ayoungFewer demands on me16:36
morganfainbergi think the priority over the next couple weeks is to land the specs.16:36
morganfainbergso midcycle is addressing the contentious specs, working through roadblocks on the current specs, etc16:37
morganfainbergand figuring if we have any SPD exceptions16:37
ayoungmorganfainberg, what did you suggest again?  "scope":"unscoped"  doesn't quite ring true16:40
morganfainbergayoung, there were two specs^w^wthree specs16:40
morganfainbergayoung, explicit unscoped, you can't rescope a scoped token, session token (unscoped token extensions)16:41
ayoungmorganfainberg, just for the request body16:41
morganfainbergayoung, oh16:41
morganfainberguh16:41
ayoungexplicit unscoped16:41
ayoungit got approved16:41
morganfainbergi think we actually said scope: nil16:41
morganfainbergor whatever the json equiv, None? is16:41
ayounghttp://git.openstack.org/cgit/openstack/keystone-specs/tree/specs/kilo/explicit-unscoped.rst16:41
morganfainbergi don't think we said "unscoped" . but tbh, it wouldn't matter which one (i do prefer using None and Nil type constructs where possible vs. arbitrary strings, but this is pure personal taste)16:42
ayoungmorganfainberg, so I don't want to make it None for fear of confusing things on the Python side;  None vs "None"  is nasty.  It needs to be an explicit value, not "nothing specified in scope"  as that will break things16:45
ayoungI'll start with "unscoped" for now16:46
morganfainbergayoung, it depends on how Keystone handles that - but sure.16:46
morganfainbergayoung, like i said, i'd be fine with either, slight personal preference isn't a huge factor16:46
topolmorganfainberg is there a priority list of what keystone-specs need to be reviewed?16:47
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/controllers.py#n22416:47
* topol please dont say all of them.. please dont say all of them... :-)16:48
morganfainbergtopol, i'd say there are three on my short list and then the ones that we discussed at the summit16:48
topolmorganfainberg, K, whats the short list?16:49
morganfainbergtopol, short list: LDAP r/w (rax proposal, and they are very comitted to making that a reality) - no it wont break/change the current r/w model.16:49
morganfainbergtopol, AE Tokens (anything besides ayoung's concerns, we'll circle up on those), the SP / K2K ones (from marek),16:49
morganfainbergand the HMT next steps (reseller)16:50
topolmorganfainberg, OK, got it16:50
morganfainbergtopol, we have plenty that should be doable in K16:50
topolmorganfainberg, Yeah there is a lot there16:50
morganfainbergbut those are the big-work ones, i left policy stuff ayoung is working on off the list because i know it's on the radar but i want him to drive the reviews on it - i knwo they've been a WIP on and off16:51
morganfainbergand the policy ones will likely split between kilo and L16:51
morganfainbergthere is just so much in them16:51
ayoungpolicy is a long slog.  We'll get something into K, but keep moving in L.  I suspect the full thing will be there in L16:52
morganfainbergscafolding and basics in K, build on and improve in L16:52
ayoungHeh16:52
morganfainbergayoung, ++ exactly16:52
morganfainbergayoung, haha see we are on the same page about that stuff ;)16:52
topolmorganfainberg, on https://review.openstack.org/#/c/140175/9/specs/kilo/read-write-ldap-drivers.rst I was just waiting for the spec author to push a patch that confirms what you said in your comment, viz. that downgrades will be supported16:54
morganfainbergtopol, yeah you asked for the short list16:54
morganfainbergtopol, i talked with them yesterday16:54
morganfainberggave them feedback and asked them to look for RFC on ldap schema to reference for this stuff16:55
morganfainbergmy understanding w/o hunting for an RFC (i'll do that this weekend) is that once defined the schema definitions shouldn't be changed, oids are effectively free16:55
morganfainbergmake a new oid if you need to change things that would be incompatible (new MAYs are ok)16:56
*** packet has joined #openstack-keystone16:56
topolmorganfainberg, makes sense!  I'll wait for them to push a patch that addresses those aspects and then I think I'm good.16:57
* topol Did anyone notice my cool use of "viz." in a sentence? I decided to try and sound sophisticated today16:57
bknudsonnobody's going to be able to use something that requires new schema.16:58
amakarovstevemar, hello! I've noticed, you are the author of notification logic for role_assignment operations. I want to change it a little and curios, why so special treatment for role_assignment? https://review.openstack.org/#/c/141854/16:59
morganfainbergbknudson, for a pure read-write case, yes they will. if they're doing AD/LDAP read-only they can keep doing as they do now.17:00
morganfainbergbknudson, but it makes sense that if keystone is managing everything in the tree, it shouldn't be shoehorned around the default schema, we're within our rights to say "here is our schema that is full featured"17:01
bknudsonI guess for read-write we don't want anybody to do it anyways, so might as well require schema changes.17:01
*** harlowja_away is now known as harlowja17:01
morganfainbergbknudson, there are people who do read-write, adn this would also be for assignment17:01
morganfainbergbknudson, if we are supporting read-write we might as well make it not an afterthought17:01
*** cretz has quit IRC17:01
morganfainbergwhich is what it feels like now.17:01
bknudsonI think it's going to be too much work to treat it in the same class as sql.17:02
bknudsonor it's going to really limit what we can do even with sql17:02
stevemartopol, you trying to be fancy with your words?!17:02
bknudsonLDAP support is already way behind SQL.17:03
morganfainbergplease comment on the spec, since it's not approved17:03
lbragstadso my question on this is how to make it so that the ldap schema just doesn't grow and grow17:03
morganfainbergif you want direction they're going with that, please ask.17:04
morganfainbergthese are the kinds of things we need to answer before accepting the spec.17:04
morganfainberglbragstad, the SQL schema mostly just grows and grows.17:04
lbragstadbut with SQL we have the ability to provide migrations to change the representation of the data, if we have to17:05
morganfainberglbragstad, and that was why i asked them to go look for the RFC on that.17:05
morganfainberglbragstad, and migration framework might be a pre-req for this to be fully supported / non-expirimental17:05
topollbragstad, Great question!17:05
morganfainberglbragstad, so ask the question on the spec :)17:05
*** rm_work|away is now known as rm_work17:06
topolstevemar, I plan on trying to be sophisticated at lunch and get a drink with a small umbrella in it.  It is getting close to the holidays17:06
bknudsonthis is what I was hinting at -- we'll have to do migrations for LDAP just like we do migrations for SQL17:06
topolbknudson, I posted similar comments on the spec17:07
stevemartopol, hopefully that lunch happens after our meeting :)17:07
morganfainbergthe main reason this is on the short list is a) we generally agreed that it would be good to make ldap better and not this wierd mish-mash of read-only/read-write, b) we have a couple big players that use ldap-read-write, c) we have one that is willing to dedicate engineering resources to make it full-featured with full CI and address these challenges17:07
morganfainbergso, it's worth considering17:07
bknudsontopol: btw - I did try escargot and steak tartar while in paris.17:08
lbragstadmorganfainberg: I agree that it's worth considering, but from an LDAP perspective, how do the migrations work?17:08
topolbknudson, wow! and yet when you were here in Ralaigh you cringed when we suggested Indian food for lunch :-)17:08
morganfainberglbragstad, that is part of what was asked of the proposers17:09
bknudsontopol: I've had indian food... I like it but it doesn't like me.17:09
morganfainberglbragstad, it is a work item to figure out17:09
bknudsonwent to an Indian place in paris with dims and others and did find something that I could agree with.17:10
lbragstadmorganfainberg: I'm automatically hardcoded to think of migrations in terms of SQL :)17:10
dstanekugg...back to the tcp4 vs. tcp6 thing on ubuntu17:10
lbragstadI'll leave some comments on the spec17:11
morganfainberglbragstad, yeah this case the way i've handled that before is "new oid with script to move data from one object to another, if the object is incompat [chanigng/removing/adding MUSTs]17:11
topolmorganfainberg++.  The read write is important cuz folks are asking for it and are willing to work on it.  I think they just need to declare how they will tackle some issues.  I just remember the first time we tried this and made some mistakes (not enough stakeholder input) and I got torched by some folks at the Portland summit17:11
morganfainberglbragstad, new MAYs can be added [but not removed] easily17:11
morganfainbergtopol, exactly, people want ldap for $reasons$17:12
morganfainbergtopol, and i can come up with a ton of usecases (and where they tip over scale wise)17:12
lbragstadmorganfainberg: so, does this mean that the schema defined for R/W LDAP is *absolutely* minimal and everything that needs to be tweaked, is tweaked as a MAY?17:13
lbragstadI'll ask that on the spec too ^17:13
*** hdd has quit IRC17:13
morganfainbergtopol, but most people wont hit those limits and will benefit from ldap - it also pushes us towards being able to (potentially) drop SQL identity on the floor and continue towards federated identity solutions out of the box17:13
topolthinking through versioning and downgrading are good topics that I was nudging folks to address so they don't get torched like I did.  I still hear folks bitching about what we tried as an initial schema17:13
morganfainberglbragstad, i don't have an answer to that, i think that is part of the spec/design process we're doing now: determine those answers17:13
topolmorganfainberg, Yeah I am on board with this as well.17:14
lbragstadok17:14
*** jdennis1 has joined #openstack-keystone17:15
*** jdennis has quit IRC17:17
*** LinstatSDR has quit IRC17:17
topolmorganfainberg, stevemar, lbragstad,  the feedback on the first time we tried this is well characterized by the following simpsons clip: https://www.youtube.com/watch?v=IRm7utSYpwk17:17
*** LinstatSDR has joined #openstack-keystone17:18
* morganfainberg will need to wathc that later17:18
topolIts 20 seconds of screaming "what were you thinking"  Which is what we heard a lot in Portland :-)17:18
topolstevemar my lunch is after our 12:30 meeting17:19
morganfainberghaha17:20
morganfainbergwell i think that we can solve this nice and cleanly17:20
stevemartopol, excellent, then we will watch billy and the cloneasaurus17:20
topolstevemar did you figure that out with out looking at the clip?17:20
morganfainbergand i think if we look at it as a way to leverage the ldap implementations that make better IDPs (for the identity side at least) as our baseline, so we don't need to implement all the crazy idp-workflows, it'll be an easier sell17:21
morganfainbergtopol, i also think that the identity/assignment split will work in our favor this time, less trying to wedge everyhting into ldap if people don't want it17:21
topolmorganfainberg. I absolutely agree.  My comments on the sec I think are easily addressed given how things are today as opposed to back then17:22
topolerr on the spec17:22
dimsbknudson: glad to have your company :)17:22
*** gyee has joined #openstack-keystone17:23
*** ChanServ sets mode: +v gyee17:23
*** gyee has quit IRC17:24
*** gyee has joined #openstack-keystone17:25
*** ChanServ sets mode: +v gyee17:25
rodrigodsmorganfainberg, was afk (lunch time), did you trigger the client releaes?17:25
morganfainbergnope, waiting on some gate stuff17:25
rodrigodsmorganfainberg, ok the HMT patch didn't receive reviews =(17:26
*** _cjones_ has joined #openstack-keystone17:34
*** _cjones_ has quit IRC17:34
*** _cjones_ has joined #openstack-keystone17:34
morganfainbergrodrigods, we will at worst do another release in early january17:37
morganfainbergrodrigods, it still has time to get into the gate - i am definitely releasing tonight provided gate is happy [in case we have emergencies to fix it]17:37
rodrigodsok, thanks morganfainberg17:38
morganfainbergrodrigods, we could release another client tomorrow if we really wanted to17:39
*** marcoemorais has joined #openstack-keystone17:39
*** zzzeek has joined #openstack-keystone17:42
*** avozza is now known as zz_avozza17:42
rodrigodsayoung, bknudson, dolphm, stevemar, henrynash, gyee sorry for being asking for this, but since Keystone has the K1 tag and HMT is in it, we'd appreciate if this https://review.openstack.org/#/c/115770/ enter the next release from keystoneclient. We have some work in Horizon that directly depends on it. We are available for immediate fixes, if necessary.17:42
*** marcoemorais has quit IRC17:44
*** marcoemorais has joined #openstack-keystone17:44
*** marcoemorais1 has joined #openstack-keystone17:45
*** amakarov is now known as amakarov_away17:45
*** marcoemorais2 has joined #openstack-keystone17:45
*** marcoemorais1 has quit IRC17:46
*** marcoemorais2 has joined #openstack-keystone17:46
*** marcoemorais2 has quit IRC17:46
*** marcoemorais1 has joined #openstack-keystone17:46
*** marcoemorais has quit IRC17:49
gyeerodrigods, looking ...17:49
morganfainberggyee oh hi!17:50
morganfainberggyee, please weigh in on the LDAP read/write spec when you have a moment.17:50
morganfainbergquestions / concerns etc would be helpful.17:50
morganfainbergsamuelms, i'll need to look at that bug when i get a plug for my laptop17:50
openstackgerritayoung proposed openstack/keystone: Explicit Unscoped  https://review.openstack.org/14252117:50
morganfainbergrodrigods, raildo, had a great caipirinha on sunday night17:52
morganfainbergrodrigods, raildo, figured you'd apreciate it.17:52
*** diegows has joined #openstack-keystone17:52
rodrigodsmorganfainberg, yes! cachaça (the drink which caipirinha is made of) is really common in our region :)17:53
morganfainbergrodrigods, i know!17:53
morganfainbergrodrigods, i need to visit brazil!17:53
morganfainberg:)17:53
gabriel-bezerramarekd: that file is empty here.17:53
*** thedodd has joined #openstack-keystone17:54
rodrigodsmorganfainberg, we have an one month party in our city (in June), which cachaça is the typical drinking17:54
morganfainberghehe17:54
rodrigodsmorganfainberg, feel invited to come here to have some cachaça with us17:55
morganfainbergwill do. esp. if there is a business reason to be in brazil.17:55
morganfainberg:)17:55
morganfainbergok heading back to the hotel so that i can get my laptop plugged in...17:55
rodrigodsgyee, thanks, any comments we are ready here to fix them17:56
morganfainbergGoing to check on gate status and such when j get back and see about the releases.17:56
*** lhcheng has joined #openstack-keystone17:57
*** lhcheng_ has joined #openstack-keystone18:00
gyeemorganfainberg, sure, on  it18:01
*** thedodd has quit IRC18:01
*** lhcheng has quit IRC18:03
gyeerodrigods, I presume you have another patch for openstackclient?18:09
rodrigodsgyee, yes18:09
gyeeawesome18:09
rodrigodsgyee, currently marked as WIP, just waiting for the keystoneclient part to land :)18:10
gabriel-bezerramarekd, dstanek: have you got the attributes passed in the aassertion from the pysaml2 example IdP? I was having a look at its code to try to discover why it is not being passed18:11
gyeerodrigods, I see. I am kinda curious how you render the tree from CLI18:11
dstanekgabriel-bezerra: is it not being passed? i haven't gotten back to that yet18:12
rodrigodsgyee, I think we display a column with the ids18:12
rodrigodsgyee, If I remember correctly18:12
gyeerodrigods, no christmas tree?!! :)18:12
rodrigodsgyee, heh18:12
*** aix has quit IRC18:15
*** thedodd has joined #openstack-keystone18:15
dstanekgabriel-bezerra: did you verify that they are not being sent?18:18
*** lhcheng_ is now known as lhcheng18:18
gabriel-bezerradstanek: the haho0032 user, which has more info than any other, has only an attribute in the assertion: edupersontargetedid -> one!for!all18:19
dstanekgabriel-bezerra: there may be a config value that controls putting the attributes in there18:20
gabriel-bezerradstanek: I'm wondering if there is anything in the metadata of the sp about that as well18:21
dstanekgabriel-bezerra: i don't think the SP will control what the IdP sends - it will limit what shows up in the env though18:22
gabriel-bezerradstanek: I'd look for something like "types of data that this SP recognizes" in the metadata18:22
gabriel-bezerradstanek: btw, it is possible to configure "remote" sources of metadata in the idp configuration -- recall that I suggested putting the metadata in a file and referencing that file in the idp_conf18:24
dstanekgabriel-bezerra: right now i am only using the urls to the metadata. no more local file stuff18:25
gabriel-bezerradstanek: https://pythonhosted.org/pysaml2/howto/config.html#metadata18:26
gabriel-bezerradstanek: like the "remote" list in the code sample of that link?18:27
rushiagrayoung: Hi18:28
rushiagrayoung: Please have a look at my comments  on https://review.openstack.org/#/c/136980/ when you have time. Let me know if you have concerns, and I'll address them18:28
gabriel-bezerradstanek: sequence of (url: _, cert: _) maps18:28
rushiagrayoung: thanks :)18:28
dstanekgabriel-bezerra: i'll post the most recent version of my config in a few18:29
*** marcoemorais1 has quit IRC18:30
dstanekgabriel-bezerra: i'm actively pushing bits and pieces to https://github.com/dstanek/keystone/tree/functonal-testing so i can push stuff around onto new nodes18:30
*** marcoemorais has joined #openstack-keystone18:30
dstanekgabriel-bezerra: please don't clone though because i am force pushing18:30
*** marcoemorais has quit IRC18:31
*** marcoemorais has joined #openstack-keystone18:31
gabriel-bezerradstanek: sure.18:31
*** marcoemorais has quit IRC18:32
*** marcoemorais has joined #openstack-keystone18:32
gabriel-bezerradstanek: It's a nice set of changes, btw.18:34
gabriel-bezerradstanek: I'm wondering about the meaning of this command line argument:18:40
gabriel-bezerra1005     parser.add_argument('-s', dest='sign', action='store_true',18:40
gabriel-bezerra1006                         help="sign the metadata")18:40
gabriel-bezerradstanek: in idp.py18:41
gabriel-bezerradstanek: if it can help in the "Unable do establish security of incoming assertion"18:41
dstanekgabriel-bezerra: i already have that fixed by adding config values18:42
dstanekgabriel-bezerra: search for sign_ in http://23.253.156.66/media/idp_conf.py18:42
*** thiagop has quit IRC18:45
dstanekgabriel-bezerra: although that may be a shortcut so i don't have to change the config file18:45
gabriel-bezerradstanek: it worked here. It's better than using the NullSecurity policy as me and marekd have done18:47
morganfainbergnkinder, ALARMING VERBIAGE!!18:48
nkindermorganfainberg: that just means that the security note has done it's job (raise awareness) :)18:48
morganfainbergnkinder, yep18:48
morganfainbergnkinder, i also just responded18:48
*** afaranha has quit IRC18:49
morganfainbergnkinder, i thought your write up was quite nice - explained things well18:49
dstanekgabriel-bezerra: yeah, i got around it by fixing the config files18:49
lbragstadjorge_munoz: fyi, here is the RFC for ldap https://tools.ietf.org/html/rfc451218:58
lbragstadjorge_munoz: or one of them18:58
jorge_munozlbragstad: thanks18:59
*** gyee has quit IRC19:00
*** afazekas has quit IRC19:02
*** marcoemorais has quit IRC19:05
*** gyee has joined #openstack-keystone19:06
*** ChanServ sets mode: +v gyee19:06
*** raildo_ has joined #openstack-keystone19:07
*** hdd has joined #openstack-keystone19:10
*** ajayaa has joined #openstack-keystone19:15
*** chrisshattuck has joined #openstack-keystone19:16
*** rushiagr is now known as rushiagr_away19:18
*** raildo_ has quit IRC19:22
*** ajayaa has quit IRC19:23
*** ajayaa has joined #openstack-keystone19:25
*** nellysmitt has quit IRC19:26
stevemardstanek, what trickery are you up to?19:26
dstanekstevemar: trying to get the automation to work :-) i did so much hacking all over the place to setup keystone federation that i can't find all the places!19:27
samuelmshaha19:27
samuelms:-)19:27
morganfainbergso, i'm hesitant to push a tag with the gate in the state it is.19:28
dstaneki have no idea how a deployer can do this for real19:28
morganfainbergsoooo i'm going to wait until it wont be $unknown_time_until_something_something before we can push a fix if something is going on19:28
morganfainbergthis may mean the tag is pushed tomorrow instead of today19:29
morganfainbergjamielennox|away, ^ re: client and middleware19:29
ayoungrushiagr_away, have you seen all the policy work that is in flight?  Take a look at this summary when you get a chance:  https://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/19:29
*** fifieldt_ has quit IRC19:30
*** rushiagr_away is now known as rushiagr19:32
*** 21WAAOJ1V has joined #openstack-keystone19:34
stevemardstanek, update your WIP patch and i'll review it :)19:35
stevemaryour hacking is all over the place19:35
*** dims has quit IRC19:35
dstanekstevemar: yes, yes it is19:35
*** dims has joined #openstack-keystone19:36
dstanekstevemar: trying to get it updated now by adding the hacking as additional automation or config changes19:36
dstanekstevemar: i've been pushing stuff here for now https://github.com/dstanek/keystone/tree/functonal-testing19:36
stevemarah okay19:36
*** 21WAAOJ1V has quit IRC19:36
*** afaranha has joined #openstack-keystone19:37
*** gordc has joined #openstack-keystone19:40
*** dims has quit IRC19:40
*** raildo_ has joined #openstack-keystone19:44
*** fifieldt_ has joined #openstack-keystone19:46
dstanekstevemar: like this crap - i forgot how i made mod_shib sign it's metadata19:47
stevemardid you use the keystone-manage utility we added in juno?19:49
dstanekstevemar: to do what?19:49
stevemardstanek, get the metadata19:49
dstanekstevemar: that's for k2k right?19:50
*** aix has joined #openstack-keystone19:52
*** Tahmina has joined #openstack-keystone19:56
*** rushiagr is now known as rushiagr_away19:58
stevemardstanek, yesh, i see your problem now :) by you can use the same pysaml2 function to create it19:59
gyeemorganfainberg, I am not convinced about R/W LDAP driver, seem like a lot of work for very little benefit19:59
dstanekstevemar: i'm looking to get the metadata from the SP signed19:59
gyeeI'd be OK with it being out-of-tree20:00
morganfainberggyee, please comment on the spec. we have a couple large players that actually use r/w ldap, one that is willing to put a lot of engineering resources behind this - and I see it as a path to leverage ldap to do the stuff that SQL identity does very badly20:00
morganfainberggyee, i'd like to dump sql identity, and we will need some form of internal identity - i don't want to move sql idenitty forward and need to implement all the things that slapd, etc can do for us.20:00
morganfainberggyee, so - please comment on the spec :) if it's not worth accepting it isn't. but i'd like comments and the like recorded because that is the basis we're going to use to determine the value20:01
dstanekstevemar: ah wait, maybe i never got this working without a "fix" to pysaml220:01
gyeemorganfainberg, I would like to see separating out IdP work done first20:01
morganfainberggyee, because it also allows the proposer to reply to the comment.20:01
gyeeI do understand the motivation20:02
morganfainberggyee, this is a big job to do, it has a lot of peices, we may be able to get that as part of this spec.20:02
morganfainberggyee, we *may* need to invert that priority, but we may not.20:02
gyeeLDAP is made for static data such as identity20:02
morganfainberggyee, my goal here is to get the clear feedback to the proposers and get the conversation going so we have a clear set of goals / ideas on if we want this in-tree20:03
morganfainberggyee, assignment is fairly static data as well fwiw. tokens are not20:03
gyeeif we separate out IdP, and backing it with LDAP that would make sense20:03
morganfainberggyee, keystone's data set as a whole is fairly static even at the SP level.20:03
dstanekstevemar: yes this is result of me fixing https://github.com/rohe/pysaml2/blob/master/src/saml2/mdstore.py#L635 to have an optional cert since https://github.com/rohe/pysaml2/blob/master/src/saml2/mdstore.py#L655 implies that it's optional20:04
morganfainberggyee, like i said, not saying we have to accept this but i really want whatever feedback available logged in the spec -20:04
gyeek, I'll comment on it20:05
*** nellysmitt has joined #openstack-keystone20:05
stevemardstanek, ahh time for a PR20:09
*** LinstatSDR has quit IRC20:10
dstanekstevemar: exactly20:13
*** raildo_ has quit IRC20:14
*** thiagop has joined #openstack-keystone20:19
raildodstanek, I answered your questions in the Reseller spec: https://review.openstack.org/#/c/139824/20:27
raildodstanek, and if you have same free time, please review the spec about the HMT improvements :)  https://review.openstack.org/#/c/135309/20:27
*** drjones has joined #openstack-keystone20:29
*** _cjones_ has quit IRC20:29
openstackgerritVictor Silva proposed openstack/keystone: Identify groups by name/domain in mapping rules.  https://review.openstack.org/13901320:32
openstackgerritVictor Silva proposed openstack/keystone: Implements whitelist and blacklist mapping rules  https://review.openstack.org/14257320:32
rodrigodsmarekd, ^20:32
rodrigodsnkinder, ^20:33
*** LinstatSDR has joined #openstack-keystone20:34
dstanekgabriel-bezerra: the -s didn't seem to work...i still needed my config values20:38
bknudsonlooks like keystoneclient py33 jobs are not working20:42
morganfainbergbknudson, yep. something with PBR or sphinx...20:43
bknudsonNameError: name 'StandardError' is not defined20:43
bknudsonseems like StandardError should be defined20:43
morganfainbergbknudson, there is a bug (not attached to ksc) and a ML topic20:43
* morganfainberg looks for it20:43
*** gordc has quit IRC20:43
bknudsonI blame stevemar20:43
morganfainbergbut yes, it's known issue and dstufft has been working on it20:43
morganfainbergbknudson, good person to blame20:44
dstanekStandardError should *always* be there unless magic is breaking20:44
dstaneksend the unicorns to aid infra!20:44
stevemarbknudson, blame me because i mentioned it at 10am?20:47
bknudsonstevemar: who smelt it dealt it.20:47
bknudsonat 10am20:47
stevemargah! that rule bites me again20:47
*** r-daneel has joined #openstack-keystone20:49
*** drjones has quit IRC20:51
*** ajayaa has quit IRC20:53
stevemarcan i get another core on https://review.openstack.org/#/c/142192/1 it's super easy20:54
gyeestevemar, indeed20:55
stevemarty gyee !20:55
*** dims has joined #openstack-keystone20:58
*** thedodd has quit IRC20:58
*** mancdaz has quit IRC21:02
*** mancdaz has joined #openstack-keystone21:03
*** thedodd has joined #openstack-keystone21:03
*** __TheDodd__ has joined #openstack-keystone21:07
*** thedodd has quit IRC21:09
openstackgerritMerged openstack/keystone-specs: Fix RST formatting issues  https://review.openstack.org/14193021:10
*** Tahmina has quit IRC21:10
*** nellysmitt has quit IRC21:11
openstackgerritThiago Paiva Brito proposed openstack/python-keystoneclient: Implementing hierarchical calls on keystoneclient v3 (python only)  https://review.openstack.org/11577021:13
richm1stevemar: ping - re: openstack endpoint create vs. keystone endpoint-create21:14
richm1with keystone endpoint-create I can use --publicurl --adminurl and --internalurl to create the endpoint with all 3 urls21:17
stevemarrichm1, oye the endpoint commands are a pain, so are the catalog/service ones, but whats up21:17
richm1so if I want to do the same thing with openstack, I need to make 3 calls, one for each interface?21:17
stevemarrichm1, let me look at the command21:18
stevemarrichm1, we talking v2 or v321:18
*** raildo has quit IRC21:18
richm1hmm - it is different21:19
*** mancdaz has quit IRC21:19
richm1ok - another item for the v2/v3 upgrade list21:19
*** mancdaz has joined #openstack-keystone21:19
ayoungmorganfainberg, when looking for LDAP input, ask nkinder as he's a long time LDAP hacker21:20
stevemarrichm1, yeah, looks like the v3 one was changed to account for the v3 API21:20
stevemarrichm1, http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#create-endpoint21:20
richm1ok21:20
morganfainbergayoung, always try to21:20
ayoungso do you really think we can dump SQL Identity?21:20
morganfainbergayoung, if we have a really good r/w (with migration path) ldap story - yes21:21
stevemarrichm1, i suppose we could take in those three parameters and call it three times under the covers...21:21
ayoungmorganfainberg, cool21:21
richm1stevemar: no, no worries21:21
richm1stevemar: will just have to wrap it in the puppet-keystone code21:22
morganfainbergayoung, but it's a long play - and it doesn't mean we're out of the identity management side, we just shift it to something we don't need to write the whole story for.21:22
ayoungmorganfainberg, that would mean that we could potentially use the Keystone database for the Virtual Machines....21:22
ayoungI like this21:22
morganfainbergayoung, i'm not willing to jump *that* far ahead - want to see us reach some form of consensus on the direction before getting too optimistic21:22
ayoungmorganfainberg, actually, there is no reason we couldn't do it now with LDAP as is, just that it could become the norm21:23
morganfainbergayoung, i also want to use this to solve the PII problem / split identity and try and make our default story "federated"21:23
morganfainbergayoung, well i don't think we can do it now. the ldap r/w story is bad in keystone21:23
morganfainbergit's mostly an after thought21:23
morganfainbergwell.. feels like at at least21:23
ayoungmorganfainberg, well, LDAP is pretty sloppy code, but the R/W aspect of it is no worse, I think, than the core LDAP code21:24
morganfainbergayoung, the r/w aspect was bolted onto the core - which made us compromise more on the core21:25
ayoungnot really.  It was w/r from the get go21:25
morganfainbergayoung, so we didn't optimise for r/o, and we wedged r/w into the same model21:25
ayoungeven before I inherited it21:25
morganfainbergayoung, well over time - it has moved more and more r/w feels just kindof bolted on the side of the r/o21:25
bknudsonthere's all sorts of things that don't work with LDAP21:26
ayoungjust less common code path.  But I think we are in sync in vision21:26
morganfainbergbknudson, agree, tons of features that are sub-par on both sides21:26
ayoungits more because we've put in much more work to dealing with AD and the other R/O use cases21:26
ayoungI'd love to be able to use the FreeIPA API for writing LDAP21:27
ayoungbut that would not work for CERN21:27
morganfainbergso anyway21:27
ayoungThey need explicitly Active Directory21:28
bknudsonI think deployers would be better doing their own writes to LDAP... just write a little script to add roles and stuff21:28
ayoungmorganfainberg, I've got a POC of unscoped to scoped only.  Only made it work on v3 so far21:28
ayoungits pretty trivial.  Want me to post it WIP, or wait till I get V2 working too?21:28
morganfainbergayoung, i saw you propose it.21:28
morganfainbergayoung, or was that something else?21:28
ayoungno, I mean the second part21:28
morganfainbergayoung, oh sure WIP it.21:29
ayoungI got the "explicit uncoped" working already21:29
morganfainbergayoung, up to you21:29
ayounglet me get v2...21:29
morganfainbergbknudson, i don't think it's reasonable to ask deployers to write something that caters to *our* definition like that.21:29
ayoungissue is testing.  v2 to v2 v3 to 3 v3 to v2 and v2 to v321:29
bknudsonmorganfainberg: it's not ours, it's their LDAP.21:29
ayoungR/W ldap is much more opinionated than Read Only21:30
morganfainbergayoung, ++21:30
morganfainbergr/o yes, it's on them21:30
stevemarr/w ldaps are headachey21:31
morganfainbergr/w if we're supporting and maintaining it, should be opinionated and really a first-class backend not "well, sortof"21:31
ayoungyou should have seen the custom schema in the LDAP impl before mine21:31
bknudsonthere should be a section in the spec that requires LDAP consideration then.21:31
morganfainbergand we do have an engineering team willing to push on this and make it a reality, so we should comment on the spec.21:31
morganfainbergbknudson, if we accept this r/w spec we should probably do that21:31
morganfainbergbknudson, or when we make an effort to make ldap better than "sortof working for limited cases" we should.21:32
morganfainbergbknudson, this is all stuff i'd like to see commented on that spec.21:32
morganfainbergbknudson, it will help us get a feel of where the proposers want to go, how far they're willing to, and if we like the direction.21:33
openstackgerritThiago Paiva Brito proposed openstack/python-keystoneclient: Implementing hierarchical calls on keystoneclient v3 (python only)  https://review.openstack.org/11577021:33
*** __TheDodd__ has quit IRC21:39
*** topol has quit IRC21:40
ayoungbknudson, any idea where the old V2 API examples are?  We seem to have only the V3 ones now21:50
*** _cjones_ has joined #openstack-keystone21:51
bknudsonayoung: curl examples?21:51
*** _cjones_ has quit IRC21:53
*** _cjones_ has joined #openstack-keystone21:53
ayoungbknudson, yeah...although I think I have it21:53
ayoungfrom looking at the code, anyway.21:53
bknudsonayoung: these are v2: http://docs.openstack.org/developer/keystone/api_curl_examples.html#admin-api-examples-using-curl21:54
bknudsonhttp://docs.openstack.org/developer/keystone/api_curl_examples.html#service-api-examples-using-curl21:54
bknudsonfor some reason it's called "service" api.21:54
ayoungbknudson, oik,  didn't see the v2 stuff in there...but still doesn;t show token for token...still, think I have it21:56
*** dims has quit IRC22:04
openstackgerritayoung proposed openstack/keystone: Unscoped to Scoped only  https://review.openstack.org/14259122:17
*** ayoung is now known as ayoung_dreidl22:18
openstackgerritDavid Stanek proposed openstack/keystone: Support for running functional federation tests  https://review.openstack.org/13913722:18
dstanekstevemar: gabriel-bezerra: ^ the latest and greatest22:18
stevemardstanek, already have it open22:18
dstaneknot i have to figure out the attribute issue22:19
dstaneks/not/now/22:19
dstanekstevemar: i need to write up a readme, but that will standup a pysaml idp, configure keystone to use federation and run a test to make sure things are properly wired together22:20
stevemardstanek, that is freaking awesome22:21
stevemardstanek, use the rules i sent out over the email :) https://review.openstack.org/#/c/139137/2/functional_tests/federation/devstack/files/key-federation-setup.py22:21
dstanekstevemar: not yet - once the attributes and mapping are there and working then i'll be happy22:21
dstanekstevemar: yes, i was planning on it - just have to find out why no attributes are getting into the assertion22:22
stevemaryep22:22
stevemarthats lookin pretty solid22:23
dstaneki probably need to convert that to bash using some of the devstack functions, but since it didn't have all of them using Python was quicker to start22:23
stevemardstanek, fwiw, there is pretty decent support from OSC for federation stuff, like creating mappings/idps/protocols22:24
morganfainbergdstanek, /me goes and runs that in an existing devstack :P22:24
stevemarmorganfainberg, gad! it says right there!22:25
stevemar:P22:25
morganfainbergbut...22:25
morganfainberg;)22:25
*** thedodd has joined #openstack-keystone22:27
*** zz_avozza is now known as avozza22:28
*** LinstatSDR has quit IRC22:28
*** dims__ has joined #openstack-keystone22:29
dstanekmorganfainberg: poof - no warranty22:30
dstanekalso only works in Ubuntu right now because i haven't tried Fedora at all yet22:31
morganfainbergehe22:32
dstaneki found out that Apache is stupid this morning22:35
dstanekmod_shib failed because i messed up some XML and Apache started find, but all client requests hung forever22:35
dstanektook me a half hour before i decided to look at the error log because Apache told me it started and was running fine22:36
*** marcoemorais has joined #openstack-keystone22:40
*** diegows has quit IRC22:40
*** jamielennox|away is now known as jamielennox22:52
*** stevemar has quit IRC22:55
*** stevemar has joined #openstack-keystone22:56
*** ChanServ sets mode: +v stevemar22:56
dstanekmorganfainberg: stevemar: you guys still around?22:57
stevemardstanek, kinda sorta22:59
stevemardolphm, i don't understand what you mean by 'is it too soon?' https://review.openstack.org/#/c/133529/ ?23:00
stevemaroh wait... i can't read23:00
dolphmstevemar: nope23:00
stevemardolphm, welp, don't remember agreeing to that23:01
stevemardolphm, looks like i got some work to do tonight23:01
dstanekoh dolphm's here too23:03
dolphmdstanek: what did i do wrong?23:03
*** timcline has quit IRC23:03
dstanekin https://review.openstack.org/#/c/139137/2/ i use a directory named functional tests; in an updated patch i called it dsvm because i wanted to have standard functional, federation and k2k functional tests and maybe other devstack vm things in there23:04
dstanekdolphm: morganfainberg: stevemar: thoughts on naming before i redo that patch? ^23:04
dolphmdstanek: what would be in there besides tests?23:07
*** gordc has joined #openstack-keystone23:09
dstanekdolphm: i was actually thinking of splitting dsvm setup from the tests more like this: https://etherpad.openstack.org/p/keystone-functional-tests23:10
*** timcline has joined #openstack-keystone23:11
*** nellysmitt has joined #openstack-keystone23:12
openstackgerritMerged openstack/keystone-specs: rescope tokens unscoped to scoped only  https://review.openstack.org/12376023:12
*** jaosorior has joined #openstack-keystone23:13
*** marcoemorais has quit IRC23:13
*** marcoemorais has joined #openstack-keystone23:13
jamielennoxstevemar: has that py33 bug been fixed? i see https://review.openstack.org/#/c/131408/ is supposed to fix it but have they released pbr again?23:14
*** nellysmitt has quit IRC23:16
esphey folks I have noobie question regarding keystone v3 and domains.  *should* we be able to disable the default domain?  I’m trying to figure out what the use cases for that might be.  thx!23:17
ayoung_dreidlesp, you could, but I wouldn't recomend it.  right now, there is no support for service users in non-default domains.  Keystone client and middleware support it as of very recently, but I wouldn't expect it from the rest of the tooling for a while23:20
espthx ayoung_dreidl, I’m wondering if we should not allow this in horizon23:21
espit basically locks you out until it’s re-enabled :)23:22
dstanekayoung_dreidl: also v2 only uses the default domain right?23:23
*** ayoung_dreidl is now known as ayoung23:23
ayoungesp, disabling the default domain?  I would not make special precautions for it right now...we are going to be doing a lot with Keystone policy, and I would think that dealing with domains in general will be part of that.  I don't think Horizon should be enforcing that kind of business logic, it is too ad-hoc23:25
ayoungdstanek, right, v2 only default domain23:25
espayoung: k, makes sense23:26
espwe’ll just keep track of the behavior for now23:26
espthx!23:26
*** avozza is now known as zz_avozza23:39
*** andreaf has quit IRC23:50
*** timcline has quit IRC23:53
*** thedodd has quit IRC23:56
*** hdd has quit IRC23:58

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