Monday, 2015-02-02

openstackgerrithenry-nash proposed openstack/keystone: Add support for group membership to data driven assignment tests  https://review.openstack.org/15196200:31
*** ncoghlan has joined #openstack-keystone00:31
openstackgerritMerged openstack/python-keystoneclient-kerberos: Move to hacking 0.10  https://review.openstack.org/14636200:31
*** oomichi has joined #openstack-keystone00:32
openstackgerritMerged openstack/python-keystoneclient-federation: Move to hacking 0.10  https://review.openstack.org/14635900:33
openstackgerritMerged openstack/python-keystoneclient-federation: Correct failures for check W292  https://review.openstack.org/14636000:34
*** henrynash has quit IRC00:35
*** kfox1111 has quit IRC00:56
openstackgerritMerged openstack/python-keystoneclient: make req_ref doesn't require id  https://review.openstack.org/14849901:04
openstackgerritMerged openstack/python-keystoneclient: Configure TCP Keep-Alive for certain Sessions  https://review.openstack.org/14770701:04
openstackgerritMerged openstack/python-keystoneclient: Fix typo in Ec2Signer class docstring  https://review.openstack.org/15102001:05
openstackgerritMerged openstack/python-keystoneclient: handles keyboard interrupt  https://review.openstack.org/12104601:06
*** nellysmitt has joined #openstack-keystone01:08
*** nellysmitt has quit IRC01:12
openstackgerritMerged openstack/python-keystoneclient: Correct failures for check H238  https://review.openstack.org/14633701:14
*** avozza is now known as zz_avozza01:20
openstackgerritZhiQiang Fan proposed openstack/python-keystoneclient: Enable hacking rule E122 and H304  https://review.openstack.org/13410101:24
*** davechen_ has joined #openstack-keystone01:47
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Extract the Loadable interface from a plugin  https://review.openstack.org/13857502:10
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Make session use the Loadable interface  https://review.openstack.org/13857602:10
*** joesavak has joined #openstack-keystone02:11
*** zz_avozza is now known as avozza02:11
*** erkules_ has joined #openstack-keystone02:15
openstackgerritJamie Lennox proposed openstack/python-keystoneclient-federation: Copy the existing federation plugins over.  https://review.openstack.org/15062702:15
*** joesavak has quit IRC02:15
*** erkules has quit IRC02:17
*** avozza is now known as zz_avozza02:23
*** nellysmitt has joined #openstack-keystone03:08
*** nellysmitt has quit IRC03:13
*** stevemar has joined #openstack-keystone03:44
*** ChanServ sets mode: +v stevemar03:44
*** dims has joined #openstack-keystone03:49
*** dims_ has joined #openstack-keystone03:51
*** jacer_huawei has joined #openstack-keystone03:54
*** jacer_huawei is now known as wanghong03:54
*** dims has quit IRC03:55
*** tellesnobrega has joined #openstack-keystone04:05
*** dims_ has quit IRC04:12
openstackgerrittakehirokaneko proposed openstack/keystone: Adds a validation param "max_username_size".  https://review.openstack.org/12850404:28
*** spandhe has joined #openstack-keystone04:33
*** rushiagr_away is now known as rushiagr04:39
*** zz_avozza is now known as avozza04:43
*** avozza is now known as zz_avozza04:53
*** nellysmitt has joined #openstack-keystone05:09
*** pnavarro has quit IRC05:11
*** darrenc has joined #openstack-keystone05:12
*** dims has joined #openstack-keystone05:12
darrenchi05:12
*** nellysmitt has quit IRC05:14
darrencI've got a question on configuring keystone for multiple LDAP servers. Any takers?05:14
*** dims has quit IRC05:17
stevemardarrenc, ask away, but worst case also ask on the mailing list05:26
*** richm has quit IRC05:37
*** zz_avozza is now known as avozza05:44
*** oomichi has quit IRC05:47
*** ncoghlan has quit IRC05:50
*** ncoghlan has joined #openstack-keystone05:50
*** avozza is now known as zz_avozza05:54
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/15185606:03
darrencSt06:03
darrencstevemar  I'm updating http://docs.openstack.org/admin-guide-cloud/content/configuring-keystone-for-ldap-backend-assignments.html for configuring multiple LDAP servers. So wherever keystone.conf file is mentioned, should domain specific configuration files be mentioned for multiple LDAP servers?06:08
stevemardarrenc, ah i see you added henrynash on your patch too: https://review.openstack.org/#/c/151980/06:10
darrencYes :)06:10
stevemardarrenc, the docs looks solid, all mentions to keystone.domain_name.conf06:12
stevemardarrenc, i think you want to use 'multiple backends' instead of 'multiple LDAP servers'06:13
stevemarcause you can have one domain use sql, and another use ldap06:13
darrencOk, thanks!06:15
darrencstevemar so the identity assignment split for configuring keystone.Conf also applies for keystone.domain_name.conf files?06:18
darrencTyping is hard on an android phone :)06:19
stevemardarrenc, haha, i bet - theres a weird set of requirements there, let me see if i can explain it06:20
stevemardarrenc, so if you are using ldap for assignment (projects, role, etc), then you must use ldap for identity (users, groups).06:20
stevemardarrenc, but if you are using sql for assignment, then you can use any combination of 0 or more ldap and sql backends for identity06:21
stevemardarrenc, i hope that is right, and henrynash doesn't throw things at me for giving false information06:21
*** tellesnobrega_ has joined #openstack-keystone06:30
darrencstevemar I think it's making sense to me now.06:32
*** tellesnobrega has quit IRC06:32
darrencThanks so much for your help06:32
darrencAnd kudos to Henry as well!06:34
*** ajayaa has joined #openstack-keystone06:38
*** jaosorior has joined #openstack-keystone06:39
*** ajayaa has quit IRC06:44
*** zz_avozza is now known as avozza06:44
*** MasterPiece has joined #openstack-keystone07:02
*** nellysmitt has joined #openstack-keystone07:10
openstackgerritSteve Martinelli proposed openstack/keystone: Add a domain to federated users  https://review.openstack.org/11085807:12
*** ajayaa has joined #openstack-keystone07:13
*** nellysmitt has quit IRC07:15
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for most resources  https://review.openstack.org/15113707:15
openstackgerritSteve Martinelli proposed openstack/keystone: Publicize region/endpoint/policy/service events  https://review.openstack.org/15177407:15
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notification handling for policy/region/service/endpoint  https://review.openstack.org/15178607:15
openstackgerritSteve Martinelli proposed openstack/keystone: Add a test for create_domain in notifications  https://review.openstack.org/15179107:15
openstackgerritSteve Martinelli proposed openstack/keystone: Revamp the documentation surrounding notifications  https://review.openstack.org/12618007:16
*** avozza is now known as zz_avozza07:16
*** afazekas has joined #openstack-keystone07:16
openstackgerritSteve Martinelli proposed openstack/keystone: Add context to manager classes that send notifications  https://review.openstack.org/15186607:18
openstackgerritSteve Martinelli proposed openstack/keystone: WIP - Add CADF notifications for trusts  https://review.openstack.org/15186707:18
*** zz_avozza is now known as avozza07:49
*** davechen_ has quit IRC07:52
*** mflobo has joined #openstack-keystone07:58
*** MasterPiece has quit IRC07:59
*** chlong has quit IRC08:00
*** spandhe has quit IRC08:06
openstackgerritMarek Denis proposed openstack/keystone: Fix typo in Patch #142743  https://review.openstack.org/15201608:07
marekdstevemar: wow, you are fast!08:08
stevemarmarekd, :D08:08
marekdwhy are you still working?08:08
marekdare you ever sleeping? :-)08:08
*** ajayaa has quit IRC08:09
openstackgerritSteve Martinelli proposed openstack/keystone: Add documetation for key types and basic authenticating  https://review.openstack.org/15201808:10
stevemarmarekd, i drank tea too late08:11
openstackgerritSteve Martinelli proposed openstack/keystone: Add documetation for key terms and basic authenticating  https://review.openstack.org/15201808:11
stevemarmarekd, anyway, heading to sleep now08:13
stevemarsee - i'm human(ish)08:13
marekdstevemar: go ahead!08:13
marekdstevemar: your twitter handle (stevebot) is completely justified.08:13
stevemarmarekd, hehe, all the other stevemar related ones were taken, i think some folks must think i'm a twitter bot08:14
stevemarmarekd, i'm out, have a good day sir08:15
marekdgood night, sir!08:15
*** stevemar has quit IRC08:19
openstackgerritMarek Denis proposed openstack/keystone: During authentication validate if IdP is enabled  https://review.openstack.org/15168308:25
*** ajayaa has joined #openstack-keystone08:27
*** henrynash has joined #openstack-keystone08:29
*** ChanServ sets mode: +v henrynash08:29
*** nellysmitt has joined #openstack-keystone08:36
*** bdossant has joined #openstack-keystone08:37
*** mzbik has joined #openstack-keystone08:41
*** bjornar has joined #openstack-keystone08:44
*** jaosorior has quit IRC08:46
*** nkinder has joined #openstack-keystone08:48
*** rwsu has joined #openstack-keystone08:49
openstackgerritMarek Denis proposed openstack/keystone: Create K2K SAML assertion from service provider.  https://review.openstack.org/15204608:49
*** rwsu is now known as rwsu-afk08:50
*** jistr has joined #openstack-keystone08:58
*** erkules_ is now known as erkules09:00
*** ncoghlan has quit IRC09:02
*** mflobo has quit IRC09:12
*** mflobo has joined #openstack-keystone09:16
*** bdossant has quit IRC09:24
*** MasterPiece has joined #openstack-keystone09:33
*** obutenko has joined #openstack-keystone09:50
openstackgerrithenry-nash proposed openstack/keystone: Fixes 'OS-INHERIT:inherited_to' info in tests  https://review.openstack.org/14454209:59
openstackgerritMarek Denis proposed openstack/keystone: Service Providers API for OS-FEDERATION  https://review.openstack.org/10462310:00
openstackgerritMarek Denis proposed openstack/keystone: Create K2K SAML assertion from service provider.  https://review.openstack.org/15204610:00
*** henrynash has quit IRC10:02
*** henrynash has joined #openstack-keystone10:08
*** ChanServ sets mode: +v henrynash10:08
openstackgerrithenry-nash proposed openstack/keystone: Refactor role assignment assertions  https://review.openstack.org/14454310:10
*** therve` is now known as therve10:17
*** ajayaa has quit IRC10:18
*** henrynash has quit IRC10:22
*** rushiagr is now known as rushiagr_away10:24
*** tellesnobrega_ has quit IRC10:42
*** samueldmq has joined #openstack-keystone10:45
*** ajayaa has joined #openstack-keystone10:46
*** rushiagr_away is now known as rushiagr10:47
openstackgerritMarek Denis proposed openstack/keystone: Create K2K SAML assertion from service provider  https://review.openstack.org/15204610:56
*** andreaf_ is now known as andreaf10:58
*** samueldmq has quit IRC11:00
*** samueldmq has joined #openstack-keystone11:05
openstackgerritMarek Denis proposed openstack/keystone-specs: Update doc for generating SAML2 assertion  https://review.openstack.org/15208311:09
openstackgerritMarek Denis proposed openstack/keystone: Create K2K SAML assertion from Service Provider  https://review.openstack.org/15204611:12
openstackgerritMarek Denis proposed openstack/keystone: Service Providers API for OS-FEDERATION  https://review.openstack.org/10462311:15
openstackgerritMarek Denis proposed openstack/keystone: Create K2K SAML assertion from Service Provider  https://review.openstack.org/15204611:15
*** pnavarro has joined #openstack-keystone11:21
*** pnavarro has quit IRC11:27
*** anish has joined #openstack-keystone11:29
anishIs keystone a hard requirement for running openstack ? I seem to be running into a bunch of oslo namespace issues when using devstack wrt keystone, can I just skip it ?11:33
*** tellesnobrega has joined #openstack-keystone11:34
samueldmqanish, Keystone is the a key stone for running openstack :)11:35
samueldmqanish, it provides authentication and authorization for other OS components.. yes, it a critical component I'd say :)11:36
anishI thought as much11:37
anishespecially when disable_service is clearly ignored11:37
samueldmqanish, I think #openstack-sdks is the right place to talk about devstack issues :)11:38
samueldmqanish, maybe you hit bugs .. and we need you to tell us about them11:38
anishsamueldmq: http://ix.io/g6u11:39
anishfrom what I understand, the namespace changes are ongoing in all projects11:39
anishkeystone just seems a little behind ?11:39
anishbut this is what I really am stuck on : ImportError: No module named keystoneclient.common11:39
samueldmqanish, are you just trying to run a regular devstack (downloaded and tried ./stack.sh) ?11:41
anishyes11:41
samueldmqanish, trying ....11:44
anishexact same issue with keystoneclient as well, oslo.utils -> oslo_utils11:45
*** rushiagr is now known as rushiagr_away11:56
*** diegows has joined #openstack-keystone12:03
*** avozza is now known as zz_avozza12:05
*** htruta has joined #openstack-keystone12:09
*** raildo has joined #openstack-keystone12:10
anishsamueldmq: don't know if you hit it, but I was able to get past that with the patch I linked + some more changes12:10
*** rushiagr_away is now known as rushiagr12:12
openstackgerritAnish Bhatt proposed openstack/keystone: Update as per oslo namespace changes. Devstack seems broken without these changes  https://review.openstack.org/15209512:17
samueldmqanish, sorry but I didnt hit it ... maybe someone else can confirm it later, when more people are active12:20
anishweird. I made a patch for review anyways, in case other ppl see this12:22
anishsamueldmq: you were using a fresh devstack with RECLONE=yes ?12:22
*** aix has joined #openstack-keystone12:31
*** nellysmitt has quit IRC12:38
*** nellysmi_ has joined #openstack-keystone12:38
*** nellysmi_ has quit IRC12:39
*** zz_avozza is now known as avozza12:41
marekdnkinder: hi. I cannot remember - did you have a chance to test mod_mellon with ECP support?12:43
nkindermarekd: ECP is still being developed for mod_auth_mellon12:44
marekdnkinder: so I guess you will not support idea where Keystone issues ECP-formated assertion in K2K case? :-)12:45
nkindermarekd: well, I hope ECP is working in mellon very soon (we're actively working on it)12:46
marekdnkinder: you are using lasso underneath, right?12:46
nkindermarekd: yes, and lasso looks to have ECP12:46
*** markvoelker has joined #openstack-keystone12:50
openstackgerritAnish Bhatt proposed openstack/keystone: Update as per oslo namespace changes. Devstack seems broken without these changes  https://review.openstack.org/15209512:51
*** rushiagr is now known as rushiagr_away12:51
*** dims has joined #openstack-keystone12:52
*** dims_ has joined #openstack-keystone12:52
*** dims has quit IRC12:56
*** nellysmitt has joined #openstack-keystone12:58
*** markvoelker has quit IRC13:00
*** ajayaa has quit IRC13:05
*** richm has joined #openstack-keystone13:06
*** markvoelker has joined #openstack-keystone13:12
openstackgerritMarek Denis proposed openstack/keystone: Create K2K SAML assertion from Service Provider  https://review.openstack.org/15204613:13
openstackgerritMarek Denis proposed openstack/keystone: Create K2K SAML assertion from Service Provider  https://review.openstack.org/15204613:15
marekdmorganfainberg: https://review.openstack.org/#/c/152046/6/keystone/contrib/federation/controllers.py,cm (line 294). I would like to return two extra parameters in HTTP headers, so the keystoneclient knows where to hit Service Providers.13:16
marekdrodrigods: hello boss13:16
*** joesavak has joined #openstack-keystone13:17
marekdrodrigods: do you think you will be able to work on service catalog soon ?  Not rushing, just checking :-)13:17
*** samueldmq has quit IRC13:23
*** jsavak has joined #openstack-keystone13:24
rodrigodsmarekd, hi... yes, I can. Will let you know if something appears13:25
marekdrodrigods: well, i can work on it13:25
marekdi just  thought you wanted to.13:26
rodrigodsmarekd, yep... but you can take it over, np :)13:26
*** joesavak has quit IRC13:27
marekdrodrigods: OK. YOu are probably busy.13:27
openstackgerritMarek Denis proposed openstack/keystone-specs: Update doc for generating SAML2 assertion  https://review.openstack.org/15208313:28
*** jaosorior has joined #openstack-keystone13:29
*** amakarov has quit IRC13:31
*** bjornar has quit IRC13:40
*** avozza is now known as zz_avozza13:49
*** gordc has joined #openstack-keystone13:50
*** gordc_ has joined #openstack-keystone13:52
*** samueldmq has joined #openstack-keystone13:53
*** bjornar has joined #openstack-keystone13:54
*** richm has quit IRC14:02
*** rushiagr_away is now known as rushiagr14:03
*** MasterPiece has quit IRC14:03
*** dims_ has quit IRC14:03
*** mzbik has quit IRC14:19
*** amakarov has joined #openstack-keystone14:29
*** zigo has quit IRC14:31
*** junhongl__ has quit IRC14:32
*** dims has joined #openstack-keystone14:33
*** xxj has quit IRC14:34
*** wpf1 has quit IRC14:34
*** dims_ has joined #openstack-keystone14:34
*** zigo has joined #openstack-keystone14:35
*** esp has quit IRC14:38
*** dims has quit IRC14:38
*** esp has joined #openstack-keystone14:41
*** chuckcarmack has joined #openstack-keystone14:44
*** jasondot_ has joined #openstack-keystone14:45
*** xxj has joined #openstack-keystone14:45
*** wpf1 has joined #openstack-keystone14:46
*** junhongl__ has joined #openstack-keystone14:46
*** rm_work is now known as rm_work|away14:47
*** zz_avozza is now known as avozza14:49
*** openstackgerrit has quit IRC14:52
*** openstackgerrit has joined #openstack-keystone14:52
openstackgerritMerged openstack/pycadf: Add a new CADF type for keystone trusts  https://review.openstack.org/15153614:52
*** ayoung has joined #openstack-keystone14:58
*** ChanServ sets mode: +v ayoung14:58
*** jsavak has quit IRC15:03
*** joesavak has joined #openstack-keystone15:03
*** rm_work|away is now known as rm_work15:04
*** marg7175 has joined #openstack-keystone15:06
*** jsavak has joined #openstack-keystone15:10
*** carlosmarin has joined #openstack-keystone15:11
*** dims_ has quit IRC15:13
*** joesavak has quit IRC15:13
*** dims has joined #openstack-keystone15:14
*** richm has joined #openstack-keystone15:14
*** timcline has joined #openstack-keystone15:24
*** timcline has quit IRC15:25
*** timcline has joined #openstack-keystone15:25
rodrigodsbknudson, ping re: your comment regarding the utils.positional decorator here https://review.openstack.org/#/c/115770/18/keystoneclient/v3/projects.py15:28
openstackgerritMarco Fargetta proposed openstack/keystone: IdP ID registration and validation  https://review.openstack.org/15215615:28
rodrigodsbknudson, what did you meant by error?15:28
*** ajayaa has joined #openstack-keystone15:31
bknudsonrodrigods: should be utils.positional.EXCEPT15:32
bknudsonrodrigods: see http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/utils.py#n27415:32
bknudsonalso, there's lots of documentation for that class.15:32
rodrigodsbknudson, thanks15:36
bknudsonrodrigods: there ought to be a test where projects.create is called with parent=a project object , rather than parent=a string15:38
bknudsonsince that's supported15:38
*** henrynash has joined #openstack-keystone15:39
*** ChanServ sets mode: +v henrynash15:39
rodrigodsbknudson, ok, thanks15:39
bknudsonshould be able to call get() to get a Project object and then pass it to create()15:39
bknudsonmaybe create() returns a Project object? Then could call create() to create the parent and then create() again to create the sub-project.15:40
openstackgerritDoug Hellmann proposed openstack/oslo.policy: Fix rst markup in docstring  https://review.openstack.org/15216015:40
*** nkinder has quit IRC15:43
*** henrynash has quit IRC15:46
*** andreaf is now known as andreaf_15:47
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577015:52
rodrigodsbknudson, tried to address all your comments ^15:53
rodrigodsbknudson, thanks for the review15:53
bknudsonrodrigods: is there some reason that test_create_with_parent_project needs to copy so much code from test_create? why not just use test_create?15:56
bknudsonhttp://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/tests/v3/utils.py#n19615:56
*** henrynash has joined #openstack-keystone15:59
*** ChanServ sets mode: +v henrynash15:59
rodrigodsbknudson, there was a patchset in which we were reusing test_create15:59
rodrigodsbknudson, not sure why I reverted that15:59
bknudsonrodrigods: that seems like the best way to go if it can do the testing we need.16:00
bknudsonor, it might be better to fix test_create() so that it can do what's needed.16:00
bknudsonsince other tests will probably want to do the same thing.16:00
rodrigodsbknudson, gotcha16:00
rodrigodshenrynash, can you take a look in https://review.openstack.org/#/c/148567/ ? addressed your comments after the rebase16:01
*** zzzeek has joined #openstack-keystone16:03
*** rodrigods has left #openstack-keystone16:07
*** rodrigods has joined #openstack-keystone16:07
openstackgerritMerged openstack/oslo.policy: Correct docstring references  https://review.openstack.org/15181316:07
*** bjornar has quit IRC16:07
*** stevemar has joined #openstack-keystone16:07
*** ChanServ sets mode: +v stevemar16:07
*** thedodd has joined #openstack-keystone16:09
rodrigodsbknudson, there are no tests where it passes an entity instead of the ID (for several objects, like users and projects (with domains)), think we can improve test_create() to check this cases but in a different patch, what do you think?16:10
openstackgerritRodrigo Duarte proposed openstack/python-keystoneclient: Hierarchical multitenancy basic calls  https://review.openstack.org/11577016:10
*** chuckcarmack has left #openstack-keystone16:10
bknudsonrodrigods: what happens if an object is passed?16:11
rodrigodsbknudson, the parameter goes through this method: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/base.py#L3416:11
rodrigodsbknudson, now I see it accepts only dicts and strings, not the object itself16:12
rodrigodsbknudson, oops, its the contrary :)16:12
bknudsonrodrigods: getid will return obj.id.16:12
bknudsonif it's got one.16:12
rodrigodsbknudson, yes...16:13
henrynashrodigods: done16:16
*** abhirc has joined #openstack-keystone16:16
raildostevemar, ping, I'm creating the API spec for reseller and I need to mark this new API calls to expiremntal. morganfainberg spoke to me that you know what I have to do. Can you help me with this?16:17
*** david-lyle_afk is now known as david-lyle16:19
openstackgerritMerged openstack/oslo.policy: Add docstrings for check classes  https://review.openstack.org/15182216:21
openstackgerritMerged openstack/oslo.policy: Remove use of graduated modules  https://review.openstack.org/15182916:21
stevemarraildo, i'll ping you back in a bit about the details for that16:23
raildostevemar, great. thanks!16:24
raildomorganfainberg, I commit the API spec with the reseller spec or is it better commit in a separate patch?16:31
rodrigodshenrynash, not sure if I follow your suggestion here https://review.openstack.org/#/c/148618/15/keystone/tests/test_v3_assignment.py16:31
rodrigodshenrynash, thanks for the review, btw16:31
henrynashrodigods: so _build_subtree_as_ids_dict() takes list of caches subtrees (if I am understanding the code right)….I’d just like a more complex tree to ensure this is working correctly…i.e. multiliple children of A, of which at least 2 have sub projects16:34
*** rwsu-afk is now known as rwsu16:40
*** hogepodge has quit IRC16:40
*** gyee has joined #openstack-keystone16:50
*** ChanServ sets mode: +v gyee16:50
openstackgerrithenry-nash proposed openstack/keystone: Improve creation of expected assignments in tests  https://review.openstack.org/14454416:57
stevemargordc, damn, i was hoping you could definitively give me an answer if re-using `resource_info` was a bad idea or not16:57
gordcstevemar: you can probably tack on resource_info to the same location... it'd be better if you had it in 'target'17:00
openstackgerrithenry-nash proposed openstack/keystone: Refactor check of targets and actors on RoleV3  https://review.openstack.org/14470217:00
gordcstevemar: i think for me, it's more should you be using same event_type if it's a noticeably different message17:00
*** abhirc_ has joined #openstack-keystone17:01
*** timcline has quit IRC17:01
rodrigodshenrynash, gotcha17:01
*** timcline has joined #openstack-keystone17:01
openstackgerrithenry-nash proposed openstack/keystone: Check for invalid filtering on v3/role_assignments  https://review.openstack.org/14470317:02
morganfainbergraildo, either17:03
*** abhirc has quit IRC17:03
*** tqtran has joined #openstack-keystone17:04
raildomorganfainberg, ok :)17:04
samueldmqhenrynash, ping17:05
*** hogepodge has joined #openstack-keystone17:05
henrynashsamueldmq: hi....17:05
openstackgerrithenry-nash proposed openstack/keystone: Improve List Role Assignment Tests  https://review.openstack.org/13702117:05
rodrigodshenrynash, are you ok with a hierarchy like http://paste.openstack.org/raw/165680/  ?17:06
samueldmqhenrynash, thanks for rebasing that chain, I'm working now on fixing some nits , etc17:06
*** timcline has quit IRC17:06
henrynashsamueldmq: I’m just rebasing them all17:06
*** timcline has joined #openstack-keystone17:06
samueldmqhenrynash, yes I saw :)17:06
henrynashsamueldmq: since all the following on ones suffer17:06
samueldmqhenrynash, ++17:06
stevemargordc, i figured we could save on a lot of ceilometer code changes this way :)17:07
*** hogepodge has quit IRC17:07
gordcstevemar: lol.17:07
rodrigodsmorganfainberg, https://review.openstack.org/#/c/148567/ was already approved but I had to rebase =/17:08
gordci mean it's not the end of the world... you definitely shouldn't send it twice like your current code does though.17:08
bretonso, was the client released?17:08
morganfainbergbreton: no, that was one of my plans for today.17:08
*** hogepodge has joined #openstack-keystone17:09
openstackgerrithenry-nash proposed openstack/keystone: Improve List Role Assignments Filters Performance  https://review.openstack.org/13720217:09
morganfainbergThough, we maaaaaay want to wait till after this week. So accidental breakage doesn't clog the gate.17:09
morganfainbergTtx might appreciate that.17:09
morganfainbergjamielennox: ^ still would be early feb. Just right post k217:10
openstackgerrithenry-nash proposed openstack/keystone: Add support for data-driven backend assignment testing  https://review.openstack.org/14917817:10
stevemargordc, the config option should keep it to either one or the other, not both being emitted btw17:10
openstackgerrithenry-nash proposed openstack/keystone: Add support for effective & inherited mode in data driven tests  https://review.openstack.org/15162317:11
openstackgerrithenry-nash proposed openstack/keystone: Add support for group membership to data driven assignment tests  https://review.openstack.org/15196217:11
*** henrynash has quit IRC17:12
openstackgerritRodrigo Duarte proposed openstack/keystone: Implements subtree_as_ids query param  https://review.openstack.org/14861817:18
openstackgerritRodrigo Duarte proposed openstack/keystone: Implements subtree_as_ids query param  https://review.openstack.org/14861817:18
*** EmilienM is now known as EmilienM|afk17:18
gordcstevemar: ... oh. right. the logic was split in two different places... i'll take a look again after lunch17:21
dstanekayoung: can you confirm that this has been implemented: https://review.openstack.org/#/c/148053/17:21
*** _cjones_ has joined #openstack-keystone17:22
gyeemorganfainberg, https://bugs.launchpad.net/python-keystoneclient/+bug/141718917:26
TempLPBugBot`Launchpad bug 1417189 in python-keystoneclient "Keystone v2 list users by name should be supported to avoid potential performance problem" (affected: 1, heat: 6) [Undecided,New]17:26
morganfainberggyee: is that a cli request or a lib request?17:26
morganfainbergIf it's cli- the answer is very simple. If it's lib, as long as keystone supports it in its api that is fine to add.17:27
gyeemorganfainberg, lib fix is essential17:27
gyeemorganfainberg, I'll trying to fix lib first, then the CLI part if needed17:28
morganfainbergCli is not going to happen in keystoneclient.17:29
morganfainbergAlso listing users is insane.17:30
gyee:)17:30
morganfainbergBut that is a different topic.17:30
stevemargyee, i don't see how you can fix that?17:30
gyeeyeah, fetch all then do linear search17:30
stevemargyee, unless you try .get(id) first17:30
morganfainberggyee: uh isn't there a get user by name?17:30
gyeestevemar, marganfainberg, right, get user by name is supported17:31
morganfainbergRest api that is?17:31
gyeewe just need to pass the param from keystoneclient17:31
morganfainbergOh god. No wait. Is that an api?17:31
gyeesi amigo17:31
morganfainbergUgh.17:31
stevemargyee, oh just pass --name to the list() function17:31
morganfainbergNo it's list + filter17:31
gyeeyes17:31
morganfainbergIt isn't "get user by name"17:31
stevemarlist + filter won't work i think17:32
morganfainbergWhy do we need to support this in client?17:32
gyeebecause API supports it17:32
morganfainbergThat isn't going to solve the performance issue.17:32
morganfainbergFwiw, client or server will still be doing the insane question.17:33
morganfainbergWith 400.000 records you are asking an insane question.17:33
stevemari needs to call .get with the exact user name17:33
stevemarit*17:33
gyeemorganfainberg, if we pass the param, LDAP filter will be constructed accordingly17:33
morganfainbergExpect insane behavior (not saying we can't fix but today it will be just as bad)17:33
gyeestevemar, user_id is not known ahead of time17:34
gyeejust username17:34
stevemargyee, i'd be happy to be wrong, try it out17:34
morganfainberggyee: it might be less expensive to POST a new user and get a conflict than do a linear search. Out ldap backend doesn't filter well17:34
gyeestevemar, I got fart in the face last week because of this one17:34
morganfainbergOur*17:35
gyeemorganfainberg, it does, get_user_by_name() does contrust the proper LDAP filter17:35
gyeeconstruct17:35
gyeewe just need to trigger it17:36
morganfainbergList != call get user by name.17:36
morganfainbergDon't expect it to17:36
gyeebut that's now the API works right? GET /v2.0/users?name=foo17:36
gyeethat's the same paradigm v3 is using I think17:37
gyees/using/following/17:37
*** marg7175 has quit IRC17:37
morganfainbergCheck. I think it actually hits the list function.17:38
*** marg7175 has joined #openstack-keystone17:38
gyeeyes, keystoneclient actually calls the list() function17:38
gyeeif we pass that param, we can avoid cache all users17:39
morganfainbergDo not assume the server is doing something sane in this regard.17:39
*** jistr has quit IRC17:39
gyeeno, not assuming anything, just do what the API said :)17:40
morganfainbergIf you want a get user by name, it should be its own api. If the action is "list" don't trust the server to not be doing the same insane thing and getting 400,000 records back17:40
gyeeoh17:40
gyeeI am cool with a separate call17:40
gyeemore obvious17:40
morganfainbergNow there is a bigger issue17:41
morganfainbergUsernames are not urlsafe17:41
morganfainbergAfaik17:41
gyeeurlencode?17:41
*** _cjones_ has quit IRC17:41
morganfainbergCrappy ux to ask the client to do so, but probably required. Unless you implement a "find user" where you can use post17:42
morganfainbergS/client/user17:42
gyeemorganfainberg, why ask the clients to do it, we can do urlencode before putting it onto the wire right?17:42
morganfainberggyee: direct api requests.17:43
gyeebut can't we do this in keystoneclient?17:43
gyeeor you mean on the documentation side?17:43
morganfainbergWe can, but again, crappy ux when not using ksc17:43
gyeeheh17:43
gyeeI see17:43
morganfainbergI really think this is a 2 fold problem: 1) God the directory server is horribly misconfigured.17:44
morganfainberg2) I think the user is doing things very wrong and we could advise changing how things are done to mitigate the issue. This won't be fixed simply with a client fix17:45
gyeebut they can't avoid it through, there are really that many users17:45
morganfainbergIt likely requires keystone fixes as well, meaning performance issue doesn't go away.17:45
*** atiwari1 has quit IRC17:46
gyeeI suppose they can configure it to limit the number of entries return, but that won't solve the problem17:46
morganfainbergDon't do a name-based search through 400,000 users17:46
morganfainbergLet's start there.17:46
gyeeI don't see a really good alternative given that all they got is username to start with17:47
gyeebut yes, we need a server side fix at some point17:47
gyeefetch all and then do linear search is bad17:47
gyeedouble bad17:47
morganfainbergA better solution in this case is try to make the user - fail when there is a conflict.17:48
morganfainbergIn the os-config bit. Fail gracefully17:48
morganfainbergrather than look for the user before creating.17:48
gyeesure they can do that, but that would be like trying to dance around API limitations17:49
morganfainbergSame concept of how we handle it in code for a lot of things. Cheaper to get a failure than a look for things before we create it.17:49
gyeein theory, lookup by name should be efficient17:49
morganfainbergThe API is limited. And you are always going to be dancing around it17:49
morganfainbergExcept not all deployments are asking an insane question "list all my users". I'd argue .find() is a bad api on keystoneclient to support.17:50
stevemargyee, it's not really an API limitation, it's an LDAP limitation17:51
gyeestevemar, people program to API, not implementation17:51
morganfainberggyee: in this case they are programming to the implementation!17:51
morganfainbergThe API does not support "get user by name"17:52
gyeeno, they call find user by name and expect it to be happy17:52
gyeeit does17:52
*** _cjones_ has joined #openstack-keystone17:52
morganfainbergKeystoneclient is the implementation. They are not programming to the API17:52
morganfainberg.find is a bad api to use with a lot of users17:53
gyeekeystoneclient is API right?17:53
morganfainbergS/api/call17:53
morganfainberggyee: it's an abstraction over the API.17:53
morganfainbergAnd in this case it provides a poor call to something the API doesn't support17:54
gyeeshort of asking them to write their own client, we'll need to fix the stuff17:54
morganfainbergWe do not need to fix this. We could fix os-config17:54
gyeeI don't understand, but what is 'GET /v2.0/users?name=foo'?17:55
morganfainbergThat is telling the server to filter. That may or may not be a good call to make when you have 400,000 records.17:55
stevemarwe need another +2/+A on this chain https://review.openstack.org/#/c/148019/17:55
morganfainbergFiltering is at best partially implemented "correctly". Even in the best apps you might get crap performance with tons of records to search through. You *do* program to the known limitations17:57
gyeeso keystoneclient will not support it even though API does?17:57
morganfainbergThe point is the API doesn't really support it.17:57
morganfainbergIt sortof does with a dodge.17:57
morganfainbergAnd likely shouldn't be used. Hell id prefer list users to go away if it was possible.17:58
morganfainbergIt is not a sane question to ask when you have federation, multiple per-domain backends, etc17:59
bknudsonmorganfainberg: list users doesn't work if you have per-domain backends.17:59
gyeebknudson, this is v2 api17:59
morganfainbergbknudson: beat ya to it by a second. ;)17:59
*** spandhe has joined #openstack-keystone17:59
gyeethis is not list users, more like find by name17:59
morganfainberggyee: and v2 is rapidly headed towards deprecstion and obselecence.17:59
bknudsondoes v2 api only return the default domain users?17:59
gyeeyes17:59
bknudsonseems like v3 should be used if it supports what you want already18:00
gyeebknudson, v3 does the same thing with list users18:00
*** EmilienM|afk is now known as EmilienM18:00
gyeefetch all and do linear search18:00
morganfainbergbknudson: it sortof does but not well. This is another "hp has 400,000 users in something and we're searching through them"18:00
morganfainbergTo save a conflict on create.18:01
morganfainbergCheck if user exists, if not, create18:01
bknudsondon't need keystone for that... do the LDAP query yourself.18:02
gyeehahaha18:02
morganfainbergThe issue is triple o.18:02
bknudsoneither way I'd prefer it was implemented in v318:02
morganfainbergbknudson: I agree at the very least there.18:02
morganfainbergI don't want to add anything else to v2.18:02
gyeedude, here we are, v3 have the same problem with searches18:03
morganfainbergWe could fix triple o here gyee18:03
morganfainbergIt will also fix it for all keystone deploys.18:03
gyeesure, less work for me :)18:03
morganfainbergNot just kilo forward.18:03
gyeemorganfainberg, can you reply to that email so it'll cover my ass?18:04
openstackgerritMerged openstack/python-keystoneclient: Docstring usability improvements  https://review.openstack.org/12785618:04
gyeeask them to fix the shit in tripleO18:04
*** _cjones_ has quit IRC18:06
morganfainberggyee: yes I'll get to it today. But the gist is going to be that fixig it in keystone is not solving the immediate problem and won't solve deployments not on kilo + because backport of a big change like this (or new apis) will not fly.18:06
gyeemorganfainberg, thanks, that should do it18:07
morganfainbergIf we do a get user by name api, we should at it to v3 keystone.18:07
morganfainbergAnd it will need to be classified under a specific domain18:07
gyee++18:08
*** _cjones_ has joined #openstack-keystone18:08
morganfainbergE.g. /domain/{id}/user_by_name18:08
morganfainbergBut less crappy18:08
morganfainberg;)18:08
*** atiwari has joined #openstack-keystone18:08
gyeev3 ldap code have the same problem, https://github.com/openstack/keystone/blob/master/keystone/identity/backends/ldap.py#L8218:10
gyeewe'll need to fix that as well18:10
stevemaralso this one is generating a lot of questions during other reviews: https://review.openstack.org/#/c/151505/18:10
*** thedodd has quit IRC18:11
morganfainberggyee: more to the point. Tripleo should work with a readonly ldap backend and not try to creat users.18:11
gyee++, that code is crappy18:11
morganfainbergI assume tripleo does not have access to create users in the hp corp directory18:11
gyeeno, it does not18:11
morganfainbergSo why are we letting it even Ty.18:11
morganfainbergTry*18:11
*** harlowja has joined #openstack-keystone18:11
gyeeyeah, that code is voodoo18:12
morganfainbergyeah this looks like an even easier fix: don't lookup the user if you aren't going to even try to add the user because it would fail anyway.18:12
gyeethey should be able to opt-out user creation with a param or env var or something18:13
*** rushiagr is now known as rushiagr_away18:14
amakarovmorganfainberg, ayoung greetings! I have a bug fix for trusts https://review.openstack.org/#/c/148642/, can you please look at it?18:14
morganfainberggyee: exactly.18:14
gyeestevemar, a lot of questions on this one? https://review.openstack.org/#/c/151505/18:16
gyeethat was a joke right?18:16
stevemargyee, i mean a lot of other reviews are changing the sample conf, and hitting the same changes, and reviewers are -1'ing because of it :)18:17
gyeeisn't there a wonderful feature called "rebase" or something?18:17
morganfainbergPlease, as core, do not minus one for sample config18:18
gyeeyeah man, what the hell :)18:18
morganfainbergIn fact, let's just go back to we generate he sample config every now and again18:18
morganfainbergIf other people are -1 for not running a generate of sample config, please comment it can be done after the code lands.18:19
morganfainbergI'd rather have the core team run an update once a week than have the rebase hell we have now.18:19
stevemarmorganfainberg, i'm fine with that18:19
*** jasondot_ has quit IRC18:20
gyeedude, have a bot do this!18:20
morganfainberggyee: there is a lot of discussion on the ml about how openstack should handle it18:20
morganfainbergIf I could remove the sample config until that discussion is solved, I would just to make the -1s go away18:20
gyeeI would make the bot do it18:21
morganfainbergSo, please don't block patches on running sample config updates. And encourage people to do those updates out of the patch chains if at all18:21
morganfainberggyee: they are trying to figure out where to put sample config if at all18:21
morganfainbergBut for now: just encourage people to run sample config updates outside of he patch chains.18:23
gyeepersonally I like sample config, saved me from digging into the code18:23
morganfainbergAnd don't block patches for it not being updated. Don't hesitate to override a -1 that is only because of sample config.18:23
morganfainberg(But comment to the effect)18:23
morganfainberg*only because they didn't update sample config18:24
richmhello keystone devs - looking for information about legal/illegal characters in names of users, projects, roles, and domains - are there any?  I would think that "@" is not a valid character18:26
*** ajayaa has quit IRC18:27
richmthe reason is puppet - we need to have unique names for resources such as users, etc.18:27
richmwe'd like to be able to use "@" as a delimiter e.g. keystone_user { "username@domain" }18:27
morganfainbergrichm: sadly @ has always been valid.18:29
stevemarrichm, depends on the backend18:29
morganfainbergSo we can't remove that.18:29
morganfainbergI know deployments that use email as usernames in default domain.18:29
*** afazekas has quit IRC18:30
morganfainbergNot sure how to unwind that.18:30
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone-specs: Reseller  https://review.openstack.org/13982418:31
openstackgerritMerged openstack/keystone: Fixes 'OS-INHERIT:inherited_to' info in tests  https://review.openstack.org/14454218:32
*** anish has left #openstack-keystone18:38
richmok - so if "@" is not good, what other characters might be used?18:38
morganfainbergrichm, i think ayoung had some ideas on how to handle that18:47
morganfainbergbut i don't have a good answer18:47
morganfainbergstevemar, dstanek, dolphm, bknudson, jamielennox, ayoung, topol, http://lists.openstack.org/pipermail/openstack-dev/2015-February/055815.html18:48
morganfainbergquick email about sample config(s)18:48
*** pnavarro has joined #openstack-keystone18:50
richmayoung: ping - ^^^18:53
samueldmqmorganfainberg, ++ on sample config regeneration :)18:55
*** henrynash has joined #openstack-keystone18:55
*** ChanServ sets mode: +v henrynash18:55
bretonack18:56
*** lhcheng has joined #openstack-keystone18:58
*** aix has quit IRC18:59
*** timcline has quit IRC19:01
morganfainbergbreton: will sync with jamielennox today and either cut today or end of week post k2. Likely the latter.19:01
*** jasondot_ has joined #openstack-keystone19:02
openstackgerritSteve Martinelli proposed openstack/keystone: Add WebSSO support for federation  https://review.openstack.org/13617719:04
*** timcline has joined #openstack-keystone19:04
morganfainbergstevemar: +2 on a couple of specs.19:04
*** timcline has quit IRC19:06
stevemarmorganfainberg, i'll take a look at the open specs19:06
*** amakarov is now known as amakarov_away19:07
*** timcline has joined #openstack-keystone19:07
samueldmqhenrynash, I removed regex from my tests ... you convinced me that those tests should be simpler19:13
samueldmqhenrynash, I'm working on doc improvement nw19:13
samueldmqs/nw/now19:13
openstackgerritRodrigo Duarte proposed openstack/keystone: Drop URL field from region table  https://review.openstack.org/15012219:16
henrynashsamueldmq: ol :-)19:18
*** henrynash has quit IRC19:23
*** EmilienM is now known as EmilienM|afk19:25
openstackgerritMerged openstack/keystone: During authentication validate if IdP is enabled  https://review.openstack.org/15168319:31
openstackgerritMerged openstack/keystone: Change oslo.utils to oslo_utils  https://review.openstack.org/14801919:32
openstackgerritMerged openstack/keystone: Regenerate sample config file  https://review.openstack.org/15150519:32
*** nellysmitt has quit IRC19:34
dstanekmorganfainberg: okay, dokay - i'll -1 anything that has a sample config modification19:36
* dstanek pulls out a big red pen19:36
bknudsonI'm sure some of mine have sample config changes.19:39
*** thedodd has joined #openstack-keystone19:41
gyeefo sho19:41
*** EmilienM|afk is now known as EmilienM19:50
*** topol has joined #openstack-keystone20:01
*** ChanServ sets mode: +v topol20:01
*** timcline has quit IRC20:02
*** jasondot_ has quit IRC20:02
*** timcline has joined #openstack-keystone20:02
*** timcline has quit IRC20:03
raildotopol, ping, if you have some time, can you review the reseller spec? :) https://review.openstack.org/#/c/139824/20:04
topolraildo, sure20:04
*** timcline has joined #openstack-keystone20:04
raildotopol, thanks!20:04
morganfainbergbknudson, if they have a config and merge great, if not lets push new changes over to the new email.20:04
*** timcline_ has joined #openstack-keystone20:05
openstackgerritRodrigo Duarte proposed openstack/keystone: Create K2K SAML assertion from Service Provider  https://review.openstack.org/15204620:07
openstackgerritRodrigo Duarte proposed openstack/keystone: Service Providers API for OS-FEDERATION  https://review.openstack.org/10462320:07
openstackgerritRodrigo Duarte proposed openstack/keystone: Drop URL field from region table  https://review.openstack.org/15012220:07
openstackgerritRodrigo Duarte proposed openstack/keystone: Update federation config to use Service Providers  https://review.openstack.org/15226020:07
openstackgerritMerged openstack/keystone: Multiple IDP authentication URL  https://review.openstack.org/14274320:08
*** timcline has quit IRC20:08
rodrigodsmarekd, stevemar ^20:09
marekdyay20:09
openstackgerritMerged openstack/keystone: Fix typo in Patch #142743  https://review.openstack.org/15201620:09
marekd^^ YAY20:10
morganfainbergmarekd, your other spec has a +2 as well i think20:11
morganfainbergthe map to direct users20:11
marekdmorganfainberg: thanks!20:12
marekdmorganfainberg: i was working on K2K and going to start implementing 'map to direct users' this week.20:12
morganfainbergawsome20:12
marekdmorganfainberg: https://review.openstack.org/#/c/152046/8/keystone/contrib/federation/controllers.py,cm anyway, see here line 294. I am introducing two new params in header. If we don;t like it the sooner I know it the better :-)20:14
morganfainberglooking20:14
*** Ephur has joined #openstack-keystone20:17
ayoungrichm, I think what we need to be able to do is use the @ to split in the mapping front end, but we can't do it as something that Keystone depends on20:18
samueldmqmorganfainberg, do you know what is the right place to ask devstack related questions?20:19
samueldmqmorganfainberg, is it #openstack-sdks ?20:19
morganfainbergsamueldmq, #openstack-qa20:20
morganfainbergor #openstack-infra [depending on the nature of the question]20:20
morganfainbergif it's gate related -infra *might* get faster responses20:20
morganfainbergif it's devstack specific -qa is the right place20:21
morganfainbergas -qa owns devstack20:21
morganfainbergmarekd, what would the alternatives to additional headers be?20:21
morganfainbergmarekd, before i really weigh in20:21
marekdmorganfainberg: so, this info is actually in the service catalog, but then ksc would need to store it locally for the time being where the token is traded for saml assertion, assertion is returned to the client, assertion is sent to SP_URL of the Service Provider, and later, an unscoped OS-FEDERATION token is retrieved from the Service Provider.20:26
marekdlocally ~ somewhere in the session object. Somewhere where those parameters will persist between the HTTP calls.20:27
morganfainberggyee, email reply sent20:32
*** jasondot_ has joined #openstack-keystone20:33
gyeemorganfainberg, thanks!20:36
morganfainberggyee, i think it'll make your job much easier20:37
morganfainbergproposed *just* what we talked about, triple-o able to install against read-only data store20:38
morganfainberg"don't even try making users"20:38
gyeehell yeah20:39
gyeeyou sum it up beautifully20:40
morganfainbergmarekd, i think we could either extract from the SC and store it in session20:40
morganfainberg*or* use the headers20:40
morganfainbergthis is a case i think the headers might be a better choice.20:40
gyeefood time20:40
morganfainberggyee, late today huh?20:41
raildogyee, I see your comments in the reseller spec, I agree with you, I'll just wait for more comments, ok?20:41
gyeeraildo, yeah, looks good mostly20:41
samueldmqmorganfainberg, k thanks (#openstack-qa)20:41
gyeemorganfainberg, yeah, good news is there's a food truck nearly where I live now :)20:42
gyeeonly vietnamese food for now20:42
morganfainbergmarekd, i support using the headers in this case.20:44
topolmorganfainberg, when is the deadline for specs to be merged?20:45
*** jasondot_ has quit IRC20:45
marekdmorganfainberg: ++20:45
morganfainbergFeb 5th20:45
morganfainbergtopol, ^20:45
morganfainbergtopol, lets make it clear, Feb 5th, before 23:59 Pacific time :P20:45
morganfainbergafter that i'll want a ML topic asking for an exception - but otherwise the specs all proposed against kilo will get a procedural -220:46
morganfainbergthat haven't merged.20:46
topolmorganfainberg, awesome. Is there a subset of ones to focus on (yes raildo, reseller :-) I know)20:46
*** nellysmitt has joined #openstack-keystone20:47
raildotopol, hahaha20:47
morganfainbergtopol, the federation one(s) from marek20:47
topolmorganfainberg OK.20:47
morganfainbergtopol, and probably ayoung's ones20:47
morganfainbergtopol, but check w/ ayoung about which ones20:48
topolayoung, let me know which ones. morganfainberg said you had about 3 hot ones20:49
ayoungtopol, morganfainberg I've given up on actually making forward progress.  We don't start discussing specs until the summit, spent the first milestone squabbling, and the get to the 2nd milestone and freeze.  I'm just going to keep writing code and it will get in eventually20:50
ayounglet's see...20:50
marekdtopol: https://review.openstack.org/#/c/149071/ that one is mine not yet merged.20:51
ayounghttps://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+owner:ayoung,n,z  thati s my list20:51
ayoungcertmonger should get approved..that should be a no brainer20:51
morganfainbergayoung, i have one comment on that one.20:51
ayoungyeah...I'll address shortly20:51
openstackgerritRodrigo Duarte proposed openstack/oslo.policy: Drop usage of namespaced packages  https://review.openstack.org/15183620:52
morganfainbergayoung, otherwise yes that one looks fine20:52
ayoungmorganfainberg, my view is:  if certmonger is missing, then we do nothing20:52
ayoungthe current ssl/pki setup is not really a production quality thing20:52
ayoungand, since we don;'t really need either, we can safely drop it20:52
ayoungwe are defaulting to uuid tokens20:52
ayoungso no pkisetup needed20:52
ayoungand the ssl setup is done via puppe20:53
ayoungt20:53
ayoungmorganfainberg, I wish we could just edit the specs online20:53
morganfainbergayoung, can certmonger manage the CA directly?20:53
morganfainbergayoung, or does it need something else e.g. certmaster/dogtag20:53
ayoungmorganfainberg, question does not really make sense20:54
ayoungah20:54
ayoungyou mean for selfsigned?  Yeah,  it can do that20:54
*** nellysmitt has quit IRC20:54
morganfainbergayoung, as long as it can do that - which is what i was looking for20:54
morganfainbergand certmonger is 1st class in ubuntu as well as fedora?20:54
*** diegows has quit IRC20:54
ayoungit needs a relatively new version of certmonger, but the packages are out for all distros20:54
openstackgerritHenrique Truta proposed openstack/python-keystoneclient: Creating parameter to list inherited role assignments  https://review.openstack.org/11730020:54
morganfainbergayoung, thats fine then. - i'm good with using something better than pki_Setup20:55
ayoungyes, certmonger has been in Ubuntuy for a while, and we have a driver from Canonical for all things cryptolike20:55
morganfainbergi expect you'll provide infomration on how that should work as a transition from pki_setup20:55
ayounghierarchical roles:  punt to Lovelace20:55
morganfainberge.g. "oh hi you tried to do X, do this instead"20:55
ayoungand yes, I hearby declare that the next release is called Lovelace20:56
morganfainbergor even a compat layer telling them pki_setup is going away go look ->> there for how to do it right20:56
ayoungyes20:56
morganfainbergayoung, that is sufficient to answer my comment inline20:56
ayoungI had a bunch of the "test for things:" in the spec, but the reality will be in the code20:56
morganfainbergmy concern was the need for dogtag or certmaster20:56
ayoungUnified Access Info:  I'm actively coding that right now20:56
morganfainbergor something else that wasn't clear20:56
ayoungEnforce policy from keystoneclient  needs to be cahnged to20:57
ayoungEnforce policy from keystonemiddleware20:57
ayoungunified policy file...should go ahead20:57
morganfainbergif certmonger can handle it all for our devstack needs, works for me.20:57
richmayoung: we just need some way to unique-ify names of users, groups, and projects in puppet20:57
ayoungbut that can be off cycle20:57
morganfainbergksc and ksm specs are *not* on the feb 5 deadline20:57
morganfainbergonly keystone server specs20:57
morganfainbergtopol, ^20:57
ayoungrichm, we have a mechanism to do that thanks to Henrynash20:57
ayoungwe do a sha256 of the userid/domainid20:58
rodrigodsayoung, morganfainberg, can count on me to help with those specs as well20:58
morganfainbergrichm, henrynash did a great job on it20:58
ayoungmorganfainberg, I know...20:58
ayoungbut the query doesn't say which they are for...since all are in one repo20:58
ayoungtoken constraints punted to Lovelace20:58
ayoung(named for Ada, not Linda, incase you were wondering)20:58
richmayoung: in puppet, an admin wants to be able to do keystone_user { "admin@domain1" }; keystone_user { "admin@domain2" }20:58
ayoungrichm, I want that to.  I was told I can't have that20:59
richmayoung: because "@" is not usable?20:59
ayoungrichm, best we can do is a json segment20:59
ayoungrichm, because people might have usedf @ signs for usernames or, worse, userids20:59
ayoungAPI changes for explicit unscoped  needs to be approved...its trivial21:00
ayoungAlembic for migrations...punt21:00
morganfainbergayoung, lol21:00
morganfainbergi figured ada not linda21:00
ayoungPolicy rules mangaged from a database:   Punt21:00
ayoungmorganfainberg, both ladies have programmiong languages named after them21:00
richmayoung: so in puppet, something like this: keystone_user { "username": "admin", "domain": "domain1" } ?21:01
richmer keystone_user { '"username": "admin", "domain": "domain1"' }21:01
ayoungrichm, yes21:02
richmayoung: ok21:02
ayoungmorganfainberg, so..back to spec:  punt on multiple signing certificate21:03
ayoungand approve Default Policy21:03
ayoungmorganfainberg, from now on, I think we should submit all specs to "next"21:04
ayoungnothing gets assigned to a release until it gets approved in the abstract...keep us from having to move things arounds21:05
ayoungI don't really see a reson to have the release in the spec  repo,  it belongs outside it in something like the bp manager or whatever we replace that with21:05
*** marg7175 has quit IRC21:07
morganfainbergayoung, this is my complaiunt with using git for specs21:07
morganfainbergit is the wrong tool21:07
morganfainbergit's waaaaay better than launchpad21:07
morganfainbergstill the wrong tool21:07
ayoungmorganfainberg, http://xkcd.com/21:08
ayoungthat is the right tool.21:08
*** raildo is now known as raildo_away21:08
morganfainberghonestly i hope storyboard becomes the bug/bp/spec tracker21:08
morganfainberglike it should be21:08
morganfainbergthen LP can die21:08
topolmarekd, you there?21:10
topolmarekd, re: https://review.openstack.org/#/c/149071/3/specs/kilo/federated-direct-user-mapping.rst21:10
openstackgerritMerged openstack/keystone: Implements parents_as_ids query param  https://review.openstack.org/14856721:14
*** krtaylor has joined #openstack-keystone21:15
stevemartopol, i just approved it, whats up21:15
topolstevemar, I just wanted a little more detail that mentions  the benefits of not treating the users as ephemeral.  Or say what the disadvantages are when this is not done.  This would really help to explain why this is needed. Folks may be confused since we spent so much time on the previous federation work saying this was not needed21:16
morganfainbergtopol, in most cases it isn't needed.21:17
marekdtopol: i am.21:17
openstackgerritMerged openstack/keystone-specs: Allow for direct mapping in federated authN.  https://review.openstack.org/14907121:17
morganfainbergtopol, i prefer the model where we don't need to direct map21:17
*** diegows has joined #openstack-keystone21:17
morganfainbergtopol, but lets def. get some clarificaiton on that in the spec so we can point at it and show the use-case(s)21:18
topolmorganfainberg. Agreed.  so when marekd says some cloud providers want it but its not clear why. Im loking for 1-2 sentences here21:18
marekdtopol: gyee was happy to have it.21:19
morganfainbergmarekd, lol "Because Guang likes it" isn't a good justification21:19
marekdtopol: I'd say thanks to that we can have authN step with a 1-st class IdP21:19
marekdmorganfainberg: agreed.21:19
morganfainbergbut i'd almost pay money to see topol  try and explain that statement to someone trying to setup federated identity21:19
marekd:D21:20
topolmarekd, um yeahhh stevemar just +A'd it :-). Perhaps we add this clarification in a subsequent patch21:20
morganfainbergtopol, we should21:20
marekd"ya know..marekd says guang liked it so we implemented it"21:20
morganfainbergmarekd, ++21:20
morganfainbergmarekd, +∞21:20
stevemarwe can definitely clarify things in another patch21:21
topolmarekd, morganfainberg, stevemar, my only complaint is my fear is that folks will see this and go oh I should do this...But in reality probably only needed in rare circumstances A, B, C.21:21
topolmarekd, morganfainberg, stevemar that was the only missing.  But if we nail that in the docs we should be okay21:22
topolmarekd so I need to know what "thanks to that we can have authN step with a 1-st class IdP" means for folks new to Keystone federation. Remember you live this everyday so its intuitively obvious to you. I need some tutoring  :-)21:23
topolwith ephemeral only we cant do x, y, z.  Thats worth storing all these users. Make sense?21:24
topolmarekd ^21:24
stevemarmarekd, fyi - i'm writing up the changes now21:25
marekdstevemar: ok, thanks.21:25
marekdtopol: right.21:25
atiwaristevemar, yt?21:26
stevemaratiwari, physically yes21:28
marekdtopol: i was probably not clear enough. The thing is, this could probably be the first step where federation becomes a core part of Keystone, and in this easy step we could increase security of authN process, where user needs to authenticate himself with an IdP (and can try only 3 times and later gets blocked, has some kckass 'reset password' procedures and probably more), whereas Keystone is responsible for authZ only, so something ayoung21:28
atiwarithanks, do you have any docs to setup K2K federation?21:29
marekdatiwari: http://rodrigods.com/playing-with-keystone-to-keystone-federation/21:29
*** thedodd has quit IRC21:29
atiwarimarekd, thanks21:29
stevemarthanks marekd, atiwari that's the best source21:29
atiwaristevemar, thanks21:30
ayoungmarekd, passwordsda re stoopid.  Lets use real technologies for secure sign in21:30
*** chipmanc has joined #openstack-keystone21:30
marekdayoung: anything we don't need to implement in Keystone and can leave this work to IdP devs.21:30
ayoungand, yes, lets get Keystone out of the Identity business all-to-gether21:30
ayoung:)21:31
marekdayoung: that's why  https://review.openstack.org/14907121:31
topolmarekd, so make sure somewhere we capture when to use this and why and when not to use it. That will really help.21:31
marekd(and also because gyee  liked it)21:31
ayoungmarekd, lets go one step further and do that in auth token middleware!21:32
marekdayoung: how?!21:32
marekdtopol: right!21:32
ayoungmarekd, http://adam.younglogic.com/2014/10/who-can-sign-for-what/21:32
morganfainbergayoung, lets just rewrite all of keystone to be auth_token middleware21:33
morganfainbergwhy have an API at all21:33
ayoungmarekd, bascially, anything that we do as part of the token-creationg process we make an externizable process21:33
ayoungmorganfainberg, I have an naswer to that:21:33
ayoungwe have APIs to fetch the data necessary to do this21:33
ayoungmorganfainberg, so, yes, all of the business logic inside Keystone moves to auth_token middleware21:33
morganfainbergayoung, break people of the habit to make it so i do X on behalf the user to api Y21:34
morganfainbergand the security model we use there and we're a step closer21:34
ayoungmorganfainberg, you really want signed requests, don't you?21:34
ayoungwell, the mechanism I lay out there would actually support it21:34
morganfainbergayoung, would work the same if you used x50921:34
morganfainbergetc21:35
morganfainbergsigned requests are just one form that doesn't work with the current model we use21:35
morganfainbergbut lots of people get it because lots of people use AWS21:35
ayoungmorganfainberg, it would if:  nova generated the request, handed it to the user, user signed it, and handed i back to Keystone21:36
ayounger Nova21:36
ayoungbut going direct to glance first makes more sense, obviously21:36
morganfainbergayoung, i am not advocating one fix or another.21:36
ayoungmorganfainberg, I am.21:36
morganfainbergjust saying where the problem currently lies.21:36
openstackgerritSteve Martinelli proposed openstack/keystone-specs: Address federated domain comments from 149071  https://review.openstack.org/15228121:37
ayoungmorganfainberg, kinda sick of discussing this,.  really just need to find funding to go skunkworks this and come back with a fait accompli21:37
marekdstevemar: Thanks, Steve(n) :-)21:39
openstackgerritRodrigo Duarte proposed openstack/keystone: Update federation config to use Service Providers  https://review.openstack.org/15226021:40
stevemarmarekd,  :O21:40
stevemarmarekd, one last patch needed for full SP support, need a way to include it in the catalog21:41
ayoungbknudson, did I just trigger a curse word out of you on a review...21:42
ayounghttps://review.openstack.org/#/c/117366/21:42
marekdstevemar: started working on that today21:42
marekdsimply didn't publish anything yet.21:42
marekd(had to look around where changes are required).21:43
openstackgerritSamuel Merritt proposed openstack/keystonemiddleware: Make v3 auth work for Swift  https://review.openstack.org/15228321:43
topolstevemar, nice job.  that justification helped a lot. re https://review.openstack.org/#/c/152281/21:45
marekdtopol: stevemar  ++21:47
* topol back to reseller21:48
jamielennoxayoung: so s4u2proxy....21:52
ayoungyeah21:52
krtaylormorganfainberg, we will turn off commenting immediately21:53
jamielennoxayoung: is this still the way to do it: http://adam.younglogic.com/2014/05/s4u2proxy-horizon/21:54
jamielennoxthere's no way i can do this without editting ldap schemas21:54
ayoungjamielennox, not yet21:55
jamielennox:(21:55
*** thedodd has joined #openstack-keystone21:55
ayoungjamielennox, I know the IPA team is working on it, but I don't think it is in the project yet21:55
*** chipmanc has quit IRC21:56
morganfainbergkrtaylor, thanks21:56
morganfainbergkrtaylor, yeah i want to know what you're looking at solving and the meeting is the best place21:57
morganfainbergkrtaylor, as you can imagine we need to make sure the gate has good signal to noise21:57
jamielennoxayoung: this is a horrible story, i just want to click a few buttons21:57
jamielennoxor 1 button21:57
ayoungjamielennox, no soup for you21:57
morganfainbergkrtaylor, and to be clear, i'm not opposed to reporting just need to know some details :) thanks for the quick response21:57
krtaylormorganfainberg, I undertand completely, in a nutshell, we are just test on our platform, its a different non-x86 environment21:58
krtaylorwe will be happy to come to a meeting and explain21:58
morganfainbergsure. but how does a change in keystone actually impact the hypervisor? thats what i'd like you to come and explain tomorrow if you have time21:58
krtaylormorganfainberg, can I add to then next agenda?21:58
morganfainbergkrtaylor, please do!21:58
krtaylormorganfainberg, will do21:59
morganfainbergkrtaylor, great! see you there :)21:59
ayoungjamielennox, the think is, I don't really like the S4U2 Appraoch anyway.  It gives away too much, but it is a necessary evil for the existing Openstack delegation model.21:59
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve creation of expected assignments in tests  https://review.openstack.org/14454421:59
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Refactor check of targets and actors on RoleV3  https://review.openstack.org/14470222:00
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Check for invalid filtering on v3/role_assignments  https://review.openstack.org/14470322:00
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Improve List Role Assignment Tests  https://review.openstack.org/13702122:00
*** samueldmq is now known as samueldmq-away22:00
jamielennoxayoung: i feel like it shouldn't be necessary, but i don't know enough to figure out what i don't know22:01
jamielennoxayoung: really we should have named federation something else and made it the entry point for all external mechanisms22:03
jamielennoxayoung: when i get all this figured out i'll look into why we can't just run kerberos at22:03
jamielennox /OS-FEDERATION/REALM/idp/krb22:03
jamielennox(or whatever the proper url is now)22:03
jamielennoxbecause i don't like / see why we should need to mount the whole keystone server again at /krb or whatever22:04
*** pnavarro has quit IRC22:05
morganfainbergjamielennox, ping22:05
morganfainbergjamielennox, re: ksc release22:05
jamielennoxkeystone v4 api will fix all tihs22:06
morganfainbergjamielennox, is it ok to plan for KSC release post m2 cut?22:06
morganfainbergjamielennox, so we don't accidently kill the gate22:06
jamielennoxmorganfainberg: when's m222:06
morganfainbergnot that i expect it22:06
morganfainberguh this week22:06
morganfainbergthursday22:06
morganfainbergofficially22:06
jamielennoxmorganfainberg: ok - there are still a number of things unreviewe22:07
jamielennoxd22:07
morganfainbergjamielennox, exactly22:07
morganfainbergjamielennox, we can get those landed and release ... as soon as m2 is done22:07
jamielennoxsure, aim for monday next week22:08
morganfainbergjamielennox, sold.22:08
jamielennoxi'd be really interested in people reviewing https://review.openstack.org/#/c/140894/22:09
jamielennoxit's kind of hard because it's usurping an existing interface that is quite heavily used22:09
jamielennoxs/hard/tricky22:09
*** Ephur has quit IRC22:13
jamielennoxbknudson: have you looked at upstreaming those hacking checks for oslo.*22:14
bknudsonjamielennox: upstream to where?22:15
jamielennoxbknudson: not sure - oslo.test?22:15
jamielennoxmaybe hacking itself?22:15
jamielennoxi wasn't sure myself - was just thinking they would be generally useful22:16
jamielennoxmaybe oslo_utils22:16
bknudsonjamielennox: there's multiple versions of the hacking check, but at the same time I'm not sure how long it's even going to last... eventually won't have to worry about it since the old names go away22:19
bknudsonI'll ask in -oslo.22:19
jamielennoxbknudson: that's fair, eventually i guess the warnings will get stronger from the oslo.X packages and it won't mater22:19
jamielennoxbknudson, morganfainberg: do we approve in general of the approach in: https://review.openstack.org/#/c/131036/22:21
jamielennoxi'm kind of torn22:21
bknudsonjamielennox: it's scary.22:21
bknudsonjamielennox: actually, now I'm thinking it's not too bad... why not?22:22
jamielennoxbknudson: i see why it might want to be allowed - at the same time if you're using PKI tokens i'd want to know if i was getting these errors22:22
bknudsonas long as the error message is good... which it probably isn't since that's the general way things work.22:23
*** david8hu has quit IRC22:23
*** david8hu has joined #openstack-keystone22:24
bknudsonjamielennox: there's a warning message logged.22:24
morganfainberggenerally speaking22:25
morganfainbergas long as the provider can do online validation like that22:25
morganfainbergi like the fallback22:25
jamielennoxok22:27
jamielennoxi really can't see any good reason to disallow, it just feels a little weird22:27
*** wanghong has quit IRC22:38
*** wanghong has joined #openstack-keystone22:39
*** wanghong has quit IRC22:39
*** wanghong has joined #openstack-keystone22:40
ayoungbknudson, didn't mean to catch you by surprise on the ssl setup thing22:41
bknudsonayoung: it was surprising... I guess since the change had been proposed a long time ago...22:41
ayoungbknudson, so I want to kill the pki/ssl setup thing altogether22:42
ayoungI should never have written it,  I was pressured to make it happen for PKI tokens22:42
ayoungbut..its not the right way to manage certs.  So, while your change is the right solution if we keep it, I just don't want to have to keep it22:42
ayoungand your change kindof locks us in to supporting it it...if you think about it22:43
bknudsonayoung: yes, I agree it would be better if that tool didn't exist. (The tool even says that when used)22:43
ayoungbknudson, so...  https://review.openstack.org/#/c/134099/  instead22:43
bknudsonayoung: our products use it.22:43
ayoungthey really shouldn't22:44
ayoungbknudson, don't you guys have a real X509 solution you should be using instead?22:44
*** thedodd has quit IRC22:45
bknudsonayoung: if there is one I don't know about it.22:45
bknudsonayoung: I think the alternative would be that we just run the openssl commands that keystone-manage would have.22:46
ayoungbknudson, so is the certmonger approach OK with you?  I think it does everything you need.  It has a self signed approach, you would just do the configuration you want on cermonger itslef (I think) not in keystone22:46
bknudsonayoung: I don't see how having keystone-manage call certmonger is better? Why not just call certmonger directly?22:46
ayoungbknudson, agreed...I'd just keep it to avoid breaking all the automation out there.. but deprecate it22:47
bknudsonmaking us switch to certmonger breaks all our automation.22:47
ayoungIt shouldn't22:47
ayoungcertmonger is there in the base OS22:47
bknudsondoes it work on POWER?22:48
ayoungbknudson, if you need the option for the short term, I think it is OK to go forward22:48
ayoungjust with the understanding that it is short lived, and not to be honored once we move off of the openssl code22:48
openstackgerritIan Cordasco proposed openstack/oslo.policy: Drop usage of namespaced packages  https://review.openstack.org/15183622:48
bknudsonayoung: I'm fine with that.22:48
*** dims has quit IRC22:49
openstackgerritMerged openstack/python-keystoneclient: Enable hacking rule E122 and H304  https://review.openstack.org/13410122:50
ayoungbknudson, I don't know.  Does  RHEL run on power?  I'm  pretty sure that it does, but we don't have the resources to check22:50
bknudsonayoung: if certmonger is on rhel and ubuntu that should be good enough for us.22:51
ayoungit is22:51
bknudsonayoung: I can't think of a good objection to certmonger... seems like it's better to just drop keystone-manage support than change it and then get rid of it later.22:54
*** nellysmitt has joined #openstack-keystone22:55
ayoungbknudson, look in to iot, and tell me it if suits your needs.  I won't block your feature if you really need it to move ahead.22:55
ayoungAn bknudson I would never shit you.  You would be a spectacularly painful bowel movement.22:56
bknudsonayoung: we don't need it just like we don't need keystone-manage pki_setup since we can call openssl commands directly... it's a nice-to-have.22:57
ayoungOK.22:57
*** alex_xu_ has quit IRC22:58
*** timcline_ has quit IRC22:59
*** nellysmitt has quit IRC23:00
*** topol has quit IRC23:00
*** alex_xu has joined #openstack-keystone23:01
*** raildo has joined #openstack-keystone23:01
*** Ephur has joined #openstack-keystone23:07
*** joesavak has joined #openstack-keystone23:07
*** raildo has quit IRC23:09
*** jsavak has quit IRC23:10
openstackgerritSteve Martinelli proposed openstack/keystone: Service Providers API for OS-FEDERATION  https://review.openstack.org/10462323:11
*** chlong has joined #openstack-keystone23:11
openstackgerritSteve Martinelli proposed openstack/keystone: Create K2K SAML assertion from Service Provider  https://review.openstack.org/15204623:12
openstackgerritSteve Martinelli proposed openstack/keystone: Drop URL field from region table  https://review.openstack.org/15012223:13
openstackgerritSteve Martinelli proposed openstack/keystone: Update federation config to use Service Providers  https://review.openstack.org/15226023:14
*** andreaf has joined #openstack-keystone23:19
*** raildo has joined #openstack-keystone23:19
*** gordc has quit IRC23:25
*** henrynash has joined #openstack-keystone23:27
*** ChanServ sets mode: +v henrynash23:27
*** joesavak has quit IRC23:29
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for most resources  https://review.openstack.org/15113723:35
*** henrynash has quit IRC23:36
*** samueldmq has joined #openstack-keystone23:41
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notifications for most resources  https://review.openstack.org/15113723:43
openstackgerritSteve Martinelli proposed openstack/keystone: Publicize region/endpoint/policy/service events  https://review.openstack.org/15177423:45
stevemarsorry for the upcoming spam, doing a rebase23:45
stevemarif some of this stuff merges then we won't get bombarded with messages :D23:46
morganfainberg!ban stevemar, flooding23:46
openstackmorganfainberg: Error: "ban" is not a valid command.23:46
morganfainberg>.>23:46
stevemarmorganfainberg, oh you23:46
*** jaosorior has quit IRC23:46
*** zzzeek has quit IRC23:51
openstackgerritSteve Martinelli proposed openstack/keystone: Add CADF notification handling for policy/region/service/endpoint  https://review.openstack.org/15178623:51
*** andreaf has quit IRC23:52
openstackgerritSteve Martinelli proposed openstack/keystone: Add a test for create_domain in notifications  https://review.openstack.org/15179123:52
openstackgerritSteve Martinelli proposed openstack/keystone: Revamp the documentation surrounding notifications  https://review.openstack.org/12618023:52
openstackgerritSteve Martinelli proposed openstack/keystone: Add context to manager classes that send notifications  https://review.openstack.org/15186623:52
raildoand he keeps flooding :P hahaha23:54
stevemarD:23:54
stevemarthats the last one23:54
stevemarraildo, the faster you review them, the sooner they won't show up here :)23:55
raildostevemar: so, I'll review now :D23:55

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