Thursday, 2014-09-11

jamielennoxekarlso-: heh, top of queue has been in line for 26 hours - borked might be an apt description00:01
nkinderjamielennox: sorry for stepping on your repo creation review00:08
jamielennoxnkinder: no worries, i fixed it a different way00:08
nkinderjamielennox: I figured I'd try to help move it along while you slept :)00:08
jamielennoxnkinder: it takes way to long to get infra to pass some of these reviews to have to turn around and issue another one after the first two patches have landed00:08
jamielennoxso i just seeded a base repo onto github they can pull from00:09
*** gokrokve has quit IRC00:11
dstanekgate queue keeps growing00:12
nkinderjamielennox: yeah, makes sense00:13
*** RockKuo_Office has joined #openstack-keystone00:13
morganfainberggate...gate...gate...gate...gate...gate.. <continues chanting>00:13
*** gyee has quit IRC00:18
*** harlowja_ has quit IRC00:25
openstackgerritOpenStack Proposal Bot proposed a change to openstack/identity-api: Updated from global requirements  https://review.openstack.org/12063500:25
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone-specs: Updated from global requirements  https://review.openstack.org/12063800:25
*** harlowja has joined #openstack-keystone00:28
openstackgerritA change was merged to openstack/python-keystoneclient: Allow passing None for username in v2.Password  https://review.openstack.org/11675700:28
openstackgerritA change was merged to openstack/keystonemiddleware: Always supply a username to auth_token tests setup  https://review.openstack.org/11676000:28
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/11625500:31
openstackgerritA change was merged to openstack/keystone: JSON Home data is required  https://review.openstack.org/11766300:31
*** cjellick has quit IRC00:31
*** tim_r has joined #openstack-keystone00:41
*** tim__r has quit IRC00:43
*** saipandi has quit IRC00:45
*** marcoemorais has quit IRC00:51
*** wanghong has joined #openstack-keystone00:59
*** jorge_munoz has joined #openstack-keystone01:03
stevemarmorganfainberg, wait a sec, don't other stuff have lxml as a dependency? did you introduce it?01:06
stevemari don't recall going to requirements project for that01:06
stevemarafk-ish01:06
*** gokrokve has joined #openstack-keystone01:09
ayoungjamielennox, how are we on the new repo?01:16
jamielennoxayoung: no movement, got a push back overnight and i've got a new patch up01:16
jamielennoxthere is pretty good support for this from infra so if you want to bug them about it be my guest01:16
jamielennoxi need to do another repo for -federation01:17
ayoungjamielennox, of course01:17
ayoungwalk me through what you did, I've never done this01:17
ayoungOK,  this is self explanatory  https://review.openstack.org/#/c/120261/8/modules/gerritbot/files/gerritbot_channel_config.yaml,cm01:18
jamielennoxsure, my knowledge of infra is kind of sketchy but i've done it a few times now01:18
jamielennoxhttps://review.openstack.org/#/c/120261/8/modules/openstack_project/files/jenkins_job_builder/config/projects.yaml seems to be like a template for defining jobs that can be run for a project01:19
ayounghttps://review.openstack.org/#/c/120261/8/modules/openstack_project/files/jenkins_job_builder/config/projects.yaml,cm  says "we have a job run on bare-precise and etc"01:19
jamielennoxyou define there your project and some names and it creates a whole bunch of possible jobs01:19
ayoungI01:19
ayoung'm assuming those are image names01:19
ayoungor a set of machines that match some profile01:19
jamielennoxthen https://review.openstack.org/#/c/120261/8/modules/openstack_project/files/zuul/layout.yaml is telling zuul which of those jobs you want to run and when01:20
ayoungpy-pi jobs?01:20
jamielennoxautomatic upload to pypi01:20
ayoungwhen does that happen?01:20
jamielennoxyou can git push a signed tag, zuul will package it and push it to pypi01:21
jamielennoxwhich is awesome01:21
jamielennoxayoung: i always end up re-following the instructions here: http://ci.openstack.org/stackforge.html01:23
ayoungah...that makes it clearer01:23
jamielennoxit's never quite that straight forward but after that you can copy from other projects or find -infra people01:24
ayoungcool.  thanks for going through the pain of it01:24
ayoungjamielennox, at some point, we should figure out a comparable struacture for Javascript code to what we are doing in Python.01:27
ayoungjamielennox, I suspect there are some lessons  we don;t want to relearn the hard way01:28
jamielennoxayoung: yea, i was wondering what of this would be useful elsewhere01:28
ayoungand the next version of Horizon is going to need it01:28
jamielennoxi know enough ruby to think at least the structure is ok01:28
jamielennoxbut i really can't say with javascript01:28
ayoungI think the structure is going to be the same, but the need for requests probably goes away:  the browser kindof dictates how you talk to services01:29
jamielennoxso the basic structure was at least heavily inspired from requests though01:29
jamielennoxsession with auth plugin01:30
ayoungsince Oslo looks like it is going to be grabbing the CORS middleware,  it might end up as an oslo thing01:30
jamielennoxpass the session around01:30
ayoungIn Angular there is a config for the AJAX requests, and  you can, if you want, even set global things...prototype inheritance is weird01:30
jamielennoxeverytime i dip a toe into javascript i run away01:31
*** dims_ has joined #openstack-keystone01:32
jamielennoxi like the theory, the language hurts me01:32
ayoungits unavoidable for web stuff, but I really don't mind the language01:32
ayoungits like plastic lawn furniture01:33
ayounggood for leaving out in the rain..not that nice to sit on, but better than sitting on the ground....01:33
ayoungeasy to break01:33
ayoungjamielennox, but, for example  https://github.com/admiyo/keystone-cops/blob/works/keystone.js#L24101:34
ayoungthat is pretty simple:  the config holds the headers01:34
ayoungresponse_promise.  has success and failure functions.   still seems strange to me that you set them after you make the AJAX call,01:35
ayoungAngular seems pretty simple to work with01:36
jamielennoxis $http global?01:36
ayoungyeah01:36
ayoungpart of Angular01:36
jamielennoxoh, i see it, it's still passed to the funtion01:36
*** oomichi has joined #openstack-keystone01:37
ayoungit is the $scope I have not quite figured out, as that seems to be a global functor  or something01:37
jamielennoxis there a openstack js project?01:37
ayoungyeah, but I don't know if it is used01:37
ayoungjstack01:37
jamielennoxhttps://ging.github.io/jstack/01:38
jamielennoxhttps://github.com/gabrielhurley/js-openclient01:38
ayoungthing is, it not worth it to fight the toolkit, and it looks like Horizon is going with Angular01:39
ayounghis looks like it is node.js oriented, which is server side01:39
jamielennoxyea, just wondering if this was something you could offload01:39
ayoungOh, yeah01:40
ayoungI am just thinking we provide guidance01:40
ayoungI'm really just using my POC to test Keystone.  Its nice on a live server01:40
ayoungI used it today to debug the LDAP trusts problem we were seeing01:41
openstackgerritA change was merged to openstack/keystonemiddleware: Always add auth URI to unauthorized requests  https://review.openstack.org/11926101:41
jamielennoxok, well i think the plugins work well, but i don't know how you would serialize them in javascript01:41
ayounghey that is one of yours01:41
ayounglet me show you the start...01:41
jamielennoxayoung: they're slowly going through01:41
ayounghttps://github.com/admiyo/keystone-cops/blob/works/keystone.js#L7301:41
ayoungso I'm doing it with a switch statement there, but you can see the code inside the case statements could grow into a full object01:42
ayoungfor instance, if you are doing a project scoped token you use this code https://github.com/admiyo/keystone-cops/blob/works/keystone.js#L2701:43
jamielennoxayoung: so how do you know what you are getting?01:43
ayoungin that case:   it is set by the UI01:43
ayounghere...01:43
ayounghttps://keystone.younglogic.net/keystone/cops/01:43
ayoungsee the radio buttons?01:43
jamielennoxye01:44
ayoungthose are linked to the $scope.auth_method variable01:44
ayoungonclick sets the variable01:44
jamielennoxsurely in a real plugin though you would want to change the boxes etc based on the plugin type01:44
ayoungthe HTML is Angular specific, but very simple:01:44
ayounghttps://github.com/admiyo/keystone-cops/blob/works/index.html#L3001:45
ayoungyes,  and typically you do that by having div tags that you make visible or hidden01:45
ayoungI need to do something comparable in D-O-A, but in server side python01:46
*** jorge_munoz has quit IRC01:46
ayoungI had some problems with the UI toolkit for Angular.  I got alerts working, then tried to get tabs working, and the alerts broke01:47
ayoungideally I'd use tabs and be able to use my POC for a handful of tasks.01:47
ayoungI want to be able to create a trusts. add a role to a user, etc01:47
*** jorge_munoz has joined #openstack-keystone01:48
*** jorge_munoz has quit IRC01:48
ayoungI had the "add arole to a user" working ,but using JQuery.  As I said, its not worth bucking the toolkit.  Rewrite is simple, but not automatic01:48
openstackgerritRodrigo Duarte proposed a change to openstack/python-keystoneclient: Implementing hierarchical calls on keystoneclient v3 (python only)  https://review.openstack.org/11577001:50
*** jorge_munoz has joined #openstack-keystone01:53
*** jorge_munoz has quit IRC01:54
jamielennoxmorganfainberg: i created the -federation repo review as well: https://review.openstack.org/12067001:56
jamielennoxif we have to copy the history from the current client to the new repo do we need to do that in github rather than via gerrit?01:57
jamielennoxayoung: i can at least look at the D-O-A side01:57
*** jorge_munoz has joined #openstack-keystone01:58
*** rodrigods_ has joined #openstack-keystone01:59
rodrigods_just reported a bug: https://bugs.launchpad.net/python-keystoneclient/+bug/1367997 . Seems like there are some missing tests for projects and domains at keystoneclient v301:59
uvirtbotLaunchpad bug 1367997 in python-keystoneclient "Missing some v3 tests for projects and domains" [Undecided,New]01:59
jamielennoxso how does horizon handle auth between domains in v3?02:03
jamielennoxrodrigods_: there are some basic tests that are done because they inherit utils.CrudTests02:06
jamielennoxmostly those files contain 'extra' tests that are specific to just that resource02:06
openstackgerritwanghong proposed a change to openstack/keystonemiddleware: correct docstring  https://review.openstack.org/12033302:13
*** rodrigods_ has quit IRC02:14
*** wanghong has quit IRC02:15
*** diegows has quit IRC02:17
*** wanghong has joined #openstack-keystone02:19
*** hrybacki has joined #openstack-keystone02:20
*** amcrn has quit IRC02:22
*** gokrokve has quit IRC02:25
*** yasukun has joined #openstack-keystone02:29
*** dims_ has quit IRC02:49
*** dims_ has joined #openstack-keystone02:49
*** rushiagr_away is now known as rushiagr02:53
*** dims_ has quit IRC02:54
*** rodrigods_ has joined #openstack-keystone03:00
rodrigods_jamielennox, ah, ok... thanks03:00
*** rodrigods_ has quit IRC03:00
*** KanagarajM has joined #openstack-keystone03:03
*** hrybacki has quit IRC03:08
*** hrybacki has joined #openstack-keystone03:10
*** hrybacki has quit IRC03:13
*** hrybacki has joined #openstack-keystone03:14
*** rushiagr is now known as rushiagr_away03:14
stevemarjamielennox, i'm confused about the separate repo's how would we pull in changes?03:15
jamielennoxstevemar: why would it be different/03:15
stevemarjamielennox, err, i mean changes to ksc03:16
jamielennoxhow would we deprecate the existing federation plugin you mean?03:16
stevemarjamielennox, more like... if i want to use a client for federation, i would download that one right - is it going to depend on python-keystoneclient ? or have it's own basemanager/crud manager framework?03:17
stevemari'm not seeing how the dots connect in a way that this isn't a maintenance nightmare03:18
jamielennoxstevemar: i wasn't expecting the managers to move03:19
jamielennoxfor example there's no reason you couldn't access OS-FEDERATION routes with a regular token03:19
jamielennoxit's mostly auth negotiation03:20
jamielennoxat least for now i think it's only the auth plugins we want to move03:20
stevemarjamielennox, hmm OK03:21
stevemarare you looking at this from a 'lets not overload ksc' point of view, or from the infra p.o.v. because lxml was used?03:22
jamielennoxstevemar: so kerberos was the initial goal03:24
jamielennoxthere's no py33 support and other issues that kerberos can't be in keystoneclient direct03:24
jamielennoxfederation is an extension of the same point03:24
jamielennoxlxml is the main reason for now03:25
stevemarjamielennox, to that, won't it be the same issue when we eventually get tempest/gate tests up?03:31
jamielennoxstevemar: probably03:32
jamielennoxit's just that keystoneclient is a dependency of a lot of thing s03:32
jamielennoxall the clients for one03:32
jamielennoxand having lxml means it doesn't work with pip for some stuff03:32
jamielennoxso long as it's not in the main repo i think it's ok because it'll be the end application that takes the dependency03:33
*** jorge_munoz has quit IRC03:33
*** alex_xu has joined #openstack-keystone03:36
stevemarjamielennox, ah OK, *that* makes more sense03:37
stevemarjamielennox, hopefully we can remove that dependency (and the pysaml2 one in keystone) later on03:37
*** rodrigods_ has joined #openstack-keystone03:37
stevemarsince we are generally creating pretty static XML content03:37
jamielennoxstevemar: is it creation, i thought it was an issue in reading03:38
stevemarbit of both03:38
jamielennoxstevemar: is there a way we can do that now?03:39
jamielennoxthe lxml bit at least03:39
jamielennoxif so there's no rush on the -federation repo03:39
jamielennoxit was in addition because it was pretty much the exact same review as -kerberos03:40
jamielennox(though as mentioned the infra guys are keen for lxml removal)03:40
*** jorge_munoz has joined #openstack-keystone03:40
stevemarjamielennox, there's definitely a way, but i don't have the time to look it up and get it done before the 18th03:42
jamielennoxmorganfainberg was looking into it as well03:42
stevemarwell, it's used in whopping 4 places03:43
*** RockKuo_Office has quit IRC03:43
jamielennoxyea, but it's doing xpath stuff that the python xml can't handle03:43
stevemarpython xml == elementTree i think?03:44
jamielennoxnot sure03:44
*** rodrigods_ has quit IRC03:45
stevemarseems that way03:46
*** RockKuo_Office has joined #openstack-keystone03:46
*** rushiagr_away is now known as rushiagr03:46
jamielennoxstevemar: it will have to happen in client one way or another, just depends whether it's worth splitting out the repo once it's done03:49
*** jorge_munoz has quit IRC03:52
jamielennoxstevemar: can i grab an opinion while you're here03:55
stevemarsure03:55
jamielennoxhttps://review.openstack.org/#/c/118004/3/keystoneclient/session.py03:55
jamielennoxso i need to handle both redirections and retries in the same code03:55
jamielennoxand i think that it's just getting too messy03:56
stevemarah is this for the stuff that was on the ML03:56
jamielennoxlike there is an edge case where if a request succeeds on the third retry, then goes for a redirect, then needs to retry again then the intial wait count is already 4 seconds and will start doubling03:57
jamielennoxso i have to carry another original_ variable through the recursion03:57
jamielennoxstevemar: it's not specifically, i've had this one up for a while03:57
jamielennoxit's a major 'feature' of other clients that i can't replicate yet. If they are going to cut new clients and update all requirements files then it would be good to have it in03:58
jamielennoxanyway, recursion is getting messy - i don't know if i can do it flat any better03:59
jamielennoxcan you see a structure that makes sense/03:59
stevemarjamielennox, it's not too bad as-is tbh04:00
stevemari see what you mean though, it is getting a bit long and overloaded04:00
stevemarfor just a basic _send_request04:01
jamielennoxright, the redirects isn't too hard and the retries isn't too hard04:02
jamielennoxmaybe it's enough just to break those two parts apart04:02
*** harlowja is now known as harlowja_away04:05
stevemarjamielennox, separate handlers for retry and redirects?04:05
*** ayoung has quit IRC04:05
stevemarjamielennox, bknudson is great at this sort of stuff04:05
*** henrynash has joined #openstack-keystone04:05
stevemarhelps when your native tongue is a programming language04:06
jamielennoxstevemar: i was thinking like an inner and an outer loop - but it still becomes recursive if you are allowed to retry accessing the value from the redirect04:06
stevemarjamielennox, damn, its namespace crap, the python stdlib xml parser craps out if it's <something:tag>04:08
stevemarinstead of just <tag>04:08
stevemarwhich is kind of silly04:08
stevemarugh, and xpath stuff04:12
stevemaryeah we're not losing this dependency any time soon04:12
stevemarunless we switch to some sort of template, which would be awful04:13
stevemarjamielennox, if you could review this one: https://review.openstack.org/#/c/119834/ that would be awesomeo04:14
stevemaris it possible to run 2 keystone instances on the same machine?04:31
*** hrybacki has quit IRC04:32
*** gokrokve has joined #openstack-keystone04:37
*** HenryG is now known as HenryG_zzzz04:40
*** ukalifon has joined #openstack-keystone04:40
jamielennoxstevemar: can't see why not04:41
openstackgerritA change was merged to openstack/python-keystoneclient: Version independent plugins  https://review.openstack.org/8114704:47
*** wanghong has quit IRC04:48
stevemarjamielennox, apparently getopt supports --options, but it's installed at the system level04:48
stevemargetopts is available, but only does single character flags :(04:49
stevemar-t test_dir ?04:49
jamielennoxstevemar: i looked at it for a few minutes and saw that - at which point i got frustrated and gave up04:49
jamielennoxbut yea, i think -t is fine04:49
jamielennoxbetter to be optional like that04:49
jamielennoxstevemar: in my v2 of that patch i had retries count be absolute04:51
jamielennoxso even if it went via redirects it only did so many retries04:51
jamielennoxdo you think that's better - otherwise you can get redirects * retries attempts04:52
stevemarjamielennox, i think this should work: https://review.openstack.org/#/c/120316/404:59
stevemari'll owe you a review tomorrow, and marek too05:00
stevemarugh no one has reviewed his adfs stuff https://review.openstack.org/#/c/111771/05:00
*** stevemar has quit IRC05:05
*** RockKuo_Office has quit IRC05:05
*** yasukun has quit IRC05:08
*** yasukun has joined #openstack-keystone05:10
*** yasukun has quit IRC05:10
*** yasukun has joined #openstack-keystone05:11
*** RockKuo_Office has joined #openstack-keystone05:22
*** ajayaa has joined #openstack-keystone05:32
*** bvandenh has joined #openstack-keystone05:41
*** amcrn has joined #openstack-keystone05:44
*** jaosorior has joined #openstack-keystone05:46
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Make keystoneclient use an adapter  https://review.openstack.org/9768105:51
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Make tests run against original client and session  https://review.openstack.org/11708905:51
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Allow retrying some failed requests  https://review.openstack.org/11800405:51
*** RockKuo_Office has quit IRC05:57
*** hrybacki has joined #openstack-keystone06:00
*** oomichi_ has joined #openstack-keystone06:03
*** oomichi has quit IRC06:05
*** hrybacki has quit IRC06:07
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/12069506:08
*** andreaf has joined #openstack-keystone06:13
*** RockKuo_Office has joined #openstack-keystone06:13
*** gokrokve has quit IRC06:28
*** gokrokve has joined #openstack-keystone06:28
openstackgerritKevin Benton proposed a change to openstack/keystone: Fail on empty userId/username before query  https://review.openstack.org/12070506:31
*** gokrokve has quit IRC06:33
*** gokrokve has joined #openstack-keystone06:34
*** k4n0 has joined #openstack-keystone06:34
*** afazekas is now known as __afazekas06:34
openstackgerritA change was merged to openstack/python-keystoneclient: fix typos  https://review.openstack.org/11984106:35
*** gokrokve has quit IRC06:38
jaosoriordolphm: are you around_06:46
jaosorior?06:46
*** gokrokve has joined #openstack-keystone07:04
*** gokrokve has quit IRC07:05
*** gokrokve has joined #openstack-keystone07:06
openstackgerritA change was merged to openstack/identity-api: Updated from global requirements  https://review.openstack.org/12063507:06
*** amerine has quit IRC07:08
*** gokrokve has quit IRC07:10
*** ukalifon has quit IRC07:23
*** amcrn has quit IRC07:23
*** yasukun has quit IRC07:32
*** yasukun has joined #openstack-keystone07:32
*** gokrokve has joined #openstack-keystone07:34
*** gokrokve has quit IRC07:39
*** oomichi_ has quit IRC07:45
*** garnav has joined #openstack-keystone07:49
*** ukalifon1 has joined #openstack-keystone08:00
*** afazekas_ has joined #openstack-keystone08:05
*** amerine has joined #openstack-keystone08:30
*** BAKfr has joined #openstack-keystone08:31
*** gokrokve has joined #openstack-keystone08:37
*** gokrokve has quit IRC08:41
*** wanghong has joined #openstack-keystone08:46
*** sunrenjie6 has joined #openstack-keystone08:46
*** andreaf has quit IRC08:47
*** oomichi has joined #openstack-keystone08:52
*** oomichi has quit IRC09:10
*** aix has joined #openstack-keystone09:26
*** Xeye is now known as amakarov09:31
ajayaavivekd, https://www.getpostman.com/collections/d929e56a725c54996e0109:33
*** gokrokve has joined #openstack-keystone09:34
*** sunrenjie6 has quit IRC09:35
*** gokrokve has quit IRC09:39
*** dims_ has joined #openstack-keystone09:51
*** dims_ has quit IRC10:00
*** ukalifon1 has quit IRC10:01
*** dims_ has joined #openstack-keystone10:01
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Add a simple module to work with filters and DNs to LDAP backend  https://review.openstack.org/11748410:06
*** dims_ has quit IRC10:06
*** d0ugal has quit IRC10:08
*** d0ugal has joined #openstack-keystone10:08
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Correct typos in keystone/common/base64utils.py docstrings  https://review.openstack.org/11977510:14
*** gokrokve has joined #openstack-keystone10:34
*** gokrokve has quit IRC10:39
*** yasukun has quit IRC10:58
*** rodrigods_ has joined #openstack-keystone11:07
*** dims_ has joined #openstack-keystone11:17
*** f13o has joined #openstack-keystone11:19
openstackgerritYuriy Taraday proposed a change to openstack/keystone: Add a pool of memcached clients  https://review.openstack.org/11945211:19
openstackgerritPeter Razumovsky proposed a change to openstack/keystone: Add a simple module to work with filters and DNs to LDAP backend  https://review.openstack.org/11748411:20
*** rodrigods_ has quit IRC11:21
bjornarWhen running keystone under wsgi (master) I am experiencing something odd: /v2.0/tenants return fine, but /v2.0/users return 40411:27
bjornarDebug is on, but nothing in my logs that can explain this11:27
bjornarforget it.11:30
bjornarWas running both was running as "main"11:30
*** dims_ has quit IRC11:30
*** dims_ has joined #openstack-keystone11:31
*** gokrokve has joined #openstack-keystone11:34
*** diegows has joined #openstack-keystone11:34
*** dims__ has joined #openstack-keystone11:34
*** dims_ has quit IRC11:35
*** gokrokve has quit IRC11:39
*** RockKuo_Office has quit IRC11:52
*** andreaf has joined #openstack-keystone11:54
*** hrybacki has joined #openstack-keystone12:04
*** alex_xu has quit IRC12:08
*** hrybacki has quit IRC12:10
*** KanagarajM has quit IRC12:17
*** gokrokve has joined #openstack-keystone12:34
*** gokrokve has quit IRC12:39
*** gordc has joined #openstack-keystone12:42
*** radez_g0n3 is now known as radez12:47
*** dims__ has quit IRC12:49
*** dims_ has joined #openstack-keystone12:50
*** dims_ is now known as dims12:51
*** HenryG_zzzz is now known as HenryG12:55
*** miqui has joined #openstack-keystone12:55
dolphmanyone looking into testQuotedWWWAuthenticateHeader swift-dsvm-functional failures?13:05
*** vhoward has joined #openstack-keystone13:09
*** joesavak has joined #openstack-keystone13:11
*** nkinder has quit IRC13:12
*** Ugallu has joined #openstack-keystone13:13
*** ayoung has joined #openstack-keystone13:14
*** hrybacki has joined #openstack-keystone13:18
*** sigmavirus24_awa is now known as sigmavirus2413:19
*** amerine_ has joined #openstack-keystone13:20
*** amerine_ has quit IRC13:21
*** richm1 has joined #openstack-keystone13:21
*** amerine_ has joined #openstack-keystone13:21
*** amerine has quit IRC13:22
*** amerine has joined #openstack-keystone13:26
*** amerine_ has quit IRC13:28
*** gokrokve has joined #openstack-keystone13:34
* dolphm keystone, swift & openstack/requirements gates are entirely broken due to bug 136804813:37
uvirtbotLaunchpad bug 1368048 in swift "testQuotedWWWAuthenticateHeader date time encoding error" [Undecided,In progress] https://launchpad.net/bugs/136804813:37
dolphmjamielennox ^ caused by a change to keystonemiddleware13:38
*** gokrokve has quit IRC13:39
*** bknudson has joined #openstack-keystone13:46
*** jorge_munoz has joined #openstack-keystone14:07
dstanekdolphm: ooh, that's not cool. we are sending two www-authenticate headers now?14:12
dolphmdstanek: yes14:12
dolphmdstanek: there's a change at the front of the gate to land a fix in swift's tests - to handle two headers14:12
dolphmthe change in keystone middleware was https://review.openstack.org/#/c/119261/14:13
dstanekyeah, i'm looking at it now14:13
dstanekthat's interesting that we extend the headers in _call_app instead of replace14:15
*** hrybacki has quit IRC14:16
*** nkinder has joined #openstack-keystone14:16
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/python-keystoneclient: Inherited role domain calls on keystoneclient v3  https://review.openstack.org/11608114:24
*** hrybacki has joined #openstack-keystone14:26
*** stevemar has joined #openstack-keystone14:28
ayoungdolphm, jamielennox probably asleep, but I can look14:28
*** vhoward has left #openstack-keystone14:29
dolphmayoung: dstanek: the fix/workaround in swift is about to land (just a couple minutes). i think we just need to take another look at that keystonemiddleware change, and decide if we should reconsider the implementation14:30
ayoungdstanek, its a case of "No good deed goes unpunished"14:30
ayounghe was attempting to do the "more correct" thing, but the tests are too rigid14:31
ayoungdolphm, is it only Swift that needs the fix?14:31
dolphmayoung: *needs* yes14:32
ayoungdolphm, OK, So if the other services are not broken by it, I'd suggest leaving it14:32
*** david-lyle has joined #openstack-keystone14:32
ayoungotherwise, we risk one of them writing a comparable test to swifts in the future14:32
*** alex_xu has joined #openstack-keystone14:34
*** gokrokve has joined #openstack-keystone14:34
*** hrybacki has quit IRC14:36
*** topol has joined #openstack-keystone14:38
*** david-lyle has quit IRC14:38
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add characterization test for cleanup role assignments for group  https://review.openstack.org/11963014:39
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix delete group cleans up role assignments with LDAP  https://review.openstack.org/11963114:39
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix using local ID to clean up user/group assignments  https://review.openstack.org/11962914:39
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix LDAP group role assignment listing  https://review.openstack.org/11948014:39
*** gokrokve has quit IRC14:39
*** gokrokve has joined #openstack-keystone14:41
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add characterization test for cleanup role assignments for group  https://review.openstack.org/11963014:46
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix delete group cleans up role assignments with LDAP  https://review.openstack.org/11963114:46
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix using local ID to clean up user/group assignments  https://review.openstack.org/11962914:46
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix LDAP group role assignment listing  https://review.openstack.org/11948014:46
garnavhi all, quick question. If my model has one column as a JsonBlob should I inherit ModelDictMixin instead of DictBase?14:56
garnavThanks in advance for any help14:56
dolphmbknudson: conflicted with your own skip test patch?14:56
bknudsondolphm: yes.14:56
dstanekdolphm, ayoung: i would think that having multiple www-authenticate isn't allow and we can quickly change the impl to replace the existing one14:57
bknudsonI should add tests in a random location rather than at the end.14:57
*** ajayaa has quit IRC14:57
dolphmbknudson: haha14:58
*** jsavak has joined #openstack-keystone14:58
dolphmgarnav: that sounds correct - one of the base classes packs unrecognized attributes into the 'extra' column if you want to support that14:59
*** joesavak has quit IRC14:59
ayoungdstanek, technically we are all in a state of sin here anyway, as we do not provide the actual mechanism.  THen again Form based authentication is not an actual mechanism. THen again again putting the cleartext username in the body of a JSON is not really a mechanism either15:00
ayoungWhat does SAML or OAuth specify?  That is closest to what we do.15:01
*** k4n0 has quit IRC15:01
*** afazekas_ has quit IRC15:03
ayoungdstanek, If I make a call to swift with and expired or invalid token, we should have in the URL the Keystone server that issued the token.  If the token is missing, Keystone middleware really should make no assumptions about where to redirect the user.  It should be  401 "You need a token, got find one"15:05
ayoungI'd like to start breaking the assumption that there is one and only one Keystone server  for a given Swift deployment.  Sure, that is the only case right now, but it should not be.15:06
dstanekayoung: but those are different issues - i'm just talking about overloading the header15:08
ayoungdstanek, you used the "J" word15:09
ayoungdstanek, I was talking about the URL put in that header15:09
amakarovnkinder, Greetings! Can you please review my patch about fixing broken extra attribute mapping in LDAP models? https://review.openstack.org/#/c/118590/15:09
ayoungSwift origianlly hard coded their own scheme in there, which is, if I understand it, what we broken15:10
ayoungamakarov, too scared to ask me to?15:10
ayoungamakarov, please include me on all LDAP related changes.15:10
ayoungbut you did...so thanks15:11
ayoungamakarov, did you run your changes against a live LDAP server?  If so, which one?15:12
dstanekayoung: we have to determine which header should be returned. maybe if there is already one we don't add ours?15:12
*** cjellick has joined #openstack-keystone15:12
dstaneksounds like keystone and swift devs need to talk through the usecase15:12
amakarovayoung, I use devstack - 1 minute - I'll see :)15:13
ayoungdstanek, well,  Keystone tokens are the authentication mechanism.  The header should be standard15:13
ayoungamakarov, devstack is OpenLDAP15:13
amakarovayoung, well - it's OpenLDAP :)15:14
*** david-lyle has joined #openstack-keystone15:15
dstanekayoung: while i agree there, i think i heard somewhere that they want swift usable outside of openstack - if that's the case, does we need to behave a little differently?15:15
ayoungdstanek, that would be Swift without Keystone. So no problem, I think.15:15
nkinderamakarov: taking a look now.  It's been on my list, but my list gets growing...15:16
dstanekayoung: what does the client do when it gets two headers?15:16
ayoungdstanek, I don't think that is legal.  So, we need to replace15:17
ayoungnkinder, its too big for Juno15:18
nkinderayoung: yes, I already have that impression15:18
ayoungamakarov, I like where you are headed with the patch, but we are past feature freeze.  Once we have RC1 cut, we will open up the Repo for Kilo contributions.15:19
dstanekayoung: so my question is whether or not we should replace if it exists all of the time or if we can detect that the 401 is the result of a delayed authz15:19
ayoungIn order to do that, you change might just be complex enough to require a Spec.15:19
ayoungdstanek, If they are using Keystone as the Auth mechanism, we should own the Auth header15:19
ayoungif there is one there already....500?15:19
ayoungIt really is a misconfiguration15:20
*** zzzeek has joined #openstack-keystone15:20
ayoungdstanek, if there are multiple auth mechanisms supported...I'd have to refresh on what HTTP requires15:20
ayoungamakarov, however, the PTL did tag that one as  juno-rc-potential   so maybe.  Is this primarily for read/write or read/only LDAP?15:25
amakarovayoung, thank you, can you please direct me what is needed in the project now? It was done before patch about read-only LDAP id, and as far as I understand, does not conflict with it.15:27
ayoungamakarov, read only LDAP is not a patch, it is just the general way LDAP is used.  \15:28
ayoungamakarov, are you using LDAP in read/write mode?15:28
amakarovayoung, rw15:28
ayoungamakarov, interesting...what'15:28
ayoungs you use case?15:29
*** BAKfr has quit IRC15:30
nkinderamakarov: let me see if I understand what the patch is trying to achieve...15:31
nkinderamakarov: if the LDAP entry does not have an attribute that is listed in an additional mapping, you will log a warning in keystone, right?15:31
amakarovayoung, initially it was about keystone didn't care about additional attribute mapping15:31
ayoungnkinder, he's trying to be able to write to LDAP where the object classes require more attributes than Keystone will send15:31
nkinderayoung: hold on, just trying to confirm a few things15:32
*** gokrokve_ has joined #openstack-keystone15:32
amakarovayoung, warning if LDAP entry does not contain required field15:33
nkindernkinder: so if you configure a mapping for an allowed (MAY) LDAP attribute, you will likely be encountering warnings.15:33
nkindertalking to myself already... :)15:33
nkinderamakarov: 2 lines up ^^^15:33
ayoungamakarov, yep15:33
amakarovayoung, and a had to fall back to it because code depend on such behaviour15:33
henrynashquick python question: is an @property in a class only evaluated once, at class instantiation time? (I’m guessing so)15:33
nkinderamakarov: so you are assuming that additional mappings are really inteded for required (MUST) attributes15:34
nkinderamakarov: so that's the "read from LDAP" part of the change15:35
amakarovayoung, https://bugs.launchpad.net/keystone/+bug/1336769 this bug describes desired behavior15:35
uvirtbotLaunchpad bug 1336769 in keystone "LDAP additional attribute mappings do not care about model attribute" [Low,In progress]15:35
*** gokrokve has quit IRC15:35
ayoungamakarov, desired by whom?  Heh.  OK, so I think you are trying to make a feature work that never worked, but to the rest of the world, it looks like you are trying to implement a new feature15:36
amakarovAnd yes - for now i treat additional mapping as MUST HAVE15:36
ayoungI think the "additional attributes" code was from the code base that I inherited15:36
ayoungthe parentage is something like this15:36
nkinderamakarov: so the real purpose for the mappings as I see if is for user creation15:36
nkinderif you are adding a user to keystone, you configure additional mappings to satisfy LDAP required attribute15:37
*** gyee has joined #openstack-keystone15:37
amakarovnkinder, yes, I didn't see usage of this feature besides user description feild :)15:37
ayoungNova (pre Keystone) had LDAP support, then someone split out Keystone, and stole the code from Nova.  THen termie rewrote Keystone and didn't put LDAP support in there. Then I used the LDAP code from the old code base for the Keystone rewrite.15:37
nkinderif you don't do this, your LDAP add operations would fail with objectclass violations15:37
ayoungI don't think the additional attributes were ever tested, and so I cannot say that they ever worked15:37
nkinderamakarov: so you are trying to pre-validate the entries on the Keystone side based off of the mappings to return a nice error message15:38
amakarovnkinder, yes15:38
nkinderamakarov: the alternative is that we just send off the entry to LDAP and let it reject it15:38
*** henrynash has quit IRC15:39
nkinderamakarov: isn't the latter what happens now?15:39
amakarovnkinder, actually I didn't check it15:39
nkinderamakarov: ok, so a few things15:40
*** david-lyle has quit IRC15:40
nkinder1 - this is a bug to do more validation on the Keystone side.  I expect that the LDAP operation would fail today though, so all we're really getting is improved error messages.15:41
amakarovnkinder, agreed15:41
nkinder2 - this really only pertains to read-write LDAP, which isn't really the target use-case for Keystone's LDAP backend15:41
nkinderamakarov: That doesn't mean it's not valuable though :)15:42
ayoungamakarov, which is why I asked "why do you want this?:"15:42
ayoungbecause if we are going to push for read/write enahncements, we  need justification15:42
*** jimhoagland has joined #openstack-keystone15:42
nkinderamakarov: LDAP is really thought of as read-only, as the idea is that many people have all of their users/credentials already in an LDAP server and they just want Keystone to use them15:42
nkinderKeystone shouldn't be a user provisioning tool for LDAP15:42
nkinderIt *can* be used for that (sort of), but that's simply because of the way that Keystone evolved.15:43
ayoungnkinder, I disagree.15:43
nkinderMy feeling is that read-write LDAP in Keystone is an evolutionary dead-end15:44
nkinderayoung: how so?15:44
ayoungnkinder, we know of at least two major Keystone deployments that go Read write15:44
ayoungRackspace and CERN both have some read/write in LDAp15:44
nkinderayoung: sure, I know that it is being used15:44
nkinderthat doesn't mean it's ideal15:44
ayoungnkinder, its better than SQL15:44
ayoungthat was what I was talking about before15:45
amakarovnkinder, following bug description there should be some feedback from client about wrong data from server15:45
ayoungLDAP has things like Password rotation and all that, but we need a way to do user capture15:45
amakarovand now all works without a warning15:45
*** jimhoagland has left #openstack-keystone15:45
nkinderamakarov: I think that's because the mapping was really only considered for write operations15:45
nkinderamakarov: keystone really doesn't care if we read back an additional mapped attribute, because it never uses them15:46
*** bvandenh has quit IRC15:46
nkinderamakarov: it's really only intended for having a way to fill in those attributes when a user is created in LDAP via Keystone15:46
amakarovnkinder, what if we expect an additional attribute from LDAP but never get it?15:46
ayoungamakarov, like what?15:46
nkinderamakarov: what do we do with the retrieved attribute?15:46
*** david-lyle has joined #openstack-keystone15:46
nkinderamakarov: I think the answer is we never even look at it15:47
nkinderamakarov: res->model doesn't need to look at additional mappings15:47
amakarovnkinder, well, I agree )15:47
nkinderamakarov: model->res needs to fill them in so LDAP doesn't blow up with an objectclass violation15:47
ayoungamakarov, why do you even care?15:48
amakarovayoung, good question )15:49
ayoungamakarov, http://adam.younglogic.com/2014/09/three-types-of-keystone-users/  is how I am thinking about things.  But the SQL backend  has some limitations, and I want to see the potential for an increased role in REad/Write LDAP.15:50
ayoungSo when I see things like this, I pay attention15:51
*** arunkant_work has joined #openstack-keystone15:51
amakarovayoung, if so we just need all this LDAP backend to read from existing databases and all data bindings are made during deployment?15:52
ayoungamakarov, huh?15:52
amakarovayoung, and we expect data structure to be immutable15:52
ayoungamakarov, that is the Enterprise use case, yes15:53
ayoungand I would say that most universities fall into that category, too15:53
amakarovayoung, I'm trying to catch the purpose of the component )15:53
ayoungamakarov, #1 usage is to read from Corporate LDAP15:53
ayoungand in those cases, LDAP is read only15:53
amakarovayoung, got it15:54
ayoungamakarov, Assignments and Identity used to be housed in a single backend15:54
ayoungand it wasn't until we split them could we stop writing to LDAP15:54
ayoungso you see a lot of vestiges from that time...and of course, some people are still running with those vestiges15:54
amakarovayoung, so r/w mode is deprecated or "to be continued" )15:55
amakarov?15:55
ayoungamakarov, lets say "to be determined"15:55
ayoungamakarov, I think it stands like this:15:56
ayoungfor REad Only use cases, LDAP as it is designed is sufficient (if clunky)15:56
ayoungfor Read/Write use case it needs some more work.15:56
amakarovayoung, thanks for information. So what to do with the patch?15:58
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/python-keystoneclient: Inherited role domain calls on keystoneclient v3  https://review.openstack.org/11608115:59
amakarovayoung, I can replace errors with warnings logging15:59
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/python-keystoneclient: Inherited project role grants on keystoneclient v3  https://review.openstack.org/12082215:59
*** wwriverrat has joined #openstack-keystone16:04
*** jsavak has quit IRC16:05
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/python-keystoneclient: Inherited role domain calls on keystoneclient v3  https://review.openstack.org/11608116:09
openstackgerritSamuel de Medeiros Queiroz proposed a change to openstack/python-keystoneclient: Inherited project role grants on keystoneclient v3  https://review.openstack.org/12082216:09
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Use oslo_debug_helper and remove our own version  https://review.openstack.org/12010416:18
*** marcoemorais has joined #openstack-keystone16:20
*** garnav has quit IRC16:20
*** rushiagr is now known as rushiagr_away16:21
*** diegows has quit IRC16:22
*** rwsu has quit IRC16:24
*** rwsu has joined #openstack-keystone16:29
*** bjornar_ has joined #openstack-keystone16:33
*** rwsu has quit IRC16:33
*** rwsu has joined #openstack-keystone16:35
*** r-daneel has joined #openstack-keystone16:45
*** wanghong has quit IRC16:46
*** rushiagr_away is now known as rushiagr16:46
openstackgerritA change was merged to openstack/keystone: Document mod_wsgi doesn't support chunked encoding  https://review.openstack.org/12027416:50
*** amakarov has quit IRC16:54
*** aix has quit IRC16:55
*** sigmavirus24 is now known as sigmavirus24_awa16:59
*** nkinder_ has joined #openstack-keystone17:03
*** rkofman has quit IRC17:05
*** rkofman has joined #openstack-keystone17:06
*** nkinder has quit IRC17:07
*** alex_xu has quit IRC17:09
*** harlowja_away is now known as harlowja17:09
*** Guest55717 has joined #openstack-keystone17:10
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/11162017:14
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystonemiddleware: Updated from global requirements  https://review.openstack.org/11914217:15
openstackgerritOpenStack Proposal Bot proposed a change to openstack/python-keystoneclient: Updated from global requirements  https://review.openstack.org/11625517:20
stevemardolphm, ping17:22
openstackgerritAlexander Makarov proposed a change to openstack/keystone: LDAP additional attribute mappings validation  https://review.openstack.org/11859017:23
*** amakarov has joined #openstack-keystone17:27
*** amakarov is now known as amakarov_away17:27
*** joesavak has joined #openstack-keystone17:38
morgan_remoteHmm17:40
*** openstackgerrit has quit IRC17:46
*** openstackgerrit has joined #openstack-keystone17:46
stevemargordc, commented17:47
*** portante has quit IRC17:51
*** portante has joined #openstack-keystone17:55
openstackgerritDavid Stanek proposed a change to openstack/keystone-specs: Add log translation hints for keystone  https://review.openstack.org/10595417:59
openstackgerritDavid Stanek proposed a change to openstack/keystone-specs: Add log translation hints for Keystone  https://review.openstack.org/10595418:00
dolphmstevemar: o/18:01
stevemardolphm, you're too late, you're dead to me now18:02
morganfainbergdolphm, no respect man. no respect.18:02
dolphmmorganfainberg: my lunch was worth it.18:02
stevemarmorganfainberg, i wonder what his excuse will be this time? lunch? food?18:02
stevemarah ha!18:02
morganfainbergdolphm, a good lunch is always worth it18:03
stevemardolphm, i was going to say that gordc wanted the role_assignment event name flipped around for consistency18:03
dolphmstevemar: use a different attribute?18:04
stevemardolphm, but if you recall, cadf has a strict naming convention for their 'action' value, it had to begin with 'create'18:04
stevemardolphm, the non-cadf events are emitted like: identity.users.created18:04
dolphmstevemar: yeah18:04
stevemardolphm, but for role_assignments, it's identity.created.role_assignment18:04
stevemargordc, was asking why the flip18:05
stevemarthe answer (i forgot at the time, hence the ping) is cadf's 'action' value has to start with a valid set of words18:05
gordcwhy you calling me out for.18:05
stevemargordc, to throw you right under the bus18:06
gordcfair enough18:06
*** marcoemorais has quit IRC18:06
*** marcoemorais has joined #openstack-keystone18:06
stevemarhaha, it was a valid question/comment on the review, i couldn't remember why initially18:06
dolphmstevemar: so what's the action we're using for assignments?18:06
*** marcoemorais has quit IRC18:06
stevemardolphm, action is "created.role_assignment" and the event_type is "identity.created.role_assignment"18:07
stevemarwe used the convention of prefixing the action with "identity" for the event_type18:07
*** marcoemorais has joined #openstack-keystone18:07
gordcjust to be clear. i'd prefer all the meters be 'identity.<target>.<action>' or 'identity.<action>.<target>'18:07
gordci think right now there's a mix of both proposed.18:07
*** marcoemorais has quit IRC18:08
morganfainbergooh are we throwing people under busses today?18:08
morganfainbergstevemar, ^18:08
*** marcoemorais has joined #openstack-keystone18:08
stevemargordc, you need to xor that statement18:08
* lbragstad raises hand to be the bus driver... 18:08
*** rushiagr is now known as rushiagr_away18:09
morganfainberglbragstad, knew it!18:09
* gordc will be thrower.18:09
dolphmstevemar volunteers to be throwee.18:09
gordcstevemar: yeah... xor... if you want to get all technically about it.18:09
dolphmgordc: so which of those do you prefer?18:09
dolphmgordc: or we already have both in use anyway?18:09
* lbragstad thinks throwee lines starts behind stevemar18:10
stevemardolphm, the following meters:18:10
dolphmgordc: topics normally get more specific, so <target>.<action> makes more sense to me18:10
gordcdolphm: we have the former checked in right now...18:10
stevemardolphm, http://docs-draft.openstack.org/01/119601/3/check/gate-ceilometer-docs/40363ef/doc/build/html/measurements.html#identity-keystone18:10
gordcdolphm: so the one that makes more sense to you.18:10
*** sigmavirus24_awa is now known as sigmavirus2418:11
gordcdolphm: i'd prefer the same naming scheme... but i'm pretty indifferent ultimately.18:12
stevemargordc, i could just change the meter name, without changing they keystone code right?18:12
gordcstevemar: yep.18:12
gordcstevemar: whether you want to change keystone code is up to you guys.18:12
stevemargordc, i'd have to split the 'action' value, and then re-construct it18:13
*** rushiagr_away is now known as rushiagr18:14
stevemarbut i think other places do that already?18:14
dolphmstevemar: split by dots?18:14
stevemaryep18:14
gordcstevemar: maybe? the meter name isn't really based on message event_type... although they are often similar.18:14
dolphmstevemar: open an RC bug and let's fix it in keystone18:15
*** henrynash has joined #openstack-keystone18:15
stevemardolphm, whats the fix then? change the event_type but not the action?18:15
stevemardolphm, https://github.com/openstack/keystone/blob/master/keystone/notifications.py#L445-L44718:16
stevemarwe always just prefix identity. to the action18:16
dolphmstevemar: well you've convinced me the event_type is wrong in keystone... so change both?18:16
stevemardolphm, we can't change both, because 'action' *has* to start with 'create'18:17
stevemarcause of the cadf spec18:17
morganfainbergdolphm, is this https://bugs.launchpad.net/keystone/+bug/1362245 just an identity-api change?18:17
uvirtbotLaunchpad bug 1362245 in openstack-api-site "Update  Endpoint Filter APIs" [Undecided,New]18:17
morganfainbergoh oh no now i see it18:18
stevemarthe best we could do in keystone, is has event_type be correct 'identity.role_assignemnt.created', and then have action be 'created.role_assignment'18:18
stevemarwhich is kinda silly, cause now we are flipping things around18:18
morganfainbergayoung, ping re: https://bugs.launchpad.net/keystone/+bug/1361422 it's assigned to you and based on your comment not sure if there is anything we should be doing? if we aren't doing anything... is it incomplete or invaid / still a J-RC target?18:19
uvirtbotLaunchpad bug 1361422 in keystone "When using Keystone API v3, catalog won't be returned" [High,Incomplete]18:19
dolphmstevemar: bah. let me look at the code. so event_type="identity.role_assignment.created" and action="created.role_assignment" is ideal, right?18:19
stevemardolphm, yes18:19
dolphmas i scroll back down and see you typed the same thing18:19
stevemardolphm, that'll fix the problem, but it'll be inconsistent to us now, instead of ceilometer18:20
ayoungmorganfainberg, looking18:20
dstanekhenrynash: have you started to hack on https://bugs.launchpad.net/keystone/+bug/1217017 ? i'm curious to know what you came up with18:20
uvirtbotLaunchpad bug 1217017 in keystone "dependency injection fails to init domain-specific identity drivers" [Medium,New]18:20
dolphmmorganfainberg: yeah it's just applying a low-priority convention we sort of missed in the api review18:20
ayoungmorganfainberg, I don't think it is a bug.18:20
morganfainbergayoung, lets make a call because if it isn't a bug we should punt it from RC118:20
ayoungI am not sure why dolphm  assigned it to me, but I  don't think there is anything to do there18:21
ayoungmorganfainberg, bump it18:21
dolphmayoung: which one?18:21
ayoungdolphm,  https://bugs.launchpad.net/keystone/+bug/136142218:21
uvirtbotLaunchpad bug 1361422 in keystone "When using Keystone API v3, catalog won't be returned" [High,Incomplete]18:21
morganfainberggo uvirtbot go uvirtbot go!18:21
morganfainberg:)18:21
gordcstevemar: why do you have outcome in event_type anyways? seems different to how the authenticate messages are sent.18:22
dolphmayoung: that was meeting day... but i don't recall18:22
ayoungdolphm, I suspect that you assigned it to me after seeing my comment, thinking I was going to run with it.  ALthough your assignment is somehow put before my comment, so maybe you had some other reason.18:22
henrynashdstanek: yep, currently working on it18:22
dolphmayoung: 18:08:14 <ayoung> https://bugs.launchpad.net/bugs/1361422  is the only incomplete .  I can take a look at triaging it18:22
uvirtbotLaunchpad bug 1361422 in keystone "When using Keystone API v3, catalog won't be returned" [High,Incomplete]18:23
stevemargordc, outcome is success or fail right? not create/delete18:23
henrynashdtsanek: ran into a few issues with unit test, which I am debugging18:23
dolphmayoung: source- http://eavesdrop.openstack.org/meetings/keystone/2014/keystone.2014-09-09-18.02.log.html18:23
morganfainberglol18:23
ayoungdolphm, I think they are using LDAP and don't hae a default user18:23
stevemargordc, the authN events are special18:23
ayoungdolphm, ah right...yeah...so not abug...unless they come back with more info18:24
ayoungbump from rc118:24
dolphmayoung: your answer is reasonable enough to drop from RC118:24
ayoung++18:24
dstanekhenrynash: if the section is defined for a domain are you forcing all settings to come from that section or do you fallback to the global section?18:24
gordcstevemar: you're special18:24
henrynashdtsanek: I think teh way I wrote the original code was the the items in the domain specific configs are overrides to that in the main config18:25
* gordc drops his mic18:25
stevemargordc, stay class up in here18:25
* morganfainberg pics the mic up and hands it back to gordc, ' i think you dropped this'18:25
gordclol18:25
gordcbiab. going to grab some coffee..18:26
henrynashdtsanek: so you could have the [database] in the global conig, and the driver setting in the domain specifc conffig file18:26
*** topol has quit IRC18:26
samuelmzhenrynash, we have a new patch set on 'Improve list role assignments filters performance' (https://review.openstack.org/#/c/116682/)18:27
*** mikedillion has joined #openstack-keystone18:27
henrynashsamuelmz: ok, will try and take a look later18:27
samuelmzhenrynash, now we consider assignment type when retrieving them18:27
samuelmzhenrynash, ok thanks :-)18:27
*** mikedillion has quit IRC18:30
*** amcrn has joined #openstack-keystone18:32
*** marcoemorais has quit IRC18:32
*** marcoemorais has joined #openstack-keystone18:33
dolphmbknudson: was your -2 on https://review.openstack.org/#/c/116374/ based on https://bugs.launchpad.net/keystone/+bug/1315049/comments/1 ?18:33
uvirtbotLaunchpad bug 1315049 in keystone "'Provider' object has no attribute 'revoke_api'" [Medium,In progress]18:33
dolphmnonameentername: o/ does your fix address the issue in stable/icehouse?18:34
dolphmregarding the bug above18:35
*** ajayaa has joined #openstack-keystone18:37
bknudsondolphm: yes. I tried it myself and master isn't affected.18:37
*** marcoemorais has quit IRC18:37
bknudsondolphm: so no fix is needed in master18:37
*** marcoemorais has joined #openstack-keystone18:38
bknudsondolphm: unless there's actually a different problem?18:38
morganfainbergbknudson, master isn't affected because i think we enabled revoke by default18:38
morganfainbergbknudson, if someone disabled revoke they would possibly hit that?18:39
dolphmmorganfainberg: good question...18:39
bknudsonmorganfainberg: I tried removing revoke from the pipeline and didn't have any problems.18:39
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: SAML2 federated authentication for ADFS.  https://review.openstack.org/11177118:39
dolphmbknudson: isn't there an enable/disable config option too?18:39
dolphmbknudson: OS-REVOKE isn't a real extension18:39
morganfainbergbknudson, hmm. ok. wonder if revoke_api is still getting loaded even w/o the pipeline18:39
*** Ugallu has quit IRC18:39
dstanekmorganfainberg: i believe you are correct - it will break if disabled18:39
morganfainbergdstanek, which means other optionals could in theory break.18:40
dolphmbknudson: is the fix correct for stable/icehouse?18:40
dstanekmorganfainberg: i think so18:40
bknudsondolphm: the fix in master? there's no problem in master currently so it must have been fixed by some other change.18:40
bknudsondstanek: why would it break if disabled?18:41
bknudsonI tried it and didn't have a problem.18:41
bknudsonI didn't do a whole lot of testing, though.18:41
dstanekbknudson: there is code that checks for optional behavior by doing 'if self.some_optional_api'18:42
dstanekbknudson: and we don't have defaults on the classes18:42
*** wanghong has joined #openstack-keystone18:42
dolphmbknudson: backport policy for stable branches is to try to land the fix in master first -- a clean cherry pick to stable/icehouse fixes the issue there, and i don't see any harm in it existing in master (although, I agree, I'd like to see some benefit in master to land it)18:42
bknudsondstanek: the dependency code will inject a some_optional_api.18:42
bknudsonsome_optional_api = None18:43
dstanekbknudson: only if it is configured to be on - the fix is to set it to be None if it's not18:43
dolphmdstanek: configured to be on == keystone.conf os_revoke_enabled = True or something?18:43
bknudsonhttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/dependency.py#n23818:44
bknudson"Resolve optional dependencies, sets the attribute to None if there's no provider registered"18:44
dolphmbknudson: but the new test fails without the fix18:44
dolphmbknudson: so, something must be broken about that claim?18:45
bknudsondolphm: that's entirely possible.18:45
dstanekbknudson: i don't think it works as intended then :-)18:45
dolphmbknudson: *should* the test run successfully as written on master?18:45
dolphmwithout a fix18:45
bknudsondolphm: so the new test does dependency.resolve_future_dependencies(provider_name='some_provider')18:46
bknudsonwhich is the same test as the one just above it: def test_optional_dependency_not_provided(self)18:46
bknudsonexcept it calls with provider_name.18:46
bknudsonwhen the server starts, it calls dependency.resolve_future_dependencies()18:46
bknudsonso that's where the user._api = None would happen18:47
bknudsonso if there's a bug it's the server is failing to call dependency.resolve_future_dependencies()18:47
bknudsonhttp://git.openstack.org/cgit/openstack/keystone/tree/bin/keystone-all#n15118:48
bknudsonhttp://git.openstack.org/cgit/openstack/keystone/tree/httpd/keystone.py#n6118:48
dolphmbknudson: so, tests maybe aren't calling that?18:48
bknudsonthe tests are calling it....18:48
dolphmsince, as far as we know, this is only an issue with $ nosetests keystone/tests/test_auth.py18:48
bknudsonhttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/core.py#n50918:48
dolphmbknudson: the tests are calling it in stable/icehouse?18:49
bknudsonmaybe in icehouse there was a problem?18:49
dolphmbknudson: five tests fail in stable/icehouse without the patch18:49
morganfainbergdolphm, land in master, backport, revert in master :P >.> i mean...18:49
dolphmlol18:49
bknudsonlooks the same in icehouse..18:50
stevemaroh gawd the gate, some changes have been in there for 28 hrs now18:51
stevemarthis is worse than last day of FF18:51
ekarlso-gate flooding :p18:51
bknudsonI get FAILED (errors=37) in stable/icehouse18:52
dolphmbknudson: the failing tests do seem to call resolve_future_dependencies()18:52
gordcstevemar: my change took 30hrs to merge...18:52
*** henrynash has quit IRC18:52
gordci would've smashed things if i needed a recheck.18:53
dolphmmy counter stops counting at 24 hours18:53
bknudsondolphm: one thing to note is that resolve_future_dependencies has to be called after all the backends are loaded... so that might be the issue18:53
stevemargordc, average is 5 rechecks now18:53
stevemari think18:53
stevemar4-518:53
*** __afazekas is now known as afazekas18:53
gordcstevemar: 4-5 new computers per patch then.18:53
bknudsonI ran nosetests in ~/dev/keystone-icehouse and now only 5 errors.18:54
gordcstevemar: back to before i dropped my mic, yes, outcome is success/failure/pending18:54
dolphmbknudson: now you're onto something...18:54
dolphmbknudson: there's no revoke_api in the drivers list when resolve_future_dependencies() is called in stable/icehouse keystone/tests/core.py18:54
stevemargordc, so the fact that we have create/delete in the event_type is fine18:55
gordcstevemar: yeah... i'm trying to think of another place but nothing comes to mind.18:56
bknudsondolphm: if there's no revoke_api in the drivers list then the requirer's revoke_api should get set to None.18:56
dolphmbknudson: oh damn18:56
lbragstadbknudson: so I rebased on your patch (https://review.openstack.org/#/c/119629/) and tried what you suggested, calling self.identity_api.driver.delete_user(user_id), however the user assignment is still being removed18:58
bknudsonlbragstad: in sql?18:59
bknudsonlbragstad: or ldap?18:59
lbragstadbknudson: sql18:59
bknudsonlbragstad: maybe there's a foreign key?19:00
lbragstadbknudson: that's what i was thinking...19:00
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Pass kwargs to auth plugins  https://review.openstack.org/12088319:00
*** rushiagr is now known as rushiagr_away19:00
*** henrynash has joined #openstack-keystone19:00
*** ajayaa has quit IRC19:01
*** gokrokve has joined #openstack-keystone19:01
stevemargordc, also, review this guy: https://review.openstack.org/#/c/120106/ super easy :D19:02
bknudsondolphm: p self.token_provider_api.revoke_api -> None19:02
bknudsonthat's in tests.core load_backends()19:02
dolphm?!19:02
bknudsonp self.token_provider_api.revoke_api19:03
bknudsonthen in the check_revocation_v2() test it's not set.19:03
bknudsonso it token_provider_api is getting reset?19:03
dolphmbknudson: i don't see that anywhere19:03
*** henrynash has quit IRC19:04
dolphmbknudson: i'm looking at load_backends in both icehouse and master..?19:04
*** russellb has quit IRC19:05
bknudsondolphm: it's in AuthTest setUp, it does token.provider.Manager()19:05
*** gokrokve_ has quit IRC19:05
stevemargordc, and this one too :D https://review.openstack.org/#/c/120884/119:06
bknudsondolphm: http://git.openstack.org/cgit/openstack/keystone/commit/keystone/tests/test_auth.py?id=0a1cb0e20247a3c7856b409452b01ad6db8069f019:06
*** gokrokve has quit IRC19:06
gordcstevemar: i decide what's super easy!19:06
*** dtroyer has quit IRC19:06
*** adam_g has quit IRC19:06
bknudsondolphm: I blame morganfainberg and morgan_remote19:07
*** russellb has joined #openstack-keystone19:07
dolphmbknudson: oh, gotcha19:07
*** lbragstad has quit IRC19:07
gordcstevemar: have you tried running subset of tests using debug_helper? i think it broke at some point when we merged oslotest19:07
gordcdoes it work for you?19:07
bknudsondolphm: I've wanted to put a check in dependency to raise if it's setting a provider multiple times.19:07
dolphmhow do you do a reverse git blame / figure out when a line of code that existed was deleted?19:07
dstanekdolphm, bknudson: the problem with that test is that it doesn't have a @provide anywhere19:07
dstanekso resolve_future_dependencies isn't called19:08
stevemargordc, whatcha mean? like specifying a test?19:08
*** henrynash has joined #openstack-keystone19:08
*** henrynash has quit IRC19:08
bknudsondolphm: that's my secret... actually I just did a git log and search for manager19:08
*** dtroyer has joined #openstack-keystone19:08
bknudsonhttp://git.openstack.org/cgit/openstack/keystone/log/keystone/tests/test_auth.py19:08
bknudsonCTRL+F manager19:08
gordcstevemar: yeah... i haven't tried it with purely oslotests but i think when we merged oslotests and had debug_helper still in ceilometer, i couldn't run a subset of tests.19:09
gordcstevemar: i've no idea if they're related... i just know at some point after i merged original debug_helper patch, it stopped working.19:09
bknudsonluckily morganfainberg picks useful commit summary19:09
stevemargordc, thats weird, i tried it out in keystone and it's fine19:09
morganfainbergbknudson, hmm?19:10
stevemargordc, in ceilometer there is a weird step that builds virtualenv, maybe thats why19:10
gordcstevemar: cool cool. i'll give it a try agian later... maybe just my environment... or some other weird step i need to figure out.19:10
*** hockeynut has quit IRC19:10
*** lbragstad has joined #openstack-keystone19:10
gordcstevemar: maybe19:10
stevemargordc, you're gonna have to nuke your debug env in .tox19:10
bknudsonmorganfainberg: you fixed https://bugs.launchpad.net/keystone/+bug/1315049 with https://bugs.launchpad.net/keystone/+bug/129499419:10
uvirtbotLaunchpad bug 1315049 in keystone "'Provider' object has no attribute 'revoke_api'" [Medium,In progress]19:10
bknudsonin master19:10
morganfainbergbknudson, ahhhh19:10
morganfainbergbknudson, good to know! :)19:10
*** d34dh0r53 has quit IRC19:11
dolphmbknudson: https://review.openstack.org/#/c/120886/19:11
gordcstevemar: yeah. i tried that... i just gave up and just ran it outside of tox.19:11
*** d34dh0r53 has joined #openstack-keystone19:11
morganfainbergbknudson, oh god that stuff. yeah that was awful19:11
gordci'll look at it later.19:11
stevemargordc, cool - whats this stuff do? bash -x {toxinidir}/setup-test-env.sh19:11
dolphmnosetests keystone/tests/test_auth.py runs successfully in stable/icehouse with that ^ but leaving it as WIP until tox finishes19:12
gordcstevemar: configures dbs for backend tests mostly19:12
dolphmbknudson: thanks for the patch :)19:12
*** hockeynut has joined #openstack-keystone19:12
*** Ephur has quit IRC19:13
bknudsondolphm: np19:13
stevemargordc, just confirms it still works with master, trying my patch now to make sure19:14
*** Guest75250 has quit IRC19:14
lbragstadbknudson: looking at the keystone database and I'm nothings jumping out, no foreign keys between user and assignment or user and role tables,19:15
lbragstadthe assignment and role tables have a foreign key reference19:15
bknudsonlbragstad: use the debugger and see where it's getting deleted.19:15
gordcstevemar: in ceilometer?19:15
*** Ephur has joined #openstack-keystone19:15
*** russellb has quit IRC19:15
stevemargordc, yep19:15
gordcwell that sucks.19:15
*** dolphm has quit IRC19:16
*** dtroyer has quit IRC19:17
stevemargordc, http://imgur.com/hO6R9oS19:17
*** david-lyle has quit IRC19:17
stevemarmight be your machine19:17
*** dolphm has joined #openstack-keystone19:17
*** david-lyle has joined #openstack-keystone19:17
gordcstevemar: was going to give another mic drop response...i'll refraim19:18
gordcrefrain*19:18
*** lbragstad has quit IRC19:19
*** lbragstad has joined #openstack-keystone19:20
*** d34dh0r53 has quit IRC19:20
*** d34dh0r53 has joined #openstack-keystone19:20
*** hockeynut has quit IRC19:21
*** hockeynut has joined #openstack-keystone19:22
stevemargordc, just tried the new oslo_debug_helper, works too!19:22
*** nkinder_ has quit IRC19:23
gordcf... retry19:23
dstanekdolphm: what's up with https://review.openstack.org/#/c/101829/ ? do you think we should hold off like gyee suggested?19:24
*** Ephur has quit IRC19:24
*** bjornar_ has quit IRC19:25
morganfainbergdstanek, dolphm, not sure why we should hold off on that19:25
*** KanagarajM has joined #openstack-keystone19:25
*** dolphm has quit IRC19:26
*** dolphm has joined #openstack-keystone19:26
*** wanghong has quit IRC19:26
morganfainbergdstanek, it seems like something we'd want to backport and OSSN/OSSA19:26
*** lbragstad has quit IRC19:28
*** d34dh0r53 has quit IRC19:29
bknudsonyou would do an OSSA if this exposed a security vulnerability... not sure what the vuln would be?19:29
morganfainbergbknudson, OSSN then?19:29
dstanekmorganfainberg: what is the OSSN/OSSA for?19:29
*** d34dh0r53 has joined #openstack-keystone19:29
morganfainbergbknudson, based on gyee's comment19:30
*** hockeynut has quit IRC19:30
dstanekmorganfainberg: is it a security issue that the user can't tell who gave them the trust? you can't actually exploit that in any way can you?19:31
*** hockeynut has joined #openstack-keystone19:31
morganfainbergdstanek, hm. well.. you can't revoke that token when the trustor changes password/disabled19:31
morganfainbergdstanek, i *think*19:31
morganfainbergi'd need to dig, but it might be revocation related issues19:31
*** topol has joined #openstack-keystone19:31
morganfainbergdstanek, that would be the only security bits19:32
dstanekmorganfainberg: that's a good point if the tokens are long lived19:32
morganfainbergdstanek, tokens tend to live 3600s-86400s19:33
morganfainbergrange19:33
*** lbragstad has joined #openstack-keystone19:34
*** dolphm has quit IRC19:35
*** dolphm has joined #openstack-keystone19:35
morganfainbergdstanek, i'd say we are definitely "long lived" tokens19:36
*** lbragstad has quit IRC19:37
gyeeI think its a security issue because 1) we can't tell who give the trust; and 2) we can't tell if its an impersonation19:37
*** lbragstad has joined #openstack-keystone19:37
*** raildo_ has joined #openstack-keystone19:38
gyeeI suppose we can tell by looking at both the user_id and trustee_user_id, if they are the same, then impersonation19:38
gyeeif they are different I mean19:38
*** d34dh0r53 has quit IRC19:38
*** colettecello has joined #openstack-keystone19:38
*** d34dh0r53 has joined #openstack-keystone19:38
*** csd_ has joined #openstack-keystone19:39
*** hockeynut has quit IRC19:39
dstanekgyee: can you exploit that?19:40
*** hockeynut has joined #openstack-keystone19:40
*** csd has quit IRC19:40
*** raildo has quit IRC19:40
*** gothicmindfood has quit IRC19:40
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/11162019:40
*** csd_ is now known as csd19:40
bknudsongyee: I have no problem with putting out an ossa for the problem.19:43
bknudsonthen we'd have to fix it.19:43
*** dolphm has quit IRC19:44
*** dolphm has joined #openstack-keystone19:44
*** dims has quit IRC19:44
*** Dafna has quit IRC19:45
gyeedstanek, bknudson,  since devstack doesn't use v2 trust so the problem is unknown19:45
morganfainberggyee, bknudson, dstanek, the alternative is (i think) breaking v2 trusts (probably a bad idea)19:45
morganfainbergbreaking = disabling completly19:46
*** lbragstad has quit IRC19:46
gyeebut we are not disabling anything though19:46
dstanekgyee: i'm not against this at all, i'm just curious to know if it's actually exploitable19:47
gyeequestion is are there any authorization policy out there that takes these two attributes into consideration19:47
*** d34dh0r53 has quit IRC19:47
morganfainbergok well in SQL tokens, this looks to be non-issue actually19:48
morganfainbergsince we always filter on trust_id . /me checks one more thing19:48
*** hockeynut has quit IRC19:48
morganfainbergand in KVS we only care about trustee_user_id it looks like.19:49
*** sigmavirus24 has quit IRC19:49
morganfainbergok so, not exploitable, afaict, so we can just hold this back probably19:49
*** d34dh0r53 has joined #openstack-keystone19:50
*** mgagne has joined #openstack-keystone19:51
gyeemorganfainberg, yeah, looks like they are not needed19:51
*** ChanServ sets mode: +o dolphm19:51
morganfainbergbknudson, gyee, dstanek, no OSSA/OSSN needed19:51
morganfainbergthough... it will break revocation events now that i think about it19:51
morganfainbergpotentialyl.19:51
*** sigmavirus24 has joined #openstack-keystone19:51
gyeeif user_id is the same as trustee_user_id, impersonation is false19:52
* dolphm is back from vnc server meltdown19:52
dolphmerr znc19:52
morganfainbergand looks like revocaton events are also unaffected19:52
morganfainbergat worst we are missing some data that could be used for audit in the token body19:53
morganfainbergs/audit/auditing that isn't cadf19:53
morganfainbergdolphm, welcome back19:55
gyeevnc :)19:57
gyeeI could use some gnc19:57
*** enewlands has joined #openstack-keystone19:58
*** jsavak has joined #openstack-keystone19:58
ayoungmorganfainberg, dolphm, got someone to work on docs, but she works on a mac, and I'm clueless there  she's got git but not pip or tox...19:59
dolphmayoung: homebrew!19:59
dolphmayoung: http://brew.sh/19:59
dolphmayoung: how i provision my own mac to get pip and whatnot https://github.com/dolph/dotfiles/blob/master/provision.sh19:59
rharwoodor macports: macports.org19:59
dolphmrharwood: NO20:00
rharwood?20:00
dolphmmacports was never any good, and it's now completely dead20:00
morganfainberggyee, bknudson, dstanek , commented on the bug and downgraded my score of the patch to +1, it isn't needed for juno rc20:00
morganfainberggyee, bknudson, dstanek, but i don't mind if we want to include it in RC.20:00
rharwoodit has worked fine for me for years and has multiple apple devs working on it...20:01
dolphmmorganfainberg: i was about to ask why ya'll didn't +A.20:01
*** joesavak has quit IRC20:01
morganfainbergdolphm, gyee's comment.20:01
morganfainbergdolphm, so can go in, doesn't have to.20:01
dolphmrharwood: that's... really suprising20:01
rharwoodI'm not sure why you would think it's dead?20:01
morganfainbergrharwood, i've found brew works a *lot* better20:01
*** joesavak has joined #openstack-keystone20:02
morganfainbergrharwood, my experience macports wasn't particularly friendly when i did use it20:02
dolphmmacports drove me back to linux20:02
gyeemorganfainberg, I don't have a strong opinion on that one20:02
*** lbragstad has joined #openstack-keystone20:02
*** diegows has joined #openstack-keystone20:03
*** colettecello is now known as gothicmindfood20:03
*** dims_ has joined #openstack-keystone20:03
gyeedolphm, rharwood, I've been using homebrew too, does the job for me20:03
gyeeI don't do anything fancy20:03
*** jsavak has quit IRC20:03
ayoungrharwood, yeah, that was annegentle's response as well...looks like it is the way today20:05
*** henrynash has joined #openstack-keystone20:08
*** nkinder_ has joined #openstack-keystone20:11
*** topol has quit IRC20:12
*** dims__ has joined #openstack-keystone20:17
*** dims_ has quit IRC20:20
*** dims__ has quit IRC20:22
*** marcoemorais has quit IRC20:36
*** marcoemorais has joined #openstack-keystone20:37
morganfainbergdolphm, for bug 1294994 did you need me to do the backport?20:38
uvirtbotLaunchpad bug 1294994 in keystone "Managers instantiated multiple times" [Medium,Fix released] https://launchpad.net/bugs/129499420:38
morganfainbergdolphm, or was there an open cr you had20:39
*** marcoemorais has quit IRC20:39
*** radez is now known as radez_g0n320:40
*** zzzeek has quit IRC20:40
*** marcoemorais has joined #openstack-keystone20:40
*** marcoemorais has quit IRC20:40
*** marcoemorais1 has joined #openstack-keystone20:45
*** jsavak has joined #openstack-keystone20:48
*** joesavak has quit IRC20:52
*** henrynash has quit IRC20:54
*** r1chardj0n3s_afk has joined #openstack-keystone20:54
*** r1chardj0n3s_afk is now known as r1chardj0n3s20:56
*** alex_xu has joined #openstack-keystone21:00
nkinder_ayoung: with the multi-backend functionlity, are the service users in a "default" domain, or is there a "service" domain?21:01
ayoungnkinder_, you can do either.21:01
ayoungnkinder_, here's what Henrynash and I discussed21:01
ayoungusing something like packstack etc, its going to set up SQL and put the service users in default21:02
ayoungleave them there, and create a new domain for your LDAP, and give it a good name,   like REDHAT for us21:02
ayoungso default becomes the service domain.  It does mean you need to do V3 everywhere, though21:02
ayoungnkinder_, in fact, that is what I have set up on my public IPA/Keystone demo.21:03
ayoungI left service user, admin, and demo in Defaul, and then have YOUNGLOGIC.NET as the IPA backed domain.21:03
nkinder_ayoung: ok, I was mainly wondering if you just left it as "default" or if you had to create another domain for the service users.21:04
nkinder_ayoung: the way you set it up is the way I would expect it21:04
*** wwriverrat has left #openstack-keystone21:07
r1chardj0n3shi ayoung: did you see my openstack-dev post about the Javascript/CORS stuff?21:09
*** jsavak has quit IRC21:10
ayoungr1chardj0n3s, nope....still parsing though the 2k emails I get every day21:12
r1chardj0n3sayoung: ok, no worries; the tl;dr is that going the oslo.middleware route is a bad choice :)21:12
r1chardj0n3sayoung: so I'm going to dodge the CORS bullet entirely21:12
ayoungr1chardj0n3s, why21:14
ayoungwe need CORS21:14
ayoungr1chardj0n3s, but, let me read it21:15
r1chardj0n3sfor my purposes I'm going to avoid it, the email explains I hope :)21:15
openstackgerritA change was merged to openstack/keystone: Keystone local authenticate has an unnecessary pending audit record.  https://review.openstack.org/12016221:15
*** amcrn_ has joined #openstack-keystone21:16
ayoungr1chardj0n3s, what is the email title?21:16
ayoungSupporting Javascript clients calling OpenStack APIs21:17
ayoungfound it21:17
r1chardj0n3syah, sent before the overnight (for me overnight) flood21:17
ayoungr1chardj0n3s, you want to do the Proxy solution?  That works, but bypasses the service catalog21:18
ayoungnot insurmountable21:18
r1chardj0n3sayoung: it keeps the service catalog but alters the publicURLs in it21:18
r1chardj0n3sI have this working :)21:18
ayoungyeah, I figured that is where you went21:18
ayoungr1chardj0n3s, I think this is a good first step.21:19
r1chardj0n3sI'll clean up what I have and put it in the githubs21:19
ayoungI think we will still want CORS support, but, as I was saying, based onthe actual service catalog.  Not all tokens should go everywhere21:19
ayoungr1chardj0n3s, how far along is your Javascript code?21:19
r1chardj0n3sbut as I was saying, that's not CORS' business ;)21:19
r1chardj0n3sayoung: I have a bunch of stuff that I wrote before I saw your code; mine is about the same, but a better structure for the angularjs aspect I think21:20
*** amcrn has quit IRC21:20
ayoungr1chardj0n3s, yeah, mine is proof of concept21:20
ayoungr1chardj0n3s, I have a deep interest in Kerberos.  I wonder if you are messing that up21:21
r1chardj0n3sayoung: I'd love to know! :)21:21
ayoungr1chardj0n3s, nkinder_ lets figure that out21:21
ayoungr1chardj0n3s, WHat are you using for your proxy?21:22
r1chardj0n3sso my plan today (it's just turned Friday here) is to clean the stuff up and get the github repos up with the code and some docs describing the structure of the app21:22
r1chardj0n3sayoung: at the moment, it's a single-page Flask app21:22
ayoungr1chardj0n3s, Flask is one of them toy webservers isn't it?21:23
r1chardj0n3sayoung: yes :)21:23
ayoungr1chardj0n3s, can it run behind apache?21:23
r1chardj0n3sayoung: yes21:23
r1chardj0n3shttps://gist.github.com/r1chardj0n3s/3f2f3aca2298ae483440 is the current state of it21:24
r1chardj0n3sit needs some fleshing out21:24
ayoungr1chardj0n3s, so due to you rewriting URLS, we can't use that same Apache to front Keystone directly21:24
ayoungbut....21:24
ayoungI could do S4U2Proxy still21:24
*** henrynash has joined #openstack-keystone21:25
r1chardj0n3sI'm not familiar with that21:25
ayoungr1chardj0n3s, its part of Kerberos21:25
r1chardj0n3syep, just saw that in the googs :)21:25
ayoungr1chardj0n3s, its part of how I am doing the current Horizon Kerberization21:26
r1chardj0n3ssorry, I gotta afk to cook breakfast & get daughter off to school21:26
ayoungIt doesn'21:26
ayoungr1chardj0n3s, what about SAML....21:26
*** cjellick_ has joined #openstack-keystone21:26
*** cjellick has quit IRC21:26
*** r1chardj0n3s is now known as r1chardj0n3s_afk21:26
*** adam_g has joined #openstack-keystone21:26
*** adam_g has quit IRC21:27
*** adam_g has joined #openstack-keystone21:27
ayoungr1chardj0n3s_afk, you might be messing up some of the other web authentication methods, but the only one I think that you would outright break is X509 client certs21:27
*** wanghong has joined #openstack-keystone21:28
*** marcoemorais1 has quit IRC21:31
*** marcoemorais has joined #openstack-keystone21:32
*** marcoemorais1 has joined #openstack-keystone21:34
*** marcoemorais1 has quit IRC21:34
*** marcoemorais1 has joined #openstack-keystone21:35
*** marcoemorais1 has quit IRC21:35
*** marcoemorais1 has joined #openstack-keystone21:36
*** marcoemorais1 has quit IRC21:36
*** marcoemorais1 has joined #openstack-keystone21:37
*** marcoemorais has quit IRC21:37
*** marcoemorais1 has quit IRC21:37
*** marcoemorais has joined #openstack-keystone21:37
*** marcoemorais has quit IRC21:37
openstackgerritLance Bragstad proposed a change to openstack/keystone: Add a functional tests for role assignments  https://review.openstack.org/11984321:38
*** marcoemorais has joined #openstack-keystone21:38
*** jaosorior has quit IRC21:42
*** enewlands has quit IRC22:02
*** dims_ has joined #openstack-keystone22:10
*** wanghong has quit IRC22:11
openstackgerritayoung proposed a change to openstack/keystone: Safer check for enabled in trusts  https://review.openstack.org/12059222:13
*** amcrn_ is now known as amcrn22:13
*** KanagarajM has quit IRC22:13
*** dims_ has quit IRC22:14
ayoungmorganfainberg, dolphm thanks for the  help on Mac.  I figure whenever someone is willing to write docs on the security vital stuff, its worth walking them through the process.22:15
morganfainbergayoung, np22:16
morganfainbergand agreed22:16
morganfainbergayoung, so... is this worth getting in for J? https://review.openstack.org/#/c/101829/ it has functionally almost no benefit/detriment22:17
morganfainbergayoung, because if it si we should approve it22:17
ayoungOk, here's why I think it should go in22:17
morganfainbergat best it's a nice to have.22:17
morganfainbergat worst it's a nice to have :)22:18
ayoungI think that trusts are kindof broken without it.22:18
ayoungIt means that you have to do impersonation in order to know who the trustor is, and that is just not something we want to encourage22:19
morganfainbergayoung, they aren't really broken though.22:19
ayoungmorganfainberg, it is, though.  It people need to check ownership, and they only check user, we'll have people doing impersonation22:19
ayounglike the Barbican folks22:19
morganfainbergayoung, *cough* v2 :P22:20
ayoungyeah, I know22:20
morganfainbergayoung, but again, i'm not opposed to it going in22:20
ayoungbut have you ever tried setting up a deployment with V3 everywhere22:20
ayoungits painful, and ....  what does Devstack default to these days,like for horizon22:20
ayoungI'd like to get it in22:20
morganfainbergayoung, so, regardless of it, I have no skin either way here. it has the score to get in just needs approval22:20
morganfainbergand gyee said he doesn't feel strongly either way22:21
ayoungis that dolph?22:21
*** alex_xu has quit IRC22:21
morganfainbergso if you feel strongly, that is a vote to get it in22:21
ayoungI already +2ed it22:21
ayoungwilling to +A it now if there is no objection22:21
morganfainbergayoung, right so i was looking for either punt or +A22:21
morganfainbergnah don't think so22:21
morganfainberggo for it22:21
ayoungwill do22:21
morganfainbergayoung, i just want to get things off the RC list one way or another and this is a very minor thing22:22
morganfainbergayoung, thanks! :)22:22
ayoungmorganfainberg, I think the way that one got missed is that trusts were originally impersonation only.22:22
morganfainbergmakes sense22:23
ayoungdolph convinced me that was a bad idea, so it was late in the trusts review process22:23
ayoungbut I suspect that the dominant way people were using trusts in V2 were for swift, whcih meant they needed impersonation anyway22:23
ayoungwhich is why there has been no complaint22:23
*** andreaf has quit IRC22:23
jamielennoxayoung: i'm not here yet, however do you mind having a look at https://review.openstack.org/#/c/118004/ it would be useful for the next release22:24
ayounghowever, swift has, I think, changed somehow that makes that no longer a hard requirement22:24
notmyname?22:24
ayoungjamielennox, I have one for you, too22:24
jamielennoxthere's one other i think and the rest are ok to wait for22:24
jamielennoxis it revocation events?22:24
ayounghttps://review.openstack.org/#/c/120883/  jamielennox that is from the kerberos patch22:25
notmynameayoung: what did swift change?22:25
ayoungnotmyname, I'm not sure, but I t thought it was something on the ownership model for the API22:25
ayoungnotmyname, this is all hearsay, and will not hold up in court22:25
ayoungbut the reason that trusts had impersonation was the objects in swift were owned by users, and to read/write them the trust tokens had to impersonate those users22:26
jamielennoxayoung: +2 - i think i might have wrote that anyway22:26
ayoungjamielennox, thanks22:26
ayoungmorganfainberg, can you hit that one as well.  I need it in the next client for testing the kerberos auth plugin22:27
notmynameayoung: we just landed https://review.openstack.org/#/c/86430/ which AFAIK gets us keystone v3 acls22:27
ayounghttps://review.openstack.org/#/c/120883/22:27
notmynameayoung: errr..."landed". currently waiting/fighting jenkins22:27
ayoungheh,  notmyname I know that pain22:27
ayoungnotmyname, you coming to Westford for the swift hackathon?22:28
notmynameof course. where else would I be?22:28
ayoungawesome. I'll be here on Tuesday for it.22:28
ayoungWell, I'd be here anyway, but I'll be in the -thon22:29
*** diegows has quit IRC22:32
*** gordc has quit IRC22:32
dolphmmorganfainberg: what's different in patchset 2 of https://review.openstack.org/#/c/120924/ ? the diffs on keystone/identity/controllers.py and keystone/token/providers/pki.py aren't loading for me22:33
morganfainbergdolphm, reset the author :P22:34
morganfainbergdolphm, morgan.fainberg@gmail.com vs m@metacloud.com22:34
* dolphm scratches head22:34
morganfainbergdolphm, i also didn't see your upload and was working on the backport myself separately22:34
morganfainbergso when i uploaded it just added patchset 222:34
morganfainberg:P22:34
dolphmmorganfainberg: oh you're on a different parent sha for some reason22:34
morganfainbergand different commit message22:35
morganfainbergdolphm, https://review.openstack.org/#/c/120924/1..2//COMMIT_MSG22:35
morganfainbergso basically... meh.22:36
dolphmmorganfainberg: your local stable/icehouse branch is 2 commits behind github22:36
morganfainbergdolphm, huh. i did a fetch/checkout22:36
morganfainbergweird22:36
dolphmmorganfainberg: *shrug* that's the diff i'm seeing in the gerrit UI, but it's timing out trying to render it22:37
dolphmso i'm going to go make dinner22:37
dolphmo/22:37
morganfainbergyeah.22:37
morganfainbergbasically i think the bulk of the change is commit message :P22:37
morganfainbergand parent22:37
*** openstackgerrit has quit IRC22:38
*** openstackgerrit_ has joined #openstack-keystone22:38
morganfainbergit's what happens when you walk away a while back and forget to hit enter on 'git review' then come back :P22:38
*** bknudson has quit IRC22:39
*** diegows has joined #openstack-keystone22:40
*** openstackgerrit_ is now known as openstackgerrit22:40
*** gyee has quit IRC22:40
openstackgerritRichard Megginson proposed a change to openstack/keystone: ldap/core deleteTree not always supported  https://review.openstack.org/7489722:41
*** dims_ has joined #openstack-keystone22:44
*** ayoung has quit IRC22:45
*** henrynash has quit IRC22:57
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: SAML2 federated authentication for ADFS.  https://review.openstack.org/11177122:58
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: SAML2 federated authentication for ADFS.  https://review.openstack.org/11177123:03
*** diegows has quit IRC23:07
stevemardstanek, if you could be so find as to take a look at ^23:11
stevemarkind*23:11
stevemarmarek's been workin hard on it, and I think you reviewed the initial saml patch fairly closely?23:12
*** hrybacki has joined #openstack-keystone23:25
*** stevemar has quit IRC23:26
r1chardj0n3s_afkayoung: thanks for the email response!23:27
*** r1chardj0n3s_afk is now known as r1chardj0n3s23:27
*** arunkant_work has quit IRC23:29
jamielennoxdolphm: you see anything about https://bugs.launchpad.net/swift/+bug/1368048 that needs fixing in middleware? (the problem adding www-authenticate to middleware responses)23:30
uvirtbotLaunchpad bug 1368048 in swift "testQuotedWWWAuthenticateHeader date time encoding error" [Critical,Fix committed]23:30
*** alex_xu has joined #openstack-keystone23:30
*** r-daneel has quit IRC23:33
*** dims_ has quit IRC23:34
*** oomichi has joined #openstack-keystone23:37
*** sigmavirus24 is now known as sigmavirus24_awa23:41
*** diegows has joined #openstack-keystone23:43
*** jorge_munoz has quit IRC23:48
*** diegows has quit IRC23:49
*** dims_ has joined #openstack-keystone23:52
*** dims__ has joined #openstack-keystone23:55
*** aix has joined #openstack-keystone23:56
*** cjellick_ has quit IRC23:57
*** dims_ has quit IRC23:58

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