Wednesday, 2014-07-02

jamielennoxoh yea! stuff is moving!00:00
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: HEAD responses should return same status as GET  https://review.openstack.org/10402600:01
morganfainbergdolphm, ^ first pass00:02
morganfainbergdolphm, i'll write up a nice ML thread once i see how broken things are.00:02
*** david-lyle has quit IRC00:05
*** david-lyle has joined #openstack-keystone00:06
openstackgerritJamie Lennox proposed a change to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10402700:07
jamielennoxmorganfainberg, dolphm: ^^00:07
morganfainbergjamielennox, wow thats a lot of change :P00:07
jamielennoxmorganfainberg: yea, it gets everywhere00:08
jamielennoxif you want me to submit seperate patches that take one thing at a time let me know00:08
morganfainbergnot sure if uh that is warranted00:08
morganfainbergbut we should prob do the same to the other middlewares00:08
morganfainberg=/00:08
jamielennoxthe others should be easier at least00:08
morganfainbergyeah i'll propose the same for s300:09
jamielennoxmemache_crypt is a middleware?00:09
morganfainbergit's only used by middleware00:09
morganfainbergso it probably should be moved to keystonemiddleware.common ?00:09
jamielennoxis common private?00:10
morganfainbergshouldn't be00:10
morganfainbergthis is something we could keep public00:10
jamielennoxcan we make a folder called keystonemiddleware._middleware00:10
jamielennoxmorganfainberg: i dislike that 'could' so much at the moment00:10
morganfainbergwhy?00:10
*** david-lyle has quit IRC00:10
jamielennoxif you don't know a reason for it make it private00:10
morganfainbergi could see other middleware wanting to use it?00:11
morganfainbergshrug00:11
morganfainbergyour call00:11
morganfainbergbut we could just make it _memcache_crypt and00:11
morganfainbergnot export it in __init__00:11
morganfainbergwhich we should do the proper __ALL__ in __init__.py00:11
jamielennoxother middleware in keystonemiddleware could use it, just not external00:11
jamielennoxyea, we should do an __all__ but i don't remember if that's what we decided made things public00:11
morganfainbergsure00:12
morganfainbergit does00:12
morganfainbergif someone does from X import *00:12
jamielennoxsorry, if the exclusion from __all__ made it private00:12
*** gokrokve has quit IRC00:24
*** dims__ has quit IRC00:25
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10403700:28
morganfainbergjamielennox, ^00:28
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10403700:29
jamielennoxmorganfainberg: heh, https://review.openstack.org/#/c/104037/1/examples/pki/gen_cmsz.py00:29
morganfainbergjamielennox, yeah00:29
morganfainbergsearch/replace fail00:29
morganfainberganyway00:31
jamielennoxmorganfainberg: looks good to me00:31
morganfainbergauth_token is a big change i'll need a bit of time to go over it00:31
morganfainbergthe others are relatively small00:31
jamielennoxyea, that one was easy00:31
morganfainbergwow we have ... i think a fairly sizable gap in tempest coverage.00:33
morganfainberglooking at https://review.openstack.org/#/c/104026/ i'm seeing a lot of tempest pass evne though i changed a number of HTTP response codes00:34
morganfainbergif the only failure is the 3 failures i'm expecting to see. ... i'm going to be worried we need to get to the grindstone and get some more (a lot more) tempest00:35
jamielennoxmorganfainberg: it'd be good if there was a tempest framework for tests, things so that we could write unit tests and tempest would see them and execute them against a real server later00:37
morganfainbergjamielennox, that would be hard.00:38
*** daneyon has quit IRC00:39
jamielennoxyea00:39
*** daneyon has joined #openstack-keystone00:39
*** daneyon has quit IRC00:39
jamielennoxgit branch | wc -l00:40
jamielennox8600:41
jamielennox:(00:41
morganfainbergheh00:42
*** dims__ has joined #openstack-keystone00:43
morganfainbergjamielennox, i wonder if we should be translating the middleware now that it's separate00:44
jamielennoxmorganfainberg: how does that work if it's in the pipeline for a server?00:45
morganfainbergdunno00:45
morganfainbergthats why i'm wondering00:45
*** achampion has joined #openstack-keystone00:45
morganfainbergthe HTTP response change patch, fails the same way as apache fails now *good thing*00:46
morganfainbergbut only the same three errors00:46
morganfainbergwhich makes me very worried what we're not testing00:46
jamielennoxi didn't see the original problem there00:46
morganfainbergGET and HEAD are supposed to return the exact same thing00:47
morganfainbergjust HEAD without the body00:47
jamielennoxyea00:47
jamielennoxwhat was offending?00:47
morganfainbergincluding status, headers (content-type, and content-length)00:47
morganfainbergjamielennox, check_user_in_trust00:47
morganfainbergand 'check_token'00:47
morganfainbergand one of the project endpoint assoc calls00:48
morganfainbergproject endpoint filter assoc00:48
morganfainbergor ehceck role in trust00:48
morganfainbergone of those00:48
jamielennoxthey were different or there was no GET registered?00:48
jamielennoxi didn't know you could call GET for check_token00:48
morganfainbergthe trust and project filter ones were no GET registered00:48
morganfainbergthe trust one returned 204 instead of 200 (head had a different code path)00:49
morganfainbergsame w/ token00:49
morganfainbergcheck token is meant to be "is token valid, we don't care about the data"00:49
morganfainbergHEAD = check token00:49
morganfainbergGET = validate (check and return data)00:49
morganfainbergalso wsgi.render_response would merrly send body data out on a HEAD request.00:50
morganfainbergso fixed that as well00:50
*** dstanek is now known as dstanek_zzz00:50
*** diegows has quit IRC00:51
jamielennoxyea, there are a lot of problems with our wsgi path00:51
jamielennoxi would like to get time to look at the pecan thing again, but not sure when that will happen00:52
*** xianghui has joined #openstack-keystone00:58
*** mitz_ has joined #openstack-keystone01:11
morganfainbergjamielennox, bknudson, dolphm, http://lists.openstack.org/pipermail/openstack-dev/2014-July/039132.html01:14
morganfainberggyee, dstanek_zzz, ^01:14
*** dstanek_zzz is now known as dstanek01:17
morganfainbergjamielennox, i think we should have a programatic test the does GET and HEAD on the same REST call and verifies the only difference is body itself01:17
jamielennoxthat would need to be added to every HEAD request though right01:18
morganfainbergevery get request01:18
jamielennoxi don't think you have to response to HEAD01:18
morganfainbergor well at elast something that tries the GEt and HEAD appropriately01:18
jamielennoxjust if you response to both they should be the same01:18
*** mberlin has quit IRC01:18
morganfainbergyou're supposed to, i think01:18
*** marcoemorais has quit IRC01:22
openstackgerritA change was merged to openstack/python-keystoneclient: Session loading from CLI options  https://review.openstack.org/9567801:25
*** mberlin has joined #openstack-keystone01:34
openstackgerritSteve Martinelli proposed a change to openstack/keystone-specs: Federating multiple Keystones  https://review.openstack.org/10002301:41
*** gokrokve has joined #openstack-keystone01:49
*** praneshp has quit IRC01:54
*** rodrigods_ has joined #openstack-keystone01:56
*** nsquare has quit IRC01:59
*** nsquare has joined #openstack-keystone02:00
*** nsquare has quit IRC02:17
*** zhiyan_ is now known as zhiyan02:22
*** xianghui has quit IRC02:24
*** dstanek is now known as dstanek_zzz02:26
*** rodrigods_ has quit IRC02:27
lbragstadquick question on the Policy API. Here https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#policy it says that 'type' can be anything as long as it's a MIME Media Type.02:29
lbragstadFor validating that parameter, should I compare against an entire list of possible MIME types?02:29
lbragstador just make sure that parameter is a string?02:30
*** zhiyan is now known as zhiyan_02:30
*** zhiyan_ is now known as zhiyan02:42
nkinder_morganfainberg: interesting finding with HEAD vs. GET...02:43
jamielennoxlbragstad: string i think, we can't know all media types02:43
morganfainbergnkinder_, yeah. that was a weird one02:43
lbragstadjamielennox: yeah, that's kind of what I was thinking when I saw http://www.freeformatter.com/mime-types-list.html02:43
openstackgerritwanghong proposed a change to openstack/keystone: auth tests should not require admin token  https://review.openstack.org/10186102:43
jamielennoxlbragstad: regarding that you know the validation object patch i had - if you are still ok with doing it that way you should just incorporate it into the initial patch rather than have me rebase it02:45
nkinder_morganfainberg: hopefully people are in agreement with your suggestions02:46
morganfainbergnkinder_, i'm wondering if this will be an issue to "fix" or it'll be close enough being in the same 2xx series02:46
morganfainbergnkinder_, ++ we shall see :)02:46
nkinder_so aside from this, do tempest tests pass with keystone in httpd/mod_wsgi?02:46
morganfainbergnkinder_, they fail in the same way as that review02:47
morganfainbergnkinder_, but otherwise yes02:47
nkinder_morganfainberg: cool.  So close to gate tests in httpd...02:47
morganfainbergnkinder_, exactly02:47
*** dstanek_zzz is now known as dstanek02:48
morganfainbergneed that fix patch, 1 tempest fix, and 2 devstack patches to land02:48
morganfainbergall very close02:48
*** nsquare has joined #openstack-keystone02:48
openstackgerritwanghong proposed a change to openstack/keystone: delete association when delete proj or endpoint  https://review.openstack.org/8755102:50
*** harlowja is now known as harlowja_away02:50
*** ajc_ has joined #openstack-keystone02:50
lbragstadjamielennox: you mean with the objects?02:52
*** praneshp has joined #openstack-keystone02:52
nkinder_morganfainberg: you got your first vote of agreement on the -dev list...02:54
morganfainbergnkinder_, i saw :)02:54
*** richm has quit IRC02:56
jamielennoxlbragstad: yep02:58
*** xianghui has joined #openstack-keystone03:05
gyeemorganfainberg, ++03:06
gyeenice piece of investigative work there03:06
*** dims__ has quit IRC03:09
*** gyee has quit IRC03:10
*** stevemar has joined #openstack-keystone03:20
*** zhiyan is now known as zhiyan_03:22
*** zhiyan_ is now known as zhiyan03:24
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add a fixture for Keystone version discovery  https://review.openstack.org/9984603:28
*** zhiyan has quit IRC03:30
*** zhiyan has joined #openstack-keystone03:37
*** zhiyan is now known as zhiyan_03:39
*** zhiyan_ is now known as zhiyan03:40
*** zhiyan is now known as zhiyan_03:46
*** zhiyan_ is now known as zhiyan03:50
*** praneshp_ has joined #openstack-keystone04:01
*** praneshp has quit IRC04:04
*** praneshp_ is now known as praneshp04:04
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Policy V3 API  https://review.openstack.org/10406504:21
openstackgerritLance Bragstad proposed a change to openstack/keystone: Implement validation on Trust V3 API  https://review.openstack.org/10406604:21
mrdahey keystone - I'm looking to implement token expiry in Nova's Ironic driver.  I have an HTTPClient object - from this, am I able to get access to the ['token']['expires'] timestamp?  I'm grepping code bases but not making much progress.  Can anyone point me in the right direction?04:35
*** dims__ has joined #openstack-keystone04:37
jamielennoxmrda: what do you mean a HTTPClient object? a keystoneclient HTTPClient?04:37
mrdaYes, I believe it's a keystone HTTPClient04:38
jamielennoxfirst question, how did you acquire a keystoneclient client, didn't token come through from auth_token?04:38
mrdayes, there's the auth_token (or user/pass creds) that is used to obtain the HTTPClient (via a get_client) call04:40
mrdathe thing is, is that I want to cache the object and reuse to minimise retrieving the client on every call04:41
mrdaso I want to check the expiry04:41
jamielennoxso the short answer is there is a client.auth_ref object which is essentially the token04:41
jamielennoxauth_ref.expires is a datetime object04:42
mrdaso the auth_ref contains the id and expires fields?04:42
jamielennoxyou can serialize and reload auth_ref04:42
*** dims__ has quit IRC04:42
mrdaok, sounds like that's what I want then04:42
jamielennoxyep, auth_ref contains a lot of data04:42
jamielennoxsee: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/access.py04:43
jamielennoxan auth_ref is an AccessInfo, so it also has a method .will_expire_soon(duration)04:43
mrdaI think you've just helped unstick me :)04:43
mrdaeven better - I wrote a similar method to will_expire_soon() which I can discard now.04:44
mrdathanks jamielennox - much appreciated!04:44
jamielennoxmrda: no worries04:45
*** lbragstad is now known as lbragstad_04:45
*** dims__ has joined #openstack-keystone05:02
*** dstanek is now known as dstanek_zzz05:04
*** stevemar has quit IRC05:05
*** dims__ has quit IRC05:07
*** afazekas_ has joined #openstack-keystone05:21
*** rwsu has quit IRC05:24
*** chandan_kumar has joined #openstack-keystone05:38
*** dstanek_zzz is now known as dstanek05:51
*** ukalifon has joined #openstack-keystone05:55
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/10338006:00
*** dstanek is now known as dstanek_zzz06:01
*** dims__ has joined #openstack-keystone06:03
*** dstanek_zzz is now known as dstanek06:06
*** dims__ has quit IRC06:08
*** dstanek is now known as dstanek_zzz06:15
*** gokrokve has quit IRC06:29
*** jaosorior has joined #openstack-keystone06:34
*** mitz_ has quit IRC06:48
*** mitz_ has joined #openstack-keystone06:50
*** nsquare has quit IRC06:51
*** tkelsey has joined #openstack-keystone06:51
*** gokrokve has joined #openstack-keystone07:00
*** gokrokve_ has joined #openstack-keystone07:02
*** gokrokv__ has joined #openstack-keystone07:04
*** gokrokve has quit IRC07:04
*** gokrokve_ has quit IRC07:07
*** gokrokv__ has quit IRC07:08
*** BAKfr has joined #openstack-keystone07:10
*** mrda is now known as mrda_away07:11
*** marekd|away is now known as marekd07:24
*** afazekas_ is now known as afazekas07:25
marekdmorganfainberg: https://review.openstack.org/#/c/60489/ this patch was landed by Diane, probably by mistake. I didn't know there was ongoing work on keysone-specs, since Kristy was actively changing it...:(07:25
*** leseb has joined #openstack-keystone07:38
*** praneshp has quit IRC07:38
*** gokrokve has joined #openstack-keystone08:04
*** dims__ has joined #openstack-keystone08:06
*** gokrokve has quit IRC08:09
*** dims__ has quit IRC08:11
*** oomichi has quit IRC08:14
*** fifieldt_ has joined #openstack-keystone08:16
*** fifieldt has quit IRC08:18
openstackgerritSlawomir Gonet proposed a change to openstack/keystone: Ending periods in exception messages deleted  https://review.openstack.org/10385208:23
*** gokrokve has joined #openstack-keystone08:30
*** fifieldt_ is now known as fifieldt08:31
*** henrynash has joined #openstack-keystone08:32
*** gokrokve has quit IRC08:34
*** bvandenh has joined #openstack-keystone08:48
*** gokrokve has joined #openstack-keystone09:02
*** leseb has quit IRC09:03
*** leseb has joined #openstack-keystone09:03
*** gokrokve has quit IRC09:03
*** leseb has quit IRC09:04
*** gokrokve has joined #openstack-keystone09:04
*** leseb has joined #openstack-keystone09:04
*** dims__ has joined #openstack-keystone09:07
*** gokrokve has quit IRC09:09
openstackgerritA change was merged to openstack/keystone-specs: Update pbr version  https://review.openstack.org/10333909:09
*** dims__ has quit IRC09:12
openstackgerrithenry-nash proposed a change to openstack/keystone: Add identity mapping capability  https://review.openstack.org/10243009:16
*** leseb has quit IRC09:17
*** leseb has joined #openstack-keystone09:18
openstackgerritwanghong proposed a change to openstack/keystone-specs: Revoke tokens when deleting EC2 credential  https://review.openstack.org/10349309:18
*** andreaf has joined #openstack-keystone09:24
openstackgerritwanghong proposed a change to openstack/keystone: Clean up EP-Filter after delete project/endpoint  https://review.openstack.org/8755109:27
*** leseb has quit IRC09:27
*** leseb has joined #openstack-keystone09:27
openstackgerritwanghong proposed a change to openstack/keystone-specs: Revoke tokens when deleting EC2 credential  https://review.openstack.org/10349309:32
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Trusted Attributes Policy for External Identity Providers  https://review.openstack.org/10027909:49
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Simplified Mapping for Federated Authentication  https://review.openstack.org/10028009:53
openstackgerritZhi Yan Liu proposed a change to openstack/python-keystoneclient: Expose an entry point to list auth_token middleware config options  https://review.openstack.org/10412809:54
openstackgerritSlawomir Gonet proposed a change to openstack/keystone: Ending periods in exception messages deleted  https://review.openstack.org/10385209:56
*** gokrokve has joined #openstack-keystone10:02
*** leseb has quit IRC10:05
openstackgerritChristian Berendt proposed a change to openstack/python-keystoneclient: Calculate a suitable column width for positional arguments  https://review.openstack.org/9787310:05
*** leseb has joined #openstack-keystone10:06
*** gokrokve has quit IRC10:07
*** dims__ has joined #openstack-keystone10:08
*** dims__ has quit IRC10:13
*** leseb has quit IRC10:13
*** leseb has joined #openstack-keystone10:13
openstackgerrithenry-nash proposed a change to openstack/keystone: Add identity mapping capability  https://review.openstack.org/10243010:16
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421410:16
*** leseb has quit IRC10:24
*** leseb has joined #openstack-keystone10:25
openstackgerrithenry-nash proposed a change to openstack/keystone: Add identity mapping capability  https://review.openstack.org/10243010:29
*** dims__ has joined #openstack-keystone10:32
*** henrynash has quit IRC10:42
*** jdennis has quit IRC11:01
*** gokrokve has joined #openstack-keystone11:02
*** gokrokve has quit IRC11:08
*** tellesnobrega has left #openstack-keystone11:16
*** leseb has quit IRC11:23
*** leseb has joined #openstack-keystone11:23
*** leseb has quit IRC11:30
*** leseb has joined #openstack-keystone11:31
*** tkelsey has quit IRC11:32
*** ajc_ has quit IRC11:58
*** gokrokve has joined #openstack-keystone12:02
*** gokrokve has quit IRC12:07
*** bvandenh has quit IRC12:08
marekdmhu: hey12:10
marekdmhu: i am reading your e-mail and not sure what specs are you talking about? :-)12:10
mhumarekd, i am in a meeting atm, can I get back to you a bit later ?12:10
marekdmhu: anytime!12:10
mhumarekd, thx12:10
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Document authentication plugins  https://review.openstack.org/8407112:19
*** achampion has quit IRC12:27
*** diegows has joined #openstack-keystone12:28
*** dstanek_zzz is now known as dstanek12:29
*** erecio has joined #openstack-keystone12:43
marekddolphm: o/ For public_keys in k2k federation, are you leaning towards any of two options - keeping them in Keystone's backend or using Barbican for that?12:44
*** leseb has quit IRC12:45
*** _elmiko is now known as elmiko12:45
*** leseb has joined #openstack-keystone12:45
*** dims__ has quit IRC12:52
*** dims__ has joined #openstack-keystone12:53
*** kwss has joined #openstack-keystone12:54
*** radez_g0n3 is now known as radez12:55
*** leseb has quit IRC13:01
*** leseb has joined #openstack-keystone13:01
*** gokrokve has joined #openstack-keystone13:02
*** chandan_kumar is now known as chandankumar13:03
*** tkelsey has joined #openstack-keystone13:05
*** Gippa has joined #openstack-keystone13:06
*** gokrokve has quit IRC13:07
*** nkinder_ has quit IRC13:08
*** xianghui has quit IRC13:12
*** stevemar has joined #openstack-keystone13:13
*** hrybacki has joined #openstack-keystone13:17
dolphmmarekd: ideally, barbican!13:19
marekdallright, i am doing some reading on that topic.13:19
marekddolphm: i don know if you had a chance to read k2k specs, but are you okay with dropping saml/oidc in favor of simplyfying thr workflow but creating our own federation-like protocol?13:24
marekdkwss: hey!13:26
marekdkwss: i am not sure if you saw this patch: https://review.openstack.org/#/c/90121/813:26
marekdkwss: maybe lack of that info caused you a headache :(13:27
rodrigodsmarekd, i'm trying to be aware of k2k, are you having meetings in a specified time? or is it more ad-hoc right now?13:28
marekdrodrigods: morganfainberg stevemar dstanek and i discussed once a workflow, but it was  rather an ad-hoc meeting.13:29
*** topol has joined #openstack-keystone13:29
*** xianghui has joined #openstack-keystone13:29
marekdrodrigods: there might one soon, but nothing certain yet.13:29
stevemarrodrigods, yeah, just ad-hoc stuff on -keystone13:30
marekdstevemar: oh, hey stevemar13:30
stevemarmarekd, i'm back today :D13:30
rodrigodsmarekd, stevemar thanks...13:30
* rodrigods reading the last k2k patch13:30
marekdstevemar: since you are here...:-)13:30
stevemarmarekd, i really need to get eyes on that dox bug i filed!13:31
*** joesavak has joined #openstack-keystone13:32
kwssmarekd, I saw it, but I'm not sure determining user ID should be a mapping engine thing :)13:32
*** Gippa has quit IRC13:32
marekdstevemar: because -infra is not fixing it or it;s not them who should fix it?13:33
stevemarmarekd, it's not infra who should fix it13:34
stevemarshould be the doc folks13:34
stevemarlooks like a library they depend on is doing something funny13:34
marekdkwss: i am just thinking about your comment. I think i get the point - you want to use one set of rules to every IdP and I understand why. I also got the impression you want to get rid of per IdP mapping, right?13:34
marekdstevemar: infra, docs, whatever..not keystone, right?13:34
dstanekstevemar: is that the Java stacktrace that I've been seeing?13:35
marekddstanek: also.13:35
kwssmarekd, not necessarily get rid of it completely, as I agree that certain situations would benefit from it, but definitely allowing a global mapping policy as well13:35
marekdkwss: in your spec - are you planning to keep how mapping rules look like? Or the JSON and its structure stays?13:35
marekdkwss: ha! because what I understood was: make one global set of rules, and remove everything else13:36
marekdkwss: e.g. because you don't want to add mapping id when PUTting protocols.13:36
kwssmarekd, the current policy structure is fine, it's more how they are assigned13:37
marekdkwss: ok, how would your rules look like?13:38
kwssmarekd, I guess there are multiple ways to achieve this, we could extend the current functionality to allow for a global policy in addition, or we remove the PUT and give rules a list of IdPs to apply to13:38
stevemardstanek, it sure looks like it eh13:38
marekdkwss: yes, but i think in your spec you are proposing to remove setting mapping ids13:38
kwssmarekd, I don't think they would have to change at all, just make it so that they can be applied without being linked to an IdP13:39
kwssmarekd, you're right, I should update the spec to include both IdP specific and global mappings, I need to check if David has anything to say about this when I meet with him this afternoon, then I'll upload a new patch13:40
marekdkwss: "If I have 100 IdPs configured and all of them issue an email attribute which we map to user: email and an organisation which maps to a *different* group for each IdP then I cannot reuse the policy and must make a new one for each IdP. This results in 100 mappings each with 2 rules (so 200 rules). In this revised version, I make 1 mapping for email and 1 for each IdP specific group, resulting (so 101 rules)"13:40
marekdkwss: that's your comment13:40
marekd:-)13:40
marekdkwss: do you think you could try building a JSON rules you would like to use with let's say 3-4 IdP in the federation?13:41
marekdi can try doing the same.13:41
kwssmarekd, I don't think my comment precludes IdP specific mappings, I'm just explaining how some situations would benefit from a global set of rules too13:42
kwssmarekd, I'll add an example of this to the next patch of the spec13:43
*** leseb has quit IRC13:46
marekdkwss: http://fpaste.org/114992/13:48
marekdkwss: this set of rules should always issue userid as email, and different groups depending on the organisation13:48
marekdhow would the rules change if we were doing mapping like you are proposing?13:49
marekdkwss: sorry, seccond comment should be "mapping to IdP2"13:50
kwssmarekd, The rules would be the same, but we wouldn't have to assign the mapping 100 times13:50
marekdkwss: is it really such a great effort to put extra line since you are already adding the protocol 100 times?13:51
*** thedodd has joined #openstack-keystone13:51
kwssmarekd, and if I later write a new policy?13:52
marekdkwss: new policy == new rule?13:52
marekdkwss: so you PATCH the mapping itself...13:52
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: Add tests without optional create endpoint params  https://review.openstack.org/10322913:53
marekdstevemar: k2k!13:54
dstanekhrybacki: you around?13:54
hrybackidstanek: o/13:55
kwssmarekd, even if this is achievable with the current system, it is still extra work and it doesn't make sense to link attribute mapping to a protocol13:55
dstanekhrybacki: looking at your latest now13:55
stevemarmarekd, k2k is almost there :)13:55
kwssmarekd, the protocol does not determine the semantics of an attribute13:55
hrybackidstanek: I think I messed up the damn import. Again.13:56
marekdkwss: protocol is rather used to letting idp have multiple mapings.13:56
*** miqui has quit IRC13:56
*** nkinder_ has joined #openstack-keystone13:56
marekdkwss: without that how an we solve my PEPSI/COLA example?13:56
dstanekhrybacki: yeah, also is your JSON correct because both new tests have the same values13:56
marekdstevemar: ehhhh, what do we want to have in extended SC?13:56
marekdstevemar: remote Keystones only, right?13:56
kwssmarekd, are pepsi and cola not separate IdPs?13:56
hrybackidstanek:  yep -- it's all dependent on what's being handed to the client.endpoints.create call13:57
dstanekhrybacki: ah, i see13:57
marekdpepsi wants to use my cloud, so does cola. They both issue parameter "DRINK" and both set its value to "SODA". Now, i need map this to PEPSI_SODA project for PEPSI and COCA_SODA for COCA13:58
marekdor cola..whatever13:58
hrybackithat create will post the 'none' for adminurl/internalurl regardless if it gets fed them or not -- just checking to make sure that post is following that rule13:58
marekdso i make independent mappings for COCA and PEPSI and make it work.13:58
marekdhow can i achieve it with global rules, applied for *every* IdP ?13:59
kwssmarekd, and if we maintain IdP specific mappings in addition to global then this is no problem, but they still should not link to any protocol13:59
hrybackidstanek: so uuid (newline) httpretty (2newlines) otherstuff ?13:59
dstanekhrybacki: nope, i'm happy with that13:59
hrybackiokay, cool13:59
marekdkwss: this is what i was not witnessing in the spec :( That this global mapping is addition, not replacement. Also because you  have removed mapping_id from all API calls, which indicates there are no per-IdP mappings.14:00
kwssmarekd, there are multiple ways to do this, to be independent of protocol, we could assign a mapping directly to the IdP, or we could include a list of IdPs to apply to in each rule. I will add this to the next patch but I would like to discuss it with David first.14:02
*** gokrokve has joined #openstack-keystone14:02
marekdkwss: sure. I know there are multiple ways, but I am talking about what i am seeing in the spec and why I am against that way (and hence keeping my -1) :-)14:03
marekdstevemar: ?14:03
kwssmarekd, that's fine, I'll address this issue in the next patch, David is in a meeting but I will be seeing him after and I will make sure the next patch is up in the next few hours :)14:04
marekdstevemar: what did you mean by having step A and A' in the userflow? What is IdP and what is ACME? They are both one Keystone, or IdP is shibboleth IdP?14:05
marekdkwss: sure!14:05
marekdI should be available next 3-4 hours, and later maybe at night14:05
kwssmarekd, I think IdP and ACME refers to a federated IdP configured into keystone and ACME is the keystone?14:06
stevemarmarekd, you got it, idp would be shibboleth14:06
stevemarkwss, yep14:06
*** gokrokve has quit IRC14:07
marekdstevemar: ok, so you are saying we can use icehouse federation as one of authN method for ACME keystone authN14:07
stevemaryeah14:07
*** rodrigods has quit IRC14:07
marekdstevemar: I will leave it up to your decision but I would add a note about that and remove from this diagram. OThewise ppl might get confused, as we are mixing 'federations' here. Especially we also use in k2k bp terms like IdP, but in a different context.14:08
marekdi think some note like "login with local Keystone using all availavle authN methods, including SAML federation" would be fine.14:09
marekdOFC you will be able to make it look more english :P14:09
*** achampion has joined #openstack-keystone14:09
marekdalso SAML federation is clearly beyond of the scope of this bp, so why mention in in one of the most important diagrams14:10
*** rwsu has joined #openstack-keystone14:10
*** erecio has quit IRC14:10
marekdI will be back in 20 minutes.14:11
*** rodrigods has joined #openstack-keystone14:11
*** marekd is now known as marekd|BBL14:11
mhumarekd: concerning my mail, I think I was hitting a bad case of over-engineering and made the pb in my head more complex than it really is. I was worried about external auth support, which is not the scope at all ... this review made me realize the mistake:  https://review.openstack.org/#/c/84071/14:13
mhuanyhow, I'll get to it ASAP14:13
*** kashyap has left #openstack-keystone14:15
*** vhoward- has joined #openstack-keystone14:17
*** leseb has joined #openstack-keystone14:18
*** vhoward- has left #openstack-keystone14:18
*** ukalifon has quit IRC14:18
stevemarmhu, everything work out?14:20
mhustevemar, yeah, I think so14:20
mhubut in any case, should I hit some problems, you'll find me here :)14:20
dstanekhrybacki: re-reading our conversation - yes, change the import - when i said nope i was responding to an earlier comment14:21
*** afazekas has quit IRC14:21
hrybackidstanek: okay, will patch and review in a min14:21
openstackgerritHarry Rybacki proposed a change to openstack/python-keystoneclient: Add tests without optional create endpoint params  https://review.openstack.org/10322914:23
hrybackidstanek: I feel bad for the ci server14:23
stevemarhrybacki, don't worry the CI servers are tough :)14:25
*** gokrokve has joined #openstack-keystone14:26
*** gokrokve_ has joined #openstack-keystone14:27
hrybackistevemar: I'll keep that in mind :P14:27
stevemarmhu, our mail system is down, but i was going to write back ... for OSC we don't have a specs repo, just write a blueprint up in launchpad14:28
mhustevemar, thx14:28
*** henrynash has joined #openstack-keystone14:29
henrynashdstanek: if you’re around, https://review.openstack.org/#/c/102430/ is fixed up wrt your comments...14:29
*** jdennis has joined #openstack-keystone14:29
*** gokrokve has quit IRC14:31
openstackgerritZhi Yan Liu proposed a change to openstack/keystonemiddleware: Expose an entry point to list auth_token middleware config options  https://review.openstack.org/10420814:42
*** gokrokve_ has quit IRC14:43
dstanekhenrynash: +2+A - thanks!14:44
henrynashdstanek: thx14:44
marekd|BBLmhu: aha :-)14:46
*** marekd|BBL is now known as marekd14:47
*** gokrokve has joined #openstack-keystone14:47
*** daneyon has joined #openstack-keystone14:47
*** daneyon has quit IRC14:47
*** daneyon has joined #openstack-keystone14:48
marekdrodrigods: here?14:49
marekdrodrigods: regarding your questions on the k2k bp.14:50
*** Chicago has joined #openstack-keystone14:50
marekdrodrigods: i think we only need Extended Service Catalog consisting of remote Keystones14:50
*** andreaf has quit IRC14:51
marekdnothing more, and this can be easily build from list of registered and enabled SP14:51
marekdService Providers.14:51
rodrigodsmarekd, hmm so maybe the description should change over there?14:51
marekdrodrigods: oh, AFAIR we wanted to do something like /auth/tokens?SC=BETA14:52
rodrigodsmarekd, in which step the user "discovers" BETA?14:53
*** tkelsey has quit IRC14:54
marekdrodrigods: ha good queston. I think it should be either apriori (so somebody told him there is SP BETA), or user should also be able to get full extended SC14:54
marekdwith all available Service providers.14:55
*** dims__ has quit IRC14:55
*** vhoward- has joined #openstack-keystone14:56
rodrigodsmarekd, and this should be triggered after the user decides to burst, right?14:56
marekdwhat this?14:56
marekdrodrigods:^^?14:56
rodrigodsmarekd, maybe I lost some discussion, but in the meeting I was watching, the user would decide that it needs to burst to another cloud, and after that, it would access the external service provider14:57
rodrigodsthe user over there, I mean the client14:57
marekdrodrigods: essentially yes, but in the meantime he would need to ask his local keystone to make that token usable only with BETA14:58
rodrigodsmarekd, ok, so it's clear that the user needs to discover the list of external service providers at some point, right?15:00
rodrigodsmaybe it should be added to the spec15:00
marekdrodrigods: point (B) is not enough?15:00
marekdlinke ~24715:00
*** mclaren has joined #openstack-keystone15:00
marekdline15:00
rodrigodsmarekd, "possible using a query parameter to select an SP." doesn't it mean that it is already sending BETA as query parameter? My point is, when it will even know that BETA exists15:02
marekdrodrigods: or, so this might need to be rephrased. The goal AFAIR was "if you know nothing: get a full SC so you can discover who is available, if you know who you want to use apriori don't fetch full SC"15:03
rodrigodsmarekd, ++15:04
rodrigodsnow it makes sense to me15:04
*** tkelsey_ has joined #openstack-keystone15:07
openstackgerritDolph Mathews proposed a change to openstack/keystone: Ensure that in v2 auth tenant_id matches trust  https://review.openstack.org/10421615:10
*** gokrokve has quit IRC15:10
stevemarmarekd, rodrigods if the user provides no query params, he gets the normal SC, if he provides &allSC or something, he can get all SP endpoints (but not local ones)15:11
*** gokrokve has joined #openstack-keystone15:11
stevemarif the user knows the SP id, he can do &SP=BETA, and get just that one back15:12
stevemari think that would work, but why not always go for allSP15:12
marekdstevemar: i was thinking the same. filtering could be good to not always gets back SC with 50 Keystone endpoints (because there are 50 trusted clouds)15:13
bknudsonthe catalog would get so big that it wouldn't even fit in the token table15:14
marekdbknudson: ++15:16
marekdbknudson: this is uuid only case, right?15:16
*** xianghui has quit IRC15:18
bknudsontokens are stored in the table whether it's uuid or pki15:18
bknudsonso we can get it back on validate15:18
*** packet has joined #openstack-keystone15:19
*** dims__ has joined #openstack-keystone15:23
*** gokrokve has quit IRC15:25
*** dims__ has quit IRC15:27
*** dims__ has joined #openstack-keystone15:27
dolphmstevemar: did canada unplug internet?15:34
stevemarit appears so15:35
stevemarrefresh15:35
joesavakyo stevemar15:37
sbasambknudson/marekd: Can you provide a link to the BP which is proposing the &SP=BETA functionality? It is something we struggle with too.15:38
stevemaryo joesavak15:38
marekdsbasam: https://review.openstack.org/#/c/100023/15:38
openstackgerritZhi Yan Liu proposed a change to openstack/keystonemiddleware: Expose an entry point to list auth_token middleware config options  https://review.openstack.org/10420815:38
sbasamthanks15:38
joesavakso there's some convo about having keystone-only protocol for federation or for k2k dropping saml/oidc...15:38
joesavakgreat for simplicity for k2k, right?15:39
joesavakbut makes it tougher for k2-nonK SP15:39
joesavakex: local cloud horizon needs to federate to ticketing-as-a-service SP15:40
openstackgerritA change was merged to openstack/keystone: Add identity mapping capability  https://review.openstack.org/10243015:40
joesavakthe idea being batted around is that horizon would ask local keysotne for the federation representation of an identity for the ticket-as-a-service SP15:41
joesavakhorizon doesn't need to know saml, oidc, abfab, or anything - it has a token and will ask keystone (the issuer) for a representation of that identity in the federation construct expected by the SP it's federating to15:42
joesavakmake sense?15:42
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/10401815:42
*** afazekas has joined #openstack-keystone15:44
*** chandankumar has quit IRC15:44
marekdjoesavak: yes, as long as protocols will work that way. in most of SAML IdP  implementations you need signed authN request from SP, so IdP knows it is issuing an assertion for a trusted SP.15:44
openstackgerritZhi Yan Liu proposed a change to openstack/keystonemiddleware: Expose an entry point to list auth_token middleware config options  https://review.openstack.org/10420815:45
marekdjoesavak: so the client is having good 'old' federation.15:45
tristanCHello folks, we are in the process of publishing and OSSA for https://bugs.launchpad.net/ossa/+bug/1331912. Though stable/havana just failed check-devstack-dsvm-cells. Yet it seems not related...15:45
uvirtbotLaunchpad bug 1331912 in keystone "[OSSA 2014-022] V2 Trusts allow trustee to emulate trustor in other projects (CVE-2014-3520)" [High,In progress]15:45
tristanClogs are: https://jenkins02.openstack.org/job/check-devstack-dsvm-cells/8105/consoleFull15:45
*** leseb has quit IRC15:46
*** leseb has joined #openstack-keystone15:46
*** leseb has quit IRC15:46
*** leseb has joined #openstack-keystone15:47
boris-42jamielennox hi there15:47
boris-42jamielennox I merged patch to osprofiler https://github.com/stackforge/osprofiler/commit/bb9c01e0dd87e6166d3076921a0ef137c5efd75615:47
boris-42jamielennox didn't yet publish new version15:47
boris-42jamielennox cause some more changes are going to be in lib15:47
stevemarjoesavak, as i understand, you are meeting jorge in 10 minutes, he will re-cap you!15:53
*** richm has joined #openstack-keystone15:53
*** hrybacki_ has joined #openstack-keystone15:54
joesavakthanks stevemar15:56
*** hrybacki has quit IRC15:57
*** jsavak has joined #openstack-keystone15:57
*** hrybacki_ has quit IRC15:58
*** daneyon_ has joined #openstack-keystone15:59
*** joesavak has quit IRC16:00
dstanekdolphm: token binding question...if i exchange a token for another more finely scoped token would i still have to provide an additional factor?16:00
*** daneyon has quit IRC16:02
*** gyee has joined #openstack-keystone16:03
*** gokrokve has joined #openstack-keystone16:06
dolphmdstanek: with binding, yes. binding doesn't have any impact on scope16:07
*** daneyon_ has quit IRC16:07
morganfainbergdolphm, ++16:13
dstanekdolphm: but the resulting scoped token will not need binding right?16:13
morganfainbergbknudson, if i address the two comments you have in jamielennox's privatize review we'd be good to merge it, right?16:14
*** BAKfr has quit IRC16:14
dolphmdstanek: i think it should maintain the requirement for a binding so that it avoids becoming a bearer token; why are you thinking otherwise?16:15
dstanekdolphm: i'm thinking (user presents token + factor to nova) -> (nova uses that to create a token for another service)16:15
bknudsonmorganfainberg: if it gets middleware released then that's fine by me16:15
morganfainbergbknudson, ok i'm addressing them now16:16
bknudsonbut I don't know why jamielennox made the change.16:16
bknudsonwas it required due to the change to the names?16:16
dstanekdolphm: so when nova goes to use the token to get an images for the user it won't have the additional factor16:16
*** jsavak has quit IRC16:17
dolphmdstanek: that's a good question. i don't have an answer... (cc- ayoung jamielennox)16:17
*** hrybacki has joined #openstack-keystone16:18
dolphmdstanek: i'd imagine some bypass mechanism (like trusting nova's signature regardless of token binding), but that sounds like a great attack vector :(16:18
* dolphm runs to grab food16:19
*** hi_every_body has joined #openstack-keystone16:20
morganfainbergbknudson, shouldn't have been required16:21
morganfainbergbknudson, i'm looking at the exception change16:21
morganfainbergthe message change meh16:21
*** marekd is now known as marekd|away16:21
*** jaosorior has quit IRC16:22
*** hrybacki has quit IRC16:22
*** kwss has quit IRC16:25
dolphmmorganfainberg: we need both the privatize changes to land, i assume?16:25
morganfainbergdolphm, ideally yes16:26
morganfainbergdolphm, which is why i'm working on them now16:26
*** daneyon has joined #openstack-keystone16:27
dolphmmorganfainberg: can they either be squashed together or made parallel?16:27
morganfainbergdolphm, easy to squash them.16:27
morganfainbergdolphm, i was worried parallel would conflict since we touched some of the same code.16:28
*** hi_every_body has quit IRC16:28
morganfainbergi'll squash + co-author it16:28
*** ukalifon has joined #openstack-keystone16:28
dolphmmorganfainberg: it's one line in auth_token changing an import16:28
dolphmmorganfainberg: imports aren't touched in the other patch16:29
morganfainbergdolphm, ah right, was tired last night16:29
morganfainbergdolphm, easy either way16:29
bknudsonlooks like the server doesn't actually support setting the response content-type16:30
bknudsonand the tests don't support having a response content-type different than the request content-type16:30
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10403716:30
dolphmbknudson: what are you trying to set the response type to?16:31
bknudsonapplication/json-home16:31
dolphmbknudson: without the client requesting application/json-home?16:31
bknudsonalso, oauth tries to set the response to application-x-www-urlformencoded16:31
morganfainbergdolphm, ^ split from being dependent16:31
dolphmmorganfainberg: cool16:31
bknudsonthe client requests application/json-home in the Accept header, not content-type16:31
bknudsonalthough it's a get request so there's no content in the request16:32
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10402716:32
*** david-lyle has joined #openstack-keystone16:32
morganfainbergbknudson, ^ jamie's without the two changes you commented on.16:32
bknudsonbut a client could potentially POST application/json and accept xml16:32
morganfainbergbknudson, i don't see why those were made, we can chain them on separately if they are absolutely needed16:33
dolphmbknudson: right... so i guess i'm lost on what's breaking with Accept: application/json-home + Content-Type: application/json-home16:33
*** leseb has quit IRC16:34
bknudsondolphm: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/wsgi.py#n61116:34
bknudsonrender_response always adds a Content-Type: application/json16:34
*** leseb has joined #openstack-keystone16:34
dolphmbknudson: made that an optional kwarg?16:34
bknudsondolphm: y, but then the problem is that the tests don't support having a different response type...16:35
dolphmbknudson: if the controller calls render_response itself, the wsgi module won't do it again16:35
dolphmbknudson: ooooh16:35
bknudsonanyway, it's just trickier than I thought it would be.16:35
bknudsonI think oauth is "broken" in that it doesn't have the right content-type.16:35
dolphmbknudson: they always call assertValidResponse or something.... maybe extend RestfulTestCase or whatever and override that method?16:35
dolphmbknudson: i assume you have a new test module that only tests json home responses?16:36
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Service Tokens are really a middleware specification  https://review.openstack.org/10425716:36
bknudsondolphm: eventually will. oauth1 will need the same fix16:36
bknudsondolphm: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/rest.py#n16616:37
bknudsonthat check fails if response content-type isn't 'json'16:38
bknudsonself.content_type is 'json'16:38
bknudsonso maybe can pass in the response content type where restful response is getting done16:38
bknudsonexpected response content type16:39
dolphmbknudson: in, so application/json works (and application/json-home should work then too?)16:39
*** leseb has quit IRC16:39
bknudsondolphm: y, I don't think that will be the problem.16:39
bknudsonbut if I fix render_response to support setting the response content-type then oauth tests fail16:40
bknudsonbecause oauth tests set x-www-urlformencoded16:40
bknudsonI don't know if the requests are x-www-urlformencoded... can try setting that in the oauth tests.16:40
dolphmbknudson: that seems right for at least one oauth response iirc... stevemar?16:40
*** rodrigods has quit IRC16:43
*** marcoemorais has joined #openstack-keystone16:43
*** thedodd has quit IRC16:44
stevemarbknudson, dolphm IIRC the responses should be x-www-urlformencoded16:45
*** marcoemorais has quit IRC16:45
*** rodrigods has joined #openstack-keystone16:45
stevemarthe requests, I'm not sure16:45
*** marcoemorais has joined #openstack-keystone16:45
bknudsonstevemar: is that what the server actually sends back?16:46
stevemarbknudson, it should be, i think we over-ride it16:46
*** bobt has joined #openstack-keystone16:46
stevemarbknudson, The HTTP request entity-header includes the "Content-Type"16:48
stevemar header field set to "application/x-www-form-urlencoded".16:48
*** marcoemorais1 has joined #openstack-keystone16:48
stevemarthat probably happens under the covers with oauthlib16:49
bknudsonstevemar: that's the request?16:49
bknudsonstevemar: is that what the tests do, too?16:50
*** marcoemorais has quit IRC16:50
*** zhiyan is now known as zhiyan_16:50
*** daneyon has quit IRC16:50
*** daneyon has joined #openstack-keystone16:51
*** zhiyan_ is now known as zhiyan16:51
bknudsondoesn't look like client.sign(self.base_url + endpoint, ...) sets Content-Type16:52
*** harlowja_away is now known as harlowja16:52
*** tkelsey_ has quit IRC16:52
bknudsonI don't see the tests setting the Content-Type to x-www-form-urlencoded ... _get_oauth_token sets application/json16:53
bknudsonhttp://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/test_v3_oauth1.py#n8016:53
bknudsonwhich is doing /auth/tokens anyways16:53
*** Chicago has quit IRC16:53
bknudsonthe rest don't have a body16:53
stevemarbknudson, i feel like the request is done properly by by oauthlib (in the tests)16:55
*** jamielennox is now known as jamielennox|away17:02
morganfainbergoh Jul4th is friday17:02
morganfainberghaha17:02
* morganfainberg just realized why everyone was saying "Have a good holiday weekend"17:03
* morganfainberg facepaws. https://i.chzbgr.com/maxW500/3739566080/hFC30F272/17:03
morganfainbergdolphm, you really like your BRZ right?17:04
morganfainbergdolphm, has it been reliable overall?17:04
dolphmmorganfainberg: *love* and 100% reliable...17:04
morganfainbergdolphm, i'm looking at ditching my S4 (so pricy)17:04
*** leseb has joined #openstack-keystone17:04
dolphmmorganfainberg: it's underpowered, but that just means you can drive at ten tenths all the time17:04
morganfainbergdolphm, brz (or frs, same car, which ever dealer gives a better deal on it) - is on the list i'm considering17:05
morganfainbergdolphm, but i figure i can save > $300/mo by switching cars.17:05
dolphmmorganfainberg: it has no grip. oil changes are dead easy. google for "brz/fr-s chirp" <-- a problem a lot of people had including me, but mine went away at about 10k miles17:05
morganfainbergso. shoudl do it :)17:06
morganfainbergdolphm, good to know, will check it out :)17:06
dolphmmorganfainberg: you're going to be dissapointed by the power different coming from an s417:06
*** joesavak has joined #openstack-keystone17:06
dolphmmorganfainberg: just make up for it with more sideways17:06
morganfainbergdolphm, i will be disappointed by _anything_ in that light. but I don't ever drive now17:06
morganfainbergdolphm, i mean i think i avg. 45mi /wk on a big week of driving17:07
morganfainbergmost weeks are closer to 017:07
dolphmmorganfainberg: wow, i do that every day17:07
morganfainbergyeah, no need to spend lots of $ on a car I'm not using.17:07
*** zhiyan is now known as zhiyan_17:08
dolphmmorganfainberg: fr-s has a looser rear-end from the factor, for whatever that's worth17:09
dolphmfactory*17:09
morganfainberggood to know17:09
morganfainberghaven't driven the fr-s yet, planning on going to look at cars this weekend now that I know it's the 4th of july17:09
*** leseb has quit IRC17:09
dolphmmorganfainberg: lol. when you do, *hold* the left fun button down for like 5 seconds to disengage traction control and stability control. abs requires pulling a fuse17:11
openstackgerritBob Thyne proposed a change to openstack/keystone: Ending periods in exception messages deleted  https://review.openstack.org/10385217:11
morganfainbergLOL17:11
morganfainberggood to know17:11
dolphmmorganfainberg: http://www.zetaproducts.net/images/products/detail/16.frs.plaque.1.jpg17:11
dolphmmorganfainberg: TC off only stays off for like 15 seconds if you just push it. VSC sport just increases the threshold for stability control, but it still kicks in too early... unless maybe it's wet out17:12
*** hrybacki has joined #openstack-keystone17:13
*** leseb has joined #openstack-keystone17:13
*** praneshp has joined #openstack-keystone17:14
raildomorganfainberg: ping17:19
morganfainbergraildo, pong17:19
raildomorganfainberg: I can bother you with my problems about inherited roles now? = P17:20
morganfainbergraildo, absolutely17:20
morganfainbergraildo if we get too deep in i might ask for a coffee break, but otherwise i'm good.17:20
raildohahaha ok17:20
raildoI was discussing at the meeting of hierarchical multitenancy about inherited roles, and we noticed two possible modifications required in the current implementation:17:21
raildo1- Currently the inherited role is applied to a domain and is expanded to all projects associated with this domain, I believe that it should be possible to a role be inherited only a part of the hierarchy. for example: I have a hierarchy: domain1.projA.projB.projC, I would like a role that was associated with projB was inherited to projC, but that will not happen. I have to apply to the role projB for domain1 and all projects (up to the17:21
raildo2- It would be possible to create "private project"? Ie, a inherited role is throughout the hierarchy, but I wish that a role does not have access to a specific project. Is this acceptable?17:22
*** amcrn has joined #openstack-keystone17:23
morganfainbergraildo, we actually talked about this at the summit17:23
morganfainbergraildo, i think we said that a project would have a "no-inherit flag" and anything under that project would get no inheritance from above it17:24
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421417:24
morganfainbergraildo, but nothing prevents that project from providing inheritance for roles to it's children again17:24
raildook17:25
morganfainbergraildo, and i actually like that model a lot. it lets us handle the reseller use case17:26
morganfainbergraildo, which was a big part of that discussion17:26
raildothis was my question, looking for a good way to work with resellers.17:27
morganfainbergraildo, there ya go, generally speaking the keystone team seemed to like that approach, where the project would prevent inheritance from above, but could provide inheritance to it's children17:29
*** leseb has quit IRC17:30
*** leseb has joined #openstack-keystone17:31
raildosounds good to me17:32
raildomorganfainberg: and in relation to a private project, the project may prohibit his father to access it?17:33
morganfainbergraildo, the private project would prevent all inheritance, if a user needs access to the private project (or it's children) an explicit role will need to be granted to that user17:34
morganfainbergraildo, this doesn't stop a cloud admin from doing administrative stuff as needed.17:35
*** leseb has quit IRC17:35
morganfainbergraildo, but explicit grants would be needed on the private project, just like any other project would work.17:36
morganfainberg(non inherited)17:36
morganfainbergbknudson, mind re +2ing https://review.openstack.org/#/c/104037/17:37
bknudsonmorganfainberg: oh, it's split out that's why I couldn't find it17:41
*** dstanek is now known as dstanek_lunch17:41
morganfainbergbknudson, hehe yeah17:41
bknudsonwish we had tests for ec2_token17:42
bknudsonI'm not going to +2 it.17:42
raildomorganfainberg: yes i agree with you but what was discussed was: a project has a role inherited to a child, but for some reason, I want this parent project (inheritable) has no access to child project. Ie disable the  inherited role  for a  specif project.17:42
morganfainbergraildo, what is that use-case17:43
morganfainbergraildo, i am concerned it will get too complex if we explicitly need to list "roles that can or can't inherit" to this specific project17:44
bknudsonmorganfainberg: had a couple of comments on https://review.openstack.org/#/c/104037/17:44
morganfainbergraildo, rather than a hard "no inheritance from parents" and just assign explicit grants across.17:44
morganfainbergbknudson, damn it, i thought i fixed those :P17:45
morganfainbergbknudson, yeah bad search/replace on iniital pass17:45
morganfainbergbknudson, thanks!17:45
*** leseb has joined #openstack-keystone17:45
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10403717:47
dolphmbknudson: i reviewed the first patch by just making sure that every change was just adding underscores to stuff #fail17:49
*** openstackgerrit has quit IRC17:49
dolphmand that unit tests passed :)17:49
*** openstackgerrit has joined #openstack-keystone17:49
dolphmfirst time i've run tests on openstack/keystonemiddleware :D17:49
*** leseb has quit IRC17:50
bknudsonI'm not looking forward to rebasing my refactoring changes, but it should be obvious what the change is17:50
raildomorganfainberg: The use case I see for this is. I have a company that will be a sub-project of a hierarchy. For some NDA, a parent project should not access this project. So even this project has a role inherited from father to other children, he can not access this project.17:51
morganfainbergraildo, i'm not seeing the value add where you wouldn't just use the no-inherit flag17:52
morganfainbergraildo, there is no reason you couldn't have multiple uses of no-inherit in the tree17:53
morganfainbergraildo, W -> X -> Y (no inherit, X's roles don't inherit to Y) -> Z -> Q (no inherit, Z's roles don't inherit to Q) -> R17:54
morganfainbergraildo, the way i see it is a "private / no-inherit flagged" project inherits nothing from above it.17:54
*** marcoemorais has joined #openstack-keystone17:55
*** marcoemorais has quit IRC17:56
*** marcoemorais has joined #openstack-keystone17:56
dolphmmorganfainberg: project.private = True17:58
morganfainbergdolphm, ++17:58
*** marcoemorais1 has quit IRC17:58
*** daneyon_ has joined #openstack-keystone17:59
*** daneyon has quit IRC18:01
dolphmmorganfainberg: raildo: stopping RBAC going down the hierarchy at private projects seems intuitive, but the sharing of resources owned by projects high in the hierarchy is a more interesting question IMO.18:02
bknudsonstevemar: the oauth response in the tests makes no sense to me... the content-type is 'application/x-www-urlformencoded', but then it looks like it returns a JSON string with the url params18:02
dolphmmorganfainberg: raildo: can a glance image owned by the a parent project be used by all projects in the underlying hierarchy, regardless of privacy?18:02
bknudson'"oauth_token=687262bff3e9480cac7f3f08ffb5afa6&oauth_token_secret=a3b4d9a87e214b7fa2635b219c8fe18b&oauth_expires_at=2014-07-03T02:01:13.417012Z"'18:03
dolphmbknudson: is that formencoded and then json encoded?18:04
morganfainbergdolphm, very good question, don't remember if we covered that18:04
bknudsondolphm: that's what it looks like18:04
bknudsonI don't know how to use oauth on keystone, otherwise I'd try it18:04
bknudsonI'm just looking at the tests18:05
stevemarbknudson, sec, looking something up18:05
dolphmbknudson: i got in touch with another group of folks from fidelity mutual that have implemented hierarchical multitenancy before... and were looking to get the same out of openstack18:05
dolphmerr morganfainberg: ^18:05
*** packet has quit IRC18:06
stevemarbknudson, so it's set here: https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/controllers.py#L22518:06
bknudsonstevemar: the problem is that render_response overrides it18:06
bknudsonstevemar: http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/wsgi.py#n60918:07
bknudsonI don't know what's supposed to happen if you have 2 Content-Types in the headers.18:08
*** jdennis has quit IRC18:08
stevemarbknudson, you said that you're not even seeing the urlencoded one anyway?18:09
*** jdennis has joined #openstack-keystone18:09
bknudsonstevemar: the response has '"oauth_token=687262bff3e9480cac7f3f08ffb5afa6&oauth_token_secret=a3b4d9a87e214b7fa2635b219c8fe18b&oauth_expires_at=2014-07-03T02:01:13.417012Z"'18:10
bknudsonstevemar: I think we were discussing the request content before.18:10
raildodolphm: Actually I'm not advocating this idea at the meeting were discussing this idea if it would be possible to create a private project, so I wanted to bring here, to know your opinions.18:10
stevemarbknudson, right.18:11
raildoBut I believe if I determine that a project is private. It should work as it was not part of the hierarchy. therefore, this glance image is not inherited.18:11
bknudsonstevemar: I'd expect a urlencoded response to be oauth_token=687262bff3e9480cac7f3f08ffb5afa6&oauth_token_secret=a3b4d9a87e214b7fa2635b219c8fe18b&oauth_expires_at=2014-07-03T02:01:13.417012Z18:11
bknudsonnot "oauth_token=687262bff3e9480cac7f3f08ffb5afa6&oauth_token_secret=a3b4d9a87e214b7fa2635b219c8fe18b&oauth_expires_at=2014-07-03T02:01:13.417012Z"18:12
bknudsonthere shouldn't be quotes around it18:12
stevemarbknudson, we could change render response, or just use webob.Response at the oauth controller level18:13
bknudsonstevemar: I'm working on changing render_response to not set the content-type if it's already set... maybe webob.Response is the better way to go18:14
bknudsonbecause render_response will also JSON-encode18:14
bknudsonbut this is a change to the oauth response if it's not going to put "" around the response18:14
stevemarbknudson, yeah, would have to change some client code18:15
bknudsonok, so you think it's correct to not have "" around the response body? If so I'll fix it since I'm looking at the code anyways18:15
*** hrybacki has quit IRC18:16
stevemarbknudson, i believe thats the way to go, render_response was over-riding it18:17
bknudsonstevemar: ok, I'll keep working on it18:18
stevemarbknudson, i'll make some changes to api-spec and client, did you open a bug?18:18
bknudsonstevemar: I didn't open a bug18:18
bknudsonthe api-spec says it returns a string?18:19
bknudsona JSON string?18:19
*** packet has joined #openstack-keystone18:19
dolphmraildo: that's my intuition as well... but the use cases seem to get complicated enough that we need to consider that to be an option :(18:20
dolphmraildo: we also talked about the parent project's visibility into the resources consumed by a private child hierarchy... like, the parent project should be able to see aggregated quota, for example, but not specifics18:22
raildodolphm: ++18:22
raildodolphm: one guy on CERN is Implementing this part of quotas (and its visibility) in Nova. So far it seems to me is being well implemented.18:25
bknudsonstevemar: the spec looks correct -- https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-oauth1-ext.md#supported-signature-methods-hmac-sha1-118:26
bknudsonLooks like policies also has an issue with content-type in response.18:32
stevemarbknudson, yay not alone!18:34
bknudsonnobody uses policies though18:34
*** dims__ has quit IRC18:37
*** jsavak has joined #openstack-keystone18:40
rodrigodsanyone has thoughts about http://lists.openstack.org/pipermail/openstack-dev/2014-July/039115.html? =)18:41
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10403718:42
dolphmrodrigods: i've read it, but i was sort of confused about why domain-level role inheritance to projects didn't already solve the problem - or maybe i'm misunderstanding the use case?18:43
*** joesavak has quit IRC18:44
*** joesavak has joined #openstack-keystone18:44
*** jsavak has quit IRC18:47
*** dims__ has joined #openstack-keystone18:47
morganfainbergdolphm, i swear we're going to get middleware out the door :P18:48
*** hrybacki has joined #openstack-keystone18:50
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421418:52
*** dstanek_lunch is now known as dstanek_lunch_zz18:55
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: Simplified Mapping for Federated Authentication  https://review.openstack.org/10028018:56
*** harlowja is now known as harlowja_away18:59
*** dstanek_lunch_zz is now known as dstanek18:59
openstackgerritKristy Siu proposed a change to openstack/keystone-specs: reengineered-federation  https://review.openstack.org/10430119:00
*** harlowja_away is now known as harlowja19:03
*** marcoemorais has quit IRC19:04
*** marcoemorais has joined #openstack-keystone19:05
*** marcoemorais has quit IRC19:05
*** marcoemorais has joined #openstack-keystone19:05
dstanekstevemar: are you still looking into the dox thing?19:09
stevemardstanek, i've alerted the necessary folk19:09
stevemardstanek, they are all over it19:09
dolphmmorganfainberg: some day! do we have any reason to wait until next week, at least to default to keystonemiddleware everywhere?19:11
*** designated has joined #openstack-keystone19:12
dolphmmorganfainberg: i.e. release this week, and then wait to use it beginning of next week?19:12
dolphmis there a newer reference for this somewhere? https://wiki.openstack.org/wiki/LoggingStandards19:12
morganfainbergdolphm, well we need to still get it into global reqs19:12
designatedI asked in #openstack-ceilometer but no one is active.  Anyone aware of an auth issue with ceilometer-api 2014.1-0ubuntu1.1?  just getting the following in ceilometer-api.log WARNING keystoneclient.middleware.auth_token [-] Unable to find authentication token in headers.  I have verified configuration is correct multiple times, even recreated the user in keystone.  All other services are authenticating just fine against keyst19:12
designatedone.19:12
dolphmdesignated: do you have auth_token in your middleware pipeline twice or something?19:13
designateddolphm, doubtful, but I will check.19:13
morganfainbergdolphm, i figure we release today, get it into global reqs and push on the making it the default (propose changes/get bknudson's changes check/gate) next week19:14
morganfainbergerm, global reqs this week19:14
*** nkinder_ has quit IRC19:14
*** leseb has joined #openstack-keystone19:14
morganfainbergother changes next week / beyond19:14
bknudsonI'll have to rebase my changes on the proposal bots19:15
afaranha1About the inherited_to_projects options in keystone, is there any example on how to use it?19:15
dolphmmorganfainberg: ++19:15
afaranha1I'm trying to use it but it's not working19:15
dolphmafaranha1: how are you testing whether it's working or not?19:16
afaranha1dolphm:  I enabled the [os_inherit], than created a new domain, a project in this domain, a user in this project and domain and a role19:17
designateddolphm, if you're referring to the [keystone_authtoken] section, there is only one.  I followed this guide: http://docs.openstack.org/icehouse/install-guide/install/apt/content/ceilometer-install.html19:17
dolphmdesignated: can you share your ceilometer paste ini?19:17
afaranha1after I assign the user to the domain with the  role created19:17
afaranha1than the user to project19:18
dstanekstevemar: cool, that saves me from setting up a doc environment again19:18
bknudsonafaranha1: I think there's a config option to enable ti19:18
afaranha1after this I log as the new user and run the command: PUT localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects19:18
afaranha1bknudson: Yes, in keystone.conf, I enabled the inherit to true,  "[os_inherit] \n enabled = true"19:19
dolphmafaranha1: instead of assigning a role to the user on the domain, you only need to make the PUT call that you just pasted19:19
dolphmafaranha1: but that wouldn't break anything (it's just not necessary)19:20
designateddolphm, there is no ceilometer paste ini, only ceilometer.conf19:20
afaranha1and restart the keystone, but the table "assignment" keep the value 0 in the "inherited" column19:20
dolphmafaranha1: you do need to set [os_inherit] enabled=true in keystone.conf19:20
dolphmdesignated: does ceilometer.conf have pipeline configuration?19:21
afaranha1dolphm: I set it, and also restarted keystone service19:21
dolphmdesignated: the github source has a paste config https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/api_paste.ini19:21
dolphmdesignated: you might have it setup differently, i suppose?19:22
dolphmafaranha1: alright, then you just need to request a token for any project in that domain. you should receive the role inherited from the domain in the resulting token19:22
designateddolphm, there is a pipeline.yaml but nothing about authentication in there19:22
bknudsonstevemar: did you open a bug for the OAuth 1 response content type? If not I'll open one19:22
openstackgerritAndreas Jaeger proposed a change to openstack/identity-api: Update to clouddocs-maven-plugin 2.1.1  https://review.openstack.org/10431019:23
designateddolphm, i followed the most current guide: http://docs.openstack.org/icehouse/install-guide/install/apt/content/ceilometer-install.html.  everything is configured in ceilometer.conf19:23
dolphmdesignated: i'm looking at that file now... i have *no* idea what that is for, but i'm not too familiar with ceilometer19:23
dolphmdesignated: that's definitely not a paste pipeline19:23
dolphmdesignated: is there a [pipeline:main] in your ceilometer.conf ?19:24
afaranha1The problem is that I don't receive it. I receive an empty list when running: GET localhost:35357/v3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/inherited_to_projects , also in mysql the table "assignment" has all its values in column "inherited" set to 0.19:24
stevemarbknudson, https://bugs.launchpad.net/keystone/+bug/133691019:25
uvirtbotLaunchpad bug 1336910 in keystone "oauth1 response content type" [Undecided,New]19:25
bknudsonthanks!19:26
designateddolphm, no19:26
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Modify oauth calls to expect urlencoded responses  https://review.openstack.org/10432019:27
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix OAuth1 to not JSON-encode create access token response  https://review.openstack.org/10432119:27
stevemarbknudson, just uploaded mine too ^19:28
bknudsonstevemar: can you try out the fixed client with my change?19:29
stevemarbknudson, mmm, sure let me try, leaving in a bit, but if i don't finish setting everything up i'll continue at night19:30
bknudsonno problem19:30
*** sigmavirus24 has joined #openstack-keystone19:31
bknudsonstevemar: https://bugs.launchpad.net/keystone/+bug/1336910 -- kind of weird that it assigned keystone to me for your change to keystoneclient19:33
uvirtbotLaunchpad bug 1336910 in keystone "oauth1 response content type" [Undecided,New]19:33
*** dims__ has quit IRC19:33
stevemarbknudson, hmph, that is weird19:34
* stevemar shrugs19:34
*** leseb has quit IRC19:38
*** leseb has joined #openstack-keystone19:38
rodrigodsdolphm, regarding what said about the email.... yeah... i think we need to think more about it (to stand up for or to abandon) =)19:39
*** hrybacki has quit IRC19:42
*** leseb has quit IRC19:43
*** dims has joined #openstack-keystone19:44
morganfainbergbknudson, dolphm, https://review.openstack.org/#/c/104037/ just cleared check, should be good to go19:46
morganfainbergdolphm, we might need https://review.openstack.org/#/c/104208/ before we release too19:48
*** dims_ has joined #openstack-keystone19:48
*** praneshp has quit IRC19:49
*** leseb has joined #openstack-keystone19:49
*** dims has quit IRC19:49
*** marcoemorais has quit IRC19:52
*** marcoemorais has joined #openstack-keystone19:52
*** praneshp has joined #openstack-keystone19:54
*** dims_ has quit IRC19:54
*** dims has joined #openstack-keystone19:54
openstackgerritChristian Berendt proposed a change to openstack/python-keystoneclient: Calculate a suitable column width for positional arguments  https://review.openstack.org/9787319:58
*** dims_ has joined #openstack-keystone19:58
*** mberlin has quit IRC19:59
*** dims has quit IRC20:00
*** marcoemorais has quit IRC20:01
*** marcoemorais has joined #openstack-keystone20:02
*** marcoemorais has quit IRC20:02
*** marcoemorais has joined #openstack-keystone20:02
*** marcoemorais has quit IRC20:03
*** marcoemorais has joined #openstack-keystone20:03
dstanekmorganfainberg: is your work to get Keystone behind Apache in devstack up for review?20:04
morganfainbergdstanek, https://review.openstack.org/#/c/101611/ is needed20:04
*** joesavak has quit IRC20:04
morganfainbergdstanek, https://review.openstack.org/#/c/104026/ [and tempest fixes (not done yet, pendin g ML topic)]20:05
*** dims_ has quit IRC20:05
morganfainbergdstanek, and then https://review.openstack.org/#/c/100747/20:05
*** marcoemorais has quit IRC20:05
*** joesavak has joined #openstack-keystone20:05
dolphmmorganfainberg: that breaks APACHE_ENABLED_SERVICES?20:05
*** marcoemorais has joined #openstack-keystone20:05
morganfainbergdolphm, APACHE_ENABLED_SERVICES is gone20:06
morganfainbergdolphm, each service goes back to it's own toggle20:06
*** jsavak has joined #openstack-keystone20:06
dolphmmorganfainberg: what's the benefit of that specific change?20:06
morganfainbergdolphm, it lets us control from devstack-gate more easily the services gated under apache20:06
*** dims has joined #openstack-keystone20:06
morganfainbergdolphm, it also makes it so someone setting APACHE_ENABLED_SERVICES=swift doesn't break keystone's deployment20:07
morganfainbergbecause they forgot the +20:07
morganfainbergor a comma20:07
morganfainbergdolphm, there is also a global that tells devstack 'use apache for any services that perfers to run under mod_Wsgi'20:09
*** harlowja is now known as harlowja_away20:09
dstanekvery, cool - just grabbed all of the patches - thanks morganfainberg20:09
*** joesavak has quit IRC20:10
morganfainbergdstanek, sure thing.20:10
morganfainbergdstanek, don't try and run tempest on the keystone one :P it will fail in ~3 trust checks looking for a 20420:10
*** thedodd has joined #openstack-keystone20:10
dstanekmorganfainberg: i'm ok the just 3 failures - i'm sure i'l cause much more as i muck around20:10
morganfainbergdstanek, hehe20:11
morganfainbergdolphm, dstanek, I'll start proposing the fixes for tempest next week if the ML doesn't seem too upset about it. unless there is a reason not to change 204 -> 200 in those cases20:13
bknudsonmorganfainberg: that tempest change is going to be complicated since it has to support old releases, too20:13
morganfainbergbknudson, tempest has gone branchless?20:13
bknudsony20:13
*** radez is now known as radez_g0n320:13
dstanekbknudson: really?20:13
morganfainbergbknudson, then we will just need to accept 204 or 200 in that case20:13
morganfainbergbknudson, both are legitimately valid then20:14
bknudsonsdague didn't like it when I tried that earlier20:14
bknudsonbut we didn't have branchless tempest then20:14
morganfainbergi'll fight that with him when he complains :)20:14
*** mberlin has joined #openstack-keystone20:15
morganfainbergand tempest failed... for middleware merge *grumble*20:15
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Expose an entry point to list auth_token middleware config options  https://review.openstack.org/10420820:15
dstanekdo you know what release you are running against so you can make the checks more precise? morganfainberg bknudson20:15
bknudsonI'm not sure but I think tempest will know the release20:16
bknudsonit's got all sorts of options20:16
bknudsonso there could be a specific option for whether it has this bug fix or not20:16
dstaneki wonder what the record is for +1s before and +2s20:17
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Expose an entry point to list auth_token middleware config options  https://review.openstack.org/10420820:21
openstackgerritMorgan Fainberg proposed a change to openstack/keystonemiddleware: Expose an entry point to list auth_token middleware config options  https://review.openstack.org/10420820:23
morganfainbergbknudson, ^ should solve your comment on the tests20:24
morganfainbergdolphm, the 2 approved make stuff private in middleware and that one ^ should be the last of what is needed bfefore we can release20:25
bknudsonmorganfainberg: thanks!20:26
*** achampion has quit IRC20:30
stevemarbknudson, OK, verified it, it looks solid20:33
stevemarbknudson, i noticed one thing funny though, i couldn't run it under apache, the oauth headers were all garbled up20:33
stevemarjust flat out missing20:33
dolphmstevemar: which headers?20:34
stevemardolphm, the ones generated by oauthlib20:34
bknudsonawesome, thanks!20:35
* morganfainberg is off to get breakfast^wlunch^late lunch20:35
*** harlowja_away is now known as harlowja20:39
dolphmmorganfainberg: odd... python setup.py develop is failing in keystonemiddleware for me, but install -> develop works20:39
*** topol has quit IRC20:40
morganfainbergdolphm, *blink*20:40
morganfainbergdolphm, really?20:40
dolphmhttp://pasteraw.com/h9c4xhu31yid18vzvcifgyh5nkkh2x920:40
dolphmmorganfainberg: ^20:40
bknudsonworked for me20:41
morganfainbergwheels20:41
dolphmmorganfainberg: full log with develop -> install -> develop http://pasteraw.com/au716v3kh8qtf0hlyha4zo1r91r5r8r20:41
bknudsonSearching for six==1.7.220:41
bknudsonI got six==1.7.2 not 1.7.320:41
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes a Python3 syntax error  https://review.openstack.org/10273420:42
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds several more test modules that pass on Py3  https://review.openstack.org/10273520:42
openstackgerritDavid Stanek proposed a change to openstack/keystone: Adds a fork of python-ldap for Py3 testing  https://review.openstack.org/9582720:42
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes test_exceptions.py for Python3  https://review.openstack.org/10273720:42
openstackgerritDavid Stanek proposed a change to openstack/keystone: Fixes test_wsgi for Python3  https://review.openstack.org/10273620:42
morganfainbergyeah the issue is six 1.7.3 is wheels i think20:42
morganfainbergpip handles this fine20:43
morganfainbergsetup develop doesn't20:43
dolphmoooh20:43
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix OAuth1 to not JSON-encode create access token response  https://review.openstack.org/10432120:43
morganfainbergdolphm, pip install -e .20:43
morganfainbergdolphm, -e does the same as develop20:43
dolphmmorganfainberg: that worked20:43
bknudsonstevemar: ^ should fix the pep8 issues20:43
dolphmmorganfainberg: in a new venv20:43
morganfainbergyep. i ran into the same issue with a clean venv you were having20:44
*** stevemar has quit IRC20:47
*** nkinder_ has joined #openstack-keystone20:50
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: JSON Home  https://review.openstack.org/9735920:53
*** dims has quit IRC20:55
*** hrybacki has joined #openstack-keystone20:58
*** henrynash has quit IRC20:59
*** dims has joined #openstack-keystone21:00
*** mrda_away is now known as mrda21:02
*** gokrokve has quit IRC21:06
*** arosen has joined #openstack-keystone21:06
arosenHi, wondering what's the difference between these two in the body when posting to /v2.0/tokens21:07
arosen-d '{"auth": {"tenantName": "demo", "passwordCredentials": {"username": "demo", "password": "password"}}}'21:07
arosen-d '{"auth": {"passwordCredentials": {"username": "demo", "password": "password"}}}'21:08
arosenThey seem to return different things21:08
*** gokrokve has joined #openstack-keystone21:08
bknudsonarosen: the first one requests a token scoped to the "demo" project"21:09
bknudsonarosen: the second one doesn't request a scope so it could use the user's default project or no project21:09
bknudson(unscoped)21:09
arosenbknudson: thanks. I'm trying to write a client that integrates with keystone but I keep getting a scoped token back which doesn't contain the endpoints.21:11
arosenbknudson: I'm doing:   auth =  keystoneclient.auth.identity.v2.Password(auth_url, username, password)21:11
bknudsonarosen: it's got roles but no endpoints?21:11
arosensession = keystoneclient.session.Session(auth=auth)21:12
arosenyea it returns:21:12
bknudsonarosen: do you want an unscoped token?21:12
arosen{"serviceCatalog": [], "user": {"username": "demo", "roles_links": [], "id": "c25be5e9236246babdd316fdd369444a", "roles": [], "name": "demo"}, "metadata": {"is_admin": 0, "roles": []}}}21:12
bknudsonarosen: that doesn't have any roles21:12
arosenright, so it looks like i need to get an unscoped token to get this info21:13
bknudsonarosen: you need a scoped token21:13
*** dims_ has joined #openstack-keystone21:13
*** dims has quit IRC21:15
bknudsonarosen: you should be able to pass in a tenant_name to keystoneclient.auth.identity.v2.Password21:15
arosenbknudson:  then i'm passing that session variable to : SessionClient(session, ath=None, interface='publicURL', ...)21:15
*** lbragstad_ is now known as lbragstad21:17
arosenbknudson:  https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/auth/identity/v2.py#L7821:17
*** gabriel-bezerra has quit IRC21:17
arosenah sorry i see i can pass that. The base class takes tenant_name.21:17
bknudsonarosen: the docs are terrible.21:18
*** gyee has quit IRC21:18
*** dims_ has quit IRC21:18
arosenbknudson:  okay i got it working making auth this:21:19
arosenauth = keystoneclient.auth.identity.v2.Password( auth_url=instance._auth_url, username=instance._username, password=instance._password, tenant_name=instance._project_name)21:19
*** afaranha1 has quit IRC21:20
arosenbknudson:  it seems kind of confusing that project_name == tenant_name but I guess that's from times when nova used project_name so we don't have consistent naming?21:20
bknudsonarosen: I'm surprised that the v2 plugin doesn't accept project_name.21:20
*** rodrigods has quit IRC21:21
openstackgerritA change was merged to openstack/keystone: Ensure that in v2 auth tenant_id matches trust  https://review.openstack.org/10421621:22
*** afaranha has joined #openstack-keystone21:22
*** d34dh0r53 has joined #openstack-keystone21:23
*** dims has joined #openstack-keystone21:31
*** daneyon_ has quit IRC21:32
*** daneyon has joined #openstack-keystone21:32
*** hrybacki has quit IRC21:34
*** ukalifon has quit IRC21:38
*** rodrigods has joined #openstack-keystone21:40
*** gabriel-bezerra has joined #openstack-keystone21:44
*** leseb has quit IRC21:49
*** leseb has joined #openstack-keystone21:50
*** leseb has quit IRC21:54
*** jamielennox|away is now known as jamielennox21:55
jamielennoxbknudson: it could take project_id/name, but in v2 it was called tenant so i left it consistent - it's pretty easy to add22:04
*** elmiko is now known as _elmiko22:06
*** rodrigods_ has joined #openstack-keystone22:08
*** bobt has quit IRC22:11
*** jsavak has quit IRC22:11
*** d34dh0r53 is now known as mostly_d34dh0r5322:16
*** bklei has joined #openstack-keystone22:25
*** richm has quit IRC22:26
*** otwieracz has quit IRC22:33
*** otwieracz has joined #openstack-keystone22:34
*** rodrigods_ has quit IRC22:36
*** jdennis has quit IRC22:42
*** bklei has quit IRC22:44
*** david-lyle has quit IRC22:53
*** david-lyle has joined #openstack-keystone22:54
*** david-lyle has quit IRC22:59
*** amcrn has quit IRC23:04
*** amcrn has joined #openstack-keystone23:05
*** sigmavirus24 has quit IRC23:08
*** rodrigods_ has joined #openstack-keystone23:08
*** rodrigods_ has quit IRC23:11
openstackgerritA change was merged to openstack/keystone: Ending periods in exception messages deleted  https://review.openstack.org/10385223:21
openstackgerritA change was merged to openstack/keystonemiddleware: Privatize Everything  https://review.openstack.org/10403723:22
*** amerine has quit IRC23:31
*** thedodd has quit IRC23:31
*** gyee has joined #openstack-keystone23:33
*** oomichi has joined #openstack-keystone23:45
arosenbknudson:  do you know if any docs or pointers exist about integrating a new project with keystone? I got my client now passing the auth_token to my server.23:52
arosenLooking to add the keystone middleware server bits now.23:52
arosenlooks like things happen via the magic api-paste.ini :)23:53
openstackgerritOpenStack Proposal Bot proposed a change to openstack/identity-api: Updated from global requirements  https://review.openstack.org/10438323:54
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Updated from global requirements  https://review.openstack.org/10401823:54

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