Wednesday, 2014-11-12

*** shakamunyi has joined #openstack-keystone00:02
henrynashgyee: hmm, that’s a good point….ahev to think about that00:02
*** amcrn has joined #openstack-keystone00:02
*** david-lyle is now known as david-lyle_afk00:03
morganfainberghenrynash, gyee, as long as we have one mechanism in the end and not two distinct mechanisms that do functionally the same thing, i'm happy00:04
gyeemorganfainberg, conceptually, role groups and hierarchical roles are the same thing00:05
morganfainberggyee, right00:05
gyeeespecially if we support nested groups00:05
morganfainberggyee, hence the "lets not make 2 different systems"00:05
morganfainberg:)00:05
gyee++00:05
rodrigodsmorganfainberg, for a feature be in Kilo, its spec needs to be accepted until Kilo-1, right?00:06
morganfainbergrodrigods, specs can be accepted until Kilo200:07
morganfainbergrodrigods, but the sooner the better!00:07
rodrigodsmorganfainberg, working with kilo 1 here (HM evolution)00:07
rodrigods(the spec)00:07
morganfainbergright00:07
morganfainbergif you can land it by kilo1 even btter.00:08
rodrigodswe really appreciate the confidence in our work, thank you all =)00:08
morganfainbergrodrigods, seriously, you guys have been doing good work. I honestly can't ask for more.00:08
*** shakamunyi has quit IRC00:09
rodrigodsmorganfainberg, thanks! really enjoying implementing this stuff00:09
*** shakamunyi has joined #openstack-keystone00:10
*** henrynash has quit IRC00:10
*** shakamunyi has quit IRC00:15
gyeemorganfainberg, https://review.openstack.org/#/c/131575/00:20
gyeewe've got to do something to help performance, either reuse or AE token00:21
morganfainberggyee, AE is more in line, reuse i'm wholly against00:21
morganfainberggyee, look at my comment, it was implied AE was the direction i just didn't call it out00:21
gyeeI am totally fine with AE, just need ayoung to unblock00:21
morganfainberggyee, that isn't going to happen until after we do the cleanup [ the battle on AE at that point is "we should do it cause it makes life better" not massive re-implementation we throw out tons of code for ]00:22
morganfainberggyee, discussed this a lot w/ dstanek @ the summit00:22
morganfainbergyou were part of those convos00:22
morganfainbergiirc00:22
gyeeexactly00:23
morganfainbergso, yes and yes :)00:23
morganfainbergi'd much rather make uuid tokens way friendlier (even if they're not uuid anymore)00:23
gyeebut this is not a massive reimpl00:24
morganfainbergthis will be because of the way the providers work00:24
morganfainberglet me split my non-persistence spec - talk tomorrow about this?00:24
gyeek00:24
morganfainberggyee, you'll see where AE fits once that is done00:24
gyeek00:24
*** Viswanath has joined #openstack-keystone00:25
morganfainbergbut the short is: fix token issuance pipeline, layer non-persistence on top of that [PKI] AE works the same (needs basically 3 methods: 1) issue, 2) validate, 3) get ID00:25
morganfainbergnot issue v2, issue v3, etc etc etc00:25
gyeeamen!00:25
morganfainbergif we add AE it's going to add a *lot* more refactoring to get the cleanup done.00:25
morganfainbergso AE comes post cleanup00:25
* morganfainberg grumbles... *sigh* I have packet loss.00:26
gyeeand we are going to freeze the interface this time?00:26
morganfainberggyee, the interface for the token provider will be a hard-contract00:26
morganfainbergsame as the REST API00:26
gyeew00t!!!!00:26
morganfainbergif we change it we need an adapter layer to handle the change (for transition period)00:27
gyeeor version it00:27
morganfainberghow many people did we have lass midcycle? dolphm, dstanek?00:27
morganfainberggyee, same net effect00:27
gyeewe are having it in Sunnyvale this time?00:27
morganfainberggyee, that is my general hope.00:28
morganfainbergmight be mountain view.00:28
morganfainbergi'm trying to pin down space.00:28
*** Viswanath has quit IRC00:29
*** dims has quit IRC00:30
*** dims has joined #openstack-keystone00:30
rodrigodsmorganfainberg, gyee, dates?00:31
morganfainbergrodrigods, I'm aiming for January 20-2200:31
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Fix token_endpoint options  https://review.openstack.org/13386500:31
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Fix importing config module  https://review.openstack.org/13386600:31
*** shakamunyi has joined #openstack-keystone00:31
jamielennoxsimple 2 line fixes ^00:31
morganfainbergrodrigods, let me send out a survey on the ML so we can get real numbers.00:31
rodrigodsmorganfainberg, would love to be there, will try get my visa asap00:32
morganfainbergrodrigods, you should likely only need whatever visa would be required for a conference (fyi(00:32
*** henrynash has joined #openstack-keystone00:32
morganfainbergrodrigods, since thats effectively what this is.00:32
rodrigodsmorganfainberg, yep, here the tourism/conference visa are issued together00:33
rodrigodsjust have to schedule a date and really depends on the demand00:33
*** henrynash has quit IRC00:41
*** lhcheng_ has quit IRC00:46
*** nkinder has joined #openstack-keystone00:47
*** zzzeek has joined #openstack-keystone00:49
*** dims has quit IRC00:52
*** dims has joined #openstack-keystone00:52
*** amerine has quit IRC00:58
*** zzzeek has quit IRC01:13
*** amerine has joined #openstack-keystone01:14
*** amerine has quit IRC01:15
*** amerine has joined #openstack-keystone01:15
*** amcrn has quit IRC01:17
*** ChanServ sets mode: +o morganfainberg01:18
*** morganfainberg changes topic to "Blocking reviews: https://gist.github.com/dolph/651c6a1748f69637abd0 | Keystone Mid-Cycle survey: http://goo.gl/forms/4W7xVM9x49"01:19
*** gokrokve has quit IRC01:19
*** dims has quit IRC01:21
htruta_morganfainberg: I would really like having an option on the survey like "I hope to" :(01:21
*** dims has joined #openstack-keystone01:22
morganfainberghtruta_, well I understand this is all tentative. I'd rather assume you are going if there is a good chance.01:22
morganfainbergor even medium chance01:22
morganfainberghtruta_, added an option for you01:24
htruta_morganfainberg: hahaha. just saw it. cool01:25
*** gyee has quit IRC01:27
*** jacorob has joined #openstack-keystone01:34
*** wwriverrat has joined #openstack-keystone01:36
*** sigmavirus24_awa is now known as sigmavirus2401:38
*** amerine has quit IRC01:40
*** Viswanath has joined #openstack-keystone01:47
*** samuelms has quit IRC01:50
*** Viswanath has quit IRC01:51
*** htruta_ has quit IRC01:52
*** dims has quit IRC02:02
*** dims has joined #openstack-keystone02:02
*** amerine has joined #openstack-keystone02:06
*** diegows has quit IRC02:07
*** amerine has quit IRC02:11
*** marcoemorais has quit IRC02:21
*** ayoung has joined #openstack-keystone02:29
*** openstackgerrit has quit IRC02:34
*** sluo_laptop has joined #openstack-keystone02:45
*** tellesnobrega_ has joined #openstack-keystone02:46
*** dims has quit IRC02:50
*** dims has joined #openstack-keystone02:50
stevemarmorganfainberg, getting some good feedback already :)03:02
*** Viswanath has joined #openstack-keystone03:22
*** Viswanath has quit IRC03:25
*** marg7175 has joined #openstack-keystone03:27
*** esp has joined #openstack-keystone03:31
*** shakamunyi has quit IRC03:32
*** boris-42 has quit IRC03:37
*** alex_xu has joined #openstack-keystone04:15
*** sigmavirus24 is now known as sigmavirus24_awa04:19
*** stevemar has quit IRC05:14
*** tellesnobrega_ has quit IRC05:23
*** veena has joined #openstack-keystone05:29
veenaAnybody, please help me in understanding how tenant creation happens and what happens in background when we run the command "keystone tenant-create". Who is responsible for tenant and user creation05:30
*** marg7175 has quit IRC05:34
*** richm has quit IRC05:35
*** ajayaa has joined #openstack-keystone05:44
*** boris-42 has joined #openstack-keystone06:21
*** stevemar has joined #openstack-keystone06:27
*** stevemar has quit IRC06:28
*** stevemar has joined #openstack-keystone06:28
*** k4n0 has joined #openstack-keystone06:37
*** ukalifon1 has joined #openstack-keystone06:54
*** nellysmitt has joined #openstack-keystone06:56
*** amirosh has joined #openstack-keystone07:12
*** nellysmitt has quit IRC07:14
*** chmouel has quit IRC07:17
*** chmouel has joined #openstack-keystone07:19
*** nellysmitt has joined #openstack-keystone07:36
*** marekd|away is now known as marekd07:38
*** chmouel has quit IRC07:43
stevemarmarekd, ping07:51
*** chmouel has joined #openstack-keystone07:54
*** veena has quit IRC07:57
*** veena has joined #openstack-keystone07:59
*** jistr has joined #openstack-keystone08:08
*** amerine has joined #openstack-keystone08:12
*** nellysmitt has quit IRC08:13
*** amerine has quit IRC08:17
*** henrynash has joined #openstack-keystone08:32
*** nellysmitt has joined #openstack-keystone08:32
*** ajayaa has quit IRC08:33
*** stevemar has quit IRC08:34
*** ukalifon1 has quit IRC08:36
*** veena has quit IRC08:45
marekdstevemar, sorry, missed your msg08:48
*** afazekas has joined #openstack-keystone08:59
ekarlsojamielennox: https://review.openstack.org/#/c/130159/ wanna take a look at that ?09:00
*** navid__ has quit IRC09:03
marekdrodrigods: ping09:05
*** ukalifon has joined #openstack-keystone09:06
*** jistr has quit IRC09:06
*** amerine has joined #openstack-keystone09:13
*** navid__ has joined #openstack-keystone09:15
*** nellysmitt has quit IRC09:17
*** amerine has quit IRC09:18
*** nellysmitt has joined #openstack-keystone09:19
*** ajayaa has joined #openstack-keystone09:22
*** nellysmitt has quit IRC09:22
*** alex_xu has quit IRC09:23
*** jistr has joined #openstack-keystone09:26
*** marekd has quit IRC09:30
*** bdossant has joined #openstack-keystone09:31
*** marekd has joined #openstack-keystone09:34
*** samuelms has joined #openstack-keystone10:04
*** jacorob has quit IRC10:05
*** tellesnobrega_ has joined #openstack-keystone10:11
*** ajayaa has quit IRC10:16
*** aix has joined #openstack-keystone10:18
*** tellesnobrega_ has quit IRC10:23
*** tellesnobrega_ has joined #openstack-keystone10:29
*** ajayaa has joined #openstack-keystone10:38
*** diegows has joined #openstack-keystone10:47
*** tellesnobrega_ has quit IRC10:50
*** dims has quit IRC10:54
*** dims has joined #openstack-keystone10:55
*** Dafna has joined #openstack-keystone11:02
marekdmorganfainberg: ayoung: so for the https://review.openstack.org/#/c/133037/ i feel this can be landed much faster rather then redoing mapping engine.11:11
*** aix has quit IRC11:14
*** amerine has joined #openstack-keystone11:14
*** amerine has quit IRC11:15
*** amerine has joined #openstack-keystone11:15
*** amerine has quit IRC11:19
*** tellesnobrega_ has joined #openstack-keystone11:20
*** aix has joined #openstack-keystone11:28
*** alex_xu has joined #openstack-keystone11:39
ekarlsojamielennox: is the session stuff supposed to do a discover if a token + endpoint is used ?11:46
*** mflobo has quit IRC11:51
*** nellysmitt has joined #openstack-keystone11:53
ekarlsojamielennox: I dont get it why when using the new auth plugin stuff with a token it requires a auth_url to be set ?!11:59
ekarlsodoes ksclient need for some weirdo reason to validate the token before heading the to service ?11:59
*** lhcheng has joined #openstack-keystone12:01
*** alex_xu has quit IRC12:05
rodrigodsmarekd, ping12:11
ekarlsoaustralian seems to have gone to bed _,,-12:13
*** jaosorior has joined #openstack-keystone12:15
*** henrynash has quit IRC12:53
*** tellesnobrega_ has quit IRC12:56
*** tellesnobrega_ has joined #openstack-keystone13:03
*** afazekas has quit IRC13:06
*** thiagop has joined #openstack-keystone13:10
*** richm has joined #openstack-keystone13:11
marekdrodrigods: nvm :-)13:14
rodrigodsmarekd, hey... checking the next steps list you've presented in the summit at the k2k presentation. what do you think we here give a hand at the mappings issues13:20
*** amakarov_away is now known as amakarov13:22
marekdrodrigods: why not, however i am starting to feel we are trying to many things at the same moment.13:31
rodrigodsmarekd, that's true, where are efforts going on right now?13:31
marekdrodrigods: there was a ml thread from jdennis where he shared his experience with a mapping engine he wrote for opendaylight13:32
marekdyou may find it interesting, good meritoric mails.13:32
rodrigodsmarekd, saw that, didn't have time to read through, though13:32
marekdrodrigods: maybe it's a good way to start13:33
marekdi admit i didn't read it either.13:33
rodrigodsmarekd, great13:33
rodrigodshehe13:33
marekdrodrigods: on the other hand13:33
marekdone thing thay is quite painful is ensuring the user_id is globally unique.13:33
rodrigodsmarekd, but if you think that we should help to polish something else...13:33
marekdrodrigods: https://review.openstack.org/#/c/133037/13:34
marekdreview!13:34
marekdthink if this change imply some security issues13:34
marekdone thing i would start thinking is also regulations for making user_id unique.13:35
rodrigodsmarekd, will review, I'm asking for your opinion in a big topic though (so we can keep busy here for some days/weeks) =)13:35
rodrigodshmm13:35
marekdso if you want to keep yourself busy i'd go and read jdennis'es doc and think what could be useful for us.13:36
marekdrodrigods: nkinder and ayoung were also talking about dynamic groups13:37
*** ajayaa has quit IRC13:37
marekdi don't have any specific task in mind like 'impement this or that' - it's rather big picture thinking which probably can keep you busy for days :-)13:37
marekdand i am serious13:37
rodrigodsmarekd, great =)13:38
marekdrodrigods: oh13:38
marekdi just recalled one business usecase13:38
rodrigodstrying to multitask here: HM, federation and policies =)13:39
rodrigodsmarekd, hmm13:39
marekdwhat with policies?13:39
marekdwhat exactly13:39
marekdrodrigods: so, imagine you have same set of groups in your idp and keystone13:40
marekdnow, user should map idp groups to keystone groups13:40
marekdthis is not possible today with current mapping engine13:40
*** nellysmitt has quit IRC13:41
rodrigodsmarekd, hmm, group <-> group mapping?13:41
marekdkind of, but without explicit destination group specifying.13:42
marekdi want my epheremral federated user to become a member of keystone groups A,B,C as he is a member of groups A,B,C in my corporate LDAP13:43
marekdthanks to that i will be able to manage access by adding/reming users in my ldap13:43
rodrigodsmarekd, got it13:43
marekdnot by chaning mapping rules13:43
*** amaurymedeiros is now known as amaurymederos13:43
rodrigodsthat's a nice one13:43
marekdi think so too :-)13:44
rodrigodsmarekd, added to my list: read mappings email, same idp groups to keystone mapping13:45
rodrigodsthanks!13:45
marekdrodrigods: read mapping email ?13:45
marekdrodrigods: you might have misunderstood me ;-)13:45
rodrigodsmarekd, "marekd> rodrigods: there was a ml thread from jdennis where he shared his experience with a mapping engine he wrote for opendaylight"13:45
marekdaaaaa13:45
marekdok13:45
marekdsorry i misunderstood you todo bullet13:45
rodrigodshaha13:46
rodrigodsnp13:46
*** k4n0 has quit IRC13:46
marekdHP guy didn's respond me yet, but if he didn't setup k2k with proper crypto i'd try that one.13:46
marekdhopefully he will today, once he's awake.13:47
rodrigodsmarekd, it worked13:47
rodrigods=)13:47
*** tellesnobrega_ has quit IRC13:47
marekddid he reply you ?13:47
rodrigodsyep13:47
rodrigodsregarding the certificates issue13:47
rodrigodshe had an interesting idea: issue both SP and IdP certs with the same issuer13:48
rodrigodswas going to try it quickly here13:48
marekdrodrigods: go ahead13:48
rodrigodsmarekd, not sure if will have the time, though13:48
rodrigods=/13:49
marekdrodrigods: so you are asking me for ideas to work to keep you busy and at the same time you are super busy? :P13:49
rodrigodsmarekd, haha no... today is a "special" day, full of meetings =P13:50
marekdaha13:50
*** sigmavirus24_awa is now known as sigmavirus2413:54
*** dims has quit IRC13:56
*** dims has joined #openstack-keystone13:56
*** jacorob has joined #openstack-keystone13:59
*** spligak has quit IRC14:00
*** afazekas has joined #openstack-keystone14:01
*** amaurymederos is now known as amaurymedeiros14:03
*** afazekas has quit IRC14:06
*** joesavak has joined #openstack-keystone14:07
*** spligak has joined #openstack-keystone14:13
*** nkinder has quit IRC14:18
*** afazekas has joined #openstack-keystone14:19
*** gokrokve has joined #openstack-keystone14:20
*** lhcheng_ has joined #openstack-keystone14:22
*** kobtea has joined #openstack-keystone14:24
*** lhcheng has quit IRC14:24
*** shakamunyi has joined #openstack-keystone14:31
*** stevemar has joined #openstack-keystone14:35
*** zzzeek has joined #openstack-keystone14:35
*** adam_g` is now known as adam_g14:37
*** adam_g has quit IRC14:37
*** adam_g has joined #openstack-keystone14:37
*** openstackgerrit has joined #openstack-keystone14:40
*** thedodd has joined #openstack-keystone14:44
*** vhoward has joined #openstack-keystone14:46
*** henrynash has joined #openstack-keystone14:48
*** ajayaa has joined #openstack-keystone14:52
*** topol_ has joined #openstack-keystone14:52
*** topol_ is now known as topol14:52
openstackgerritLance Bragstad proposed openstack/keystone: Move notification unit tests to unit test dir  https://review.openstack.org/13383414:52
henrynashlbragstad: thx for all your reviewing recently…any chance you could give a quick squint to: https://review.openstack.org/#/c/132826/ …If we can get that in, we can kick start the whole sequence of patch fixes14:57
lbragstadhenrynash: looking14:57
henrynashlbragstad: thx14:57
lbragstadhenrynash: btw, I saw the bug you opened (https://bugs.launchpad.net/keystone/+bug/1391682)14:57
uvirtbotLaunchpad bug 1391682 in keystone "V2.0 Parameter validation for projects crud should not happen in drivers" [Low,New]14:57
lbragstadI have a patch that addresses some of it14:58
*** afazekas_ has joined #openstack-keystone14:58
henrynashlbragstad: yeah..and saw your comemnts….I’ll take a look at yours14:58
lbragstadit's WIP at the moment but I can try dust it off today14:58
*** ukalifon has quit IRC14:58
*** afazekas has quit IRC15:00
samuelmshenrynash, a couple of minutes to discuss about the 'list role assignments performance' patch ? :)15:06
henrynashsamuelms: sure15:06
rodrigodshenrynash, ^ run!15:06
rodrigodshehe15:07
ekarlsojamielennox: u up ? :D15:07
henrynashrodigods: :-)15:07
samuelmshenrynash, https://review.openstack.org/#/c/116682/12/keystone/assignment/controllers.py15:07
samuelmshenrynash, everything (except for parameters validation) shoudl be placed at the manager, right?15:08
henrynashsamuelms: I remember :-)15:08
samuelmshenrynash, so the methods like _build_project_equivalent_of_group_domain_role should be at the manager15:08
samuelmshenrynash, right?15:08
henrynashsamuelms: welll...15:09
*** nkinder has joined #openstack-keystone15:10
henrynashsamuelms: I would ahve thought we want the formatting of the chosen response to the API to still be in the controller15:10
henrynashsamuelms: i.e. let’s say we changed the stucture of teh json we spit return from the API call….15:11
samuelmshenrynash, but in those methods, as well as for _format_entity, they're based on *driver* results15:11
henrynashsamuelms: you would want that to ONLY affect the controller15:11
henrynashsamuelms: agreed….I think we need to look at what the manager should return to the controller15:13
samuelmshenrynash, that s the point15:13
*** gokrokve has quit IRC15:13
samuelmshenrynash, so the manager should return an intermediate representation of the assignment to the controller ?15:14
rodrigodssamuelms, henrynash, we should make clear what is the info that the manager *can* return15:14
samuelmshenrynash, and we need to use this representation when creating new assignments (when expanding) at the manager level15:14
rodrigodsand let the controller do the hard part: expand stuff15:14
rodrigodsright?15:15
samuelmsrodrigods, no15:15
samuelmsrodrigods, the expansion of assignments will be placed at manager level15:15
rodrigodssamuelms, ahh manager vs driver15:15
rodrigodswas meaning driver15:15
rodrigods=P15:15
samuelmsrodrigods, yep, makes sense now15:15
*** henrynash has quit IRC15:15
*** lhcheng_ has quit IRC15:18
*** samuelms is now known as samuelms-afk15:18
ayoungstevemar, I should be doing my expense reports and also out Benefits enrollment, but instead I am +2ing you patches15:22
stevemarayoung, woo hoo, i did those things other things on monday15:23
ayoungstevemar, these are simple enough.  I want to talk with you about the token pipeline, though.  marekd too15:23
marekdayoung: what's yp15:24
marekdup15:24
ayoungOK...I've been going on about the token provider as a pipeline for a couple years now15:25
ayoungand we sketched it out in the mid cycle last January15:25
marekdayoung: what's the general topic? REMOTE_USER and federation ?15:25
ayoungthe issues you are seeing with REMOTE_USER starts to get in to them15:25
ayoungand the openid  change that I +2ed as well15:25
ayoungthe question, then, is what should it look like.15:26
morganfainbergExpense reports ugh.15:26
ayoungIdeally, it would be a config file that end users could change, but that is risky, in that they could remove essential pieces15:26
ayoungalternatively, we could do "plugin ins"  at specific points in the pipeline, but then the pipeline gets rigid.  That is what we have now15:27
morganfainbergAlso good morning15:27
ayoungwe can swap the auth plugins, and we can swap the whole token provider15:27
ayoungmorganfainberg, good morning to you, too15:27
ayoungso...the first step would be, I think, to make use of dstanek 's new mechanism for wiring together the pipeline as a way to break apart the token provider15:28
marekdayoung: any links, reviews?15:28
ayoungmarekd, sure....15:28
ayounglet me get the diagram up from the discussion first...15:28
marekdayoung: cause i was thinking about refactoring auth.controller authenticate() and simply put higher priority on auth methods where JSON input is provided15:29
ayounghttps://twitter.com/admiyoung15:29
ayoungah...not there yet.15:29
marekdayoung: then, if there is no such thing and REMOTE_USER is not None fire exernal auth method15:29
ayounghold off, that is not sufficient15:29
marekdwell, some tests started to fail when i was doing so, but didn't investigate too deep.15:30
ayoungDamnit twitter, I want a link to my image!15:30
ayoungdata:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABAAAAAMACAYAAAC6uhUNAAAgAElEQVR4nOy9V5Mj1523qW+wN+ti3x2nkRkNJVKiSFESPUXRm6YTvZHo2b67TJcBCkDB2wQSmchEIpHwpnxVu2pv2N6bqvZNpzHx7l5sbOwHePYCldlA2aYojThvzMUTWXlOJoBCRUf07zn/88/vaAEfeihANhzEiITIhoOk/V4Udz+S04Hm86L5vOh+H9mAH93vI+PzknG7Ud1OVK8LxedA8fSRcttJu+yoThuqoxfV0YvmsqO57CiOXmRnL6q7cV2oez225R/S9eH7KF4vpWSSrBDDiAtkxThaPEYmIaDFYw2EKJoQJRuNYsRiFASBgiBgxASMQIh8l5P0x6uRXnmb+LMvkHxqGfqTz115:32
ayoungF98Ck23vs0W378Wzb+8EG23PEUYw8+T+mZ16m8+RED76xm4KMOau12Sk4PuXAIPRkjp4oU0xIjaZUd2RyHSzVOVYc4XRvm9OAop0bGuTg8ztH+KPvbnOzscnEkInKpVOO/b93Ov49tZiqVZTqmMuVPctGX5Hosw+dqkcuZIqc1g4N6lj2FCscntzN9+DDnDx/m3JHDXDpxgmtHj3Nl30GO1kY5VRnlXGGEs8YgJ7Uqx7Uqp7IDnCsOc1TMcVLKcTSZZW9EZrMzyrAtwLAtxIgrxoQ3xYhHYqhfou6WqLlSGL0CibVu/B92o9ujVHwphqNZxuJ5xhMFNiZLTIhFRmIGRXcSpStAdHUfwlonuj3KUERnY7LEmFKmppUoZQtzKOp5inqeSq5E2ShaNM8V9Twlo2xRzJYo6EXymQJGOoeRzr15:32
ayoungXMm9fMR0EvWhSzJUpGmXKuQjFbIp8pkNPy5LQ8+UyBgl4kp+Ux0jlrvHmu+XXzmQL5TMF6zdnkjZJFIVemkCtTzFco5iuUCtUlqRYqFrVilXqpRr1UY6BcZ6BcZ7g2xEh9mJH6MKMDI4wNjjI+NMbE8DgTw+NMTmxhcuNWtm2aZHJyO5PbdrB11y4md+9m69497Dh4gJ2HDrL78CH2HDnMgSNHOXTsOEePneDYsRMcOXSY44ePcOLIUU4dO86ZEyc5d+o050+fYerMWc6dOt1yPn32HBfOnefCufNcPD/FhbPTXDg7zfSZKaZOn2fq9HnOnzrH+VPnOHfyLCcOH+fYwaMc2neQT3fvZ9/OvezetosdW7YzuXErk6Ob2Da2mc1D4wwVa+QVnXRcRhUktESKdFy2UAUJVZBQYkmUWBJZSC15:32
ayoungALAlI8uiBJIbIgkhAhFYugRBdGDocspFCQZDBgIQb8LfPzkYqEF0WKhJAiIeRomFRs5vMIUdR4DDUeQ46GF0WMxBYlGRUWRYwmEaNJkpFW5HADJSK2oIZvoERE5FAMKbwwqWh8QaRYDDEaQhRCJONhpERkzt9OiguzSLSQEOIWYjyBGE+QTIg3jSQmF+XPeb85JiclC0VOkZLklvPmseZ7U5I8BzmZWhRJlBdlqftTkrIoC12ryKqFmkqjptKkFY20olnnzXN/Kub3pcgp1JSCmlJIK6qFOdY8rqlpi+b5r40ioypJlFSClBxHSSVIq0m0tERaTaIqImk1uQSpRdHSyjcio6k3jZ5Jo2fSZHXNYr7XMq8zMcfnu+7rvP98zPe+N+ZkMlqKjCYviPn30NKSNaZnUuiZFFldwUjLN01OS515:32
ayoungHTUuQzikU5k6KcSVHSUxRmyGdTGEaDQiFNPq+Sz6YoGArVXJp6IcNgQWewoDNQ1KnlNcpZhYqhUivqDFZyDJQN6qUslWKGSjFDqTQ/mUwSTRNRFAFJihCPB4hGvYRC/QSDLvr7eyxcrm5crm6czi4LR0/7ovR0rKG3c62FbcO6G3StoW/DKhzdq+i3rcXraCPQ30nY203U30ssYEOMOElGXcQCNhzdq1jxwWu88bsnePGZh3jhqYd45dknuO+O2/nH/+N/4W/+5/+Jn3z3b7nnZz/h/jtu5de3/Yin7v8V//w3/xu/vOUfeeDnt3Dfbf/Ew3feykuP3I+/ax15:32
morganfainbergHah15:32
ayoungYou have to be Fing kidding me15:32
*** gokrokve has joined #openstack-keystone15:32
*** ajayaa has quit IRC15:33
ayounghttps://twitter.com/admiyoung/status/42906044846257766415:33
stevemarayoung, click on the hour/date of the tweet15:33
ayoungOK,  looks like I need to link to the post15:33
stevemarthere ya go15:33
marekdo, i remember that pic15:34
ayoungmutter mutter15:34
ayoungOK, so  there are some optional pieces in there, which were put in for the discussion.  Don;t let them distract for now15:34
ayoungOK,  so let me throw out an early approach the morganfainberg has already nacked:  we do it all as a paste pipeline.15:35
ayoungit would look like this:15:35
ayoung[pipeline:auth]15:35
* ayoung just to start the conversation...15:36
ayoungpipeline =    sizelimit url_normalize authenticate token_scope delegation catalog format compress signature persist15:37
ayoungdelegation would, I think, include role assignments, trusts, and oauth in one integrated piece15:38
* ayoung missed groups15:38
ayoungpipeline =    sizelimit url_normalize authenticate mapping virtual_orgs token_scope delegation catalog format compress signature persist15:39
stevemarayoung, would this new proposed pipeline remove token_auth and admin_token_auth from the v3/admin/public pipelines?15:39
ayoungstevemar, that is the thing, they don't belong in the auth pipeline15:39
ayoungtoken_auth would instead be an auth-plugin only15:39
stevemarhmm15:40
marekdauth pipe15:40
ayoungstevemar, ok...let me go a little further15:40
ayoungpaste has a shortcoming that we need to work around15:40
*** henrynash has joined #openstack-keystone15:40
ayoungwe can define a filter, or a pipeline, but we can't define a reusable series of filters to use in multiple pipelines15:40
ayoung lets assume, though, that we can do that15:40
ayoungso something like15:41
ayoung[filter-list: token_pipeline]15:41
ayoungfilters =     mapping virtual_orgs token_scope delegation catalog format compress signature persist15:41
ayoungthen we want to do two different auth_urls, say one for SAML, and one for Kerberos15:41
ayoungit would be15:41
henrynashsamuelms, rodigods: sorry, was offline for a bit…yes, agree with your points15:42
ayoungpipeline =  sizelimit url_normalize saml_auth token_pipeline issue_token15:42
ayoungwith issue_token being the "service" there as required by paste15:42
ayoung we'd pull apart the v3 pipeline to have auth in its own pipeline15:43
ayoungfor issuing SAML assertions in the K2K case we would vary up the pipeline15:43
morganfainbergSo. Let me ask a question. Why are we trying to split everything up at once? The isolation of the "bits" that are token provider specific seem like a small optimization and not a big win (especially if they are blockers for the other work this cycle)15:44
ayoungso where I have format in the pipeline, it would probably be  token_format versus saml_format15:44
marekdayoung: what would be that saml_auth?15:44
*** baffle has joined #openstack-keystone15:44
marekdscoping federated token?15:44
ayoungmarekd, to me, keystone PKIZ tokens and Keystone SAML docs are two different marshalling formats for the same data15:45
morganfainbergToken providers are largely workable as they are (cleanup needed) without needing the fine grained breakdown you're proposing. I'm not saying don't do a pipeline. I'm saying don't try and break it down too far off the bat. Small steps15:45
ayoungthat was why it was /auth/tokens.  We should have /auth/saml15:45
ayoungmorganfainberg, lets get the vision before we do task breakdown15:45
ayoungwhat I really need is the ability to specify kerberos, x509, and basic/password auth in their own pipelines15:46
morganfainbergI think you're off in the weeds of implementation15:46
morganfainbergHonestly15:46
morganfainbergThis isn't vision, this is "what are we going to do".15:46
ayoungmorganfainberg, I'm using the paste as an example, not as the end implementation15:47
ayoungfor example, each time I changed the token format, I needed to subclass token-provider15:47
ayoungthat is not really what we want15:47
ayoungwe could do it all in Python code, using dstanek 's DI mechanism15:47
ayoungI still would need to do paste work, though15:48
morganfainbergYes and we decided that is already largely where we wanted to head. The paste part -- that is details following. You don't *need* paste to do this.15:48
baffleIs there any available policy.json example that implements RBAC with roles and also supports the notion of a "superadmin" like v3cloudsample?15:49
ayoungright....as I said you had already nacked it.  I was showing a practical example.  But regardless of how we implement the token pipeline, we've identified we want to actually have one.15:49
morganfainbergAny token provider would be 4 things: issue, validate , validat_middleware, token I'd15:49
ayoungI don't care if it is paste or some other format15:49
ayoungwe need to be able to swap format.15:50
ayoungwe need to be able to swap auth mechanism15:50
ayoungand, we don't want to force all token pipelines to use the same auth mechanism, we do that today15:50
morganfainbergThe provider *is* the format the way I see it15:51
ayoungwe want to be able to reuse the mapping across multiple pipelines, I think. But even there, I am not 100%.  The REMOTE_USER issue comes up repeatedly in Kerberos15:51
ayoungmorganfainberg, then we need to make it cleaner to define new token providers.15:52
ayoungand all of the delegation stuff does not need to be swapped out15:52
*** afazekas_ is now known as afazekas15:52
*** david-lyle_afk is now known as david-lyle15:52
morganfainbergYes. Already working on the spec for that. Talked a lot with dstanek about this and largely we are headed exactly that way.15:52
ayoungI think that is going to be common15:53
* morganfainberg is on phone so harder to type it all out.15:53
ayoungmorganfainberg, gotta run myself.15:53
morganfainbergDelegation is independent of format, agreed.15:53
ayoungWill get back on line shortly15:53
morganfainbergK15:53
*** ayoung is now known as ayoung-afk15:53
marekdmorganfainberg: ok, so, speaking more...short term....any opinions on that? https://review.openstack.org/#/c/133037/15:55
*** diegows has quit IRC15:55
*** ajayaa has joined #openstack-keystone15:55
*** wwriverrat has joined #openstack-keystone15:56
marekdbecause this is cause of all this convo15:56
morganfainbergAt a glance that makes a lot of sense.15:56
marekdso, feel free to add a score once you read it.15:57
morganfainbergYeah. Putting it on my short list for today.15:57
marekdthanks15:57
*** amirosh has quit IRC15:59
*** amirosh has joined #openstack-keystone16:00
openstackgerritLance Bragstad proposed openstack/keystone: Move test_utils to keystone/tests/unit/  https://review.openstack.org/13398916:01
*** thedodd has quit IRC16:02
*** wwriverrat1 has joined #openstack-keystone16:04
*** lhcheng has joined #openstack-keystone16:04
*** amirosh has quit IRC16:04
*** lhcheng_ has joined #openstack-keystone16:06
*** wwriverrat has quit IRC16:06
*** wwriverrat1 has left #openstack-keystone16:07
*** lhcheng has quit IRC16:09
*** saipandi has joined #openstack-keystone16:15
*** saipandi has quit IRC16:17
*** kobtea has quit IRC16:18
*** kobtea has joined #openstack-keystone16:19
*** kobtea has quit IRC16:24
*** sigmavirus24 is now known as sigmavirus24_awa16:32
*** amerine has joined #openstack-keystone16:33
*** gokrokve_ has joined #openstack-keystone16:33
*** _cjones_ has joined #openstack-keystone16:34
*** sigmavirus24_awa is now known as sigmavirus2416:34
*** Viswanath has joined #openstack-keystone16:36
*** gokrokve has quit IRC16:36
*** gokrokve_ has quit IRC16:37
*** ajayaa has quit IRC16:38
*** Viswanath has quit IRC16:39
*** lhcheng_ has quit IRC16:40
*** lhcheng has joined #openstack-keystone16:44
*** gyee has joined #openstack-keystone16:45
openstackgerritLance Bragstad proposed openstack/keystone: Move test_utils to keystone/tests/unit/  https://review.openstack.org/13398916:47
*** lhcheng_ has joined #openstack-keystone16:49
*** amerine has quit IRC16:51
*** afazekas has quit IRC16:51
*** lhcheng has quit IRC16:51
*** shakamunyi has quit IRC16:53
*** samuelms-afk is now known as samuelms16:54
*** ayoung-afk is now known as ayoung16:57
openstackgerritMerged openstack/keystone: Add openid connect support  https://review.openstack.org/13270616:58
openstackgerritMerged openstack/keystone: Additional debug logs for federation flows  https://review.openstack.org/13299516:58
*** joesavak has quit IRC17:03
*** joesavak has joined #openstack-keystone17:04
openstackgerritLance Bragstad proposed openstack/keystone: Move injection unit tests to keystone/tests/unit  https://review.openstack.org/13401017:10
*** amirosh has joined #openstack-keystone17:10
*** amerine has joined #openstack-keystone17:10
*** gokrokve has joined #openstack-keystone17:12
*** marcoemorais has joined #openstack-keystone17:14
*** amirosh has quit IRC17:15
*** nellysmitt has joined #openstack-keystone17:17
*** thedodd has joined #openstack-keystone17:19
*** henrynash has quit IRC17:30
*** amcrn has joined #openstack-keystone17:31
openstackgerritMarek Denis proposed openstack/keystone: Adds dynamic checking for mapped tokens  https://review.openstack.org/13313017:32
openstackgerritMarek Denis proposed openstack/keystone: Rename openid to oidc in test_auth_plugins.conf  https://review.openstack.org/13349417:33
*** ukalifon1 has joined #openstack-keystone17:37
*** jistr has quit IRC17:38
ukalifon1Hi. I am trying to test CADF in keystone in Juno. I am creating users and granting them roles in different projects/domains - and no messages are emitted to the log at all. Do I need to configure CADF somehow to get it to work? Is it logging to the file or a message queue?17:41
*** amcrn has quit IRC17:41
morganfainbergukalifon1, CADF notifications should go out on the notification bus.17:42
morganfainbergukalifon1, but you'll need to configure notifications to be on.17:42
ukalifon1morganfainberg: how can I configure notifications?17:43
morganfainbergukalifon1, looking for the link for you17:43
*** amirosh has joined #openstack-keystone17:43
morganfainbergso here are the docs on notifications: http://docs.openstack.org/developer/keystone/event_notifications.html looking for the exact option to turn them on for you17:45
morganfainbergstevemar, hah, i think we have a documentation gap17:46
morganfainbergukalifon1, enabling notifications for keystone works the same as any other project using the oslo.messaging library17:48
*** afaranha has joined #openstack-keystone17:52
morganfainbergukalifon1, http://docs.openstack.org/trunk/config-reference/content/orchestration-configuring-rpc.html here is the doc you're looking for17:52
morganfainbergukalifon1, once the RPC / notification system is enabled, CADF notifications for Keystone will be emitted to the bus.17:52
ukalifon1morganfainberg: Thanks a lot, I'll try it now17:54
*** shakamunyi has joined #openstack-keystone17:56
*** thedodd has quit IRC17:56
*** shakamunyi has quit IRC17:56
*** bdossant has quit IRC17:57
*** henrynash has joined #openstack-keystone17:59
*** amcrn has joined #openstack-keystone18:00
*** shakamunyi has joined #openstack-keystone18:01
*** gokrokve has quit IRC18:03
*** gokrokve has joined #openstack-keystone18:03
*** thedodd has joined #openstack-keystone18:05
stevemarmorganfainberg, ah okay... ukalifon1 did that work for you? are you seeing the notifications / what did you have to change?18:13
morganfainbergmarekd, stevemar, +1 on the REMOTE_USER change for mapped18:17
morganfainbergbut no +2 until API doc change merges.18:17
stevemarmorganfainberg, fair enough18:18
marekdmorganfainberg: thank yoy, just replied to your comment.18:18
morganfainbergmarekd, thanks. also +2 on the API change18:18
openstackgerritAlexander Makarov proposed openstack/keystone-specs: Trust redelegation documentation  https://review.openstack.org/13154118:19
amakarovmorganfainberg, greetings! I made some changes to trust specs,can you please take a look? https://review.openstack.org/#/c/131541/18:19
*** aix has quit IRC18:19
morganfainbergmarekd, but user_name isn't used *anywhere* if it came from REMOTE_USER with that code.18:20
morganfainbergwe only have user_id at that point, and not in any mapped properties, so... do we need to return out "user_name" in that case from _setup_username ?18:20
morganfainbergwe only return user_id from _handle_unscoped_token18:21
henrynashlooking for someone to start +A the first in the chain of assignment fixes: https://review.openstack.org/#/c/132826/218:21
morganfainberghenrynash, let me take a gander, then i need to go off and do paperwork (more specifically write up an official summary of the summit)18:22
morganfainbergomg it's only 10am :P18:22
marekdmorganfainberg: we start with getting *user_name* either from mapped_properties or REMOTE_USER and urlencode it to user_id18:22
henrynashthere’s a whole bunch stacked up behind this that I think we want to backport to Juno…so want to get them in before we changed anything too radical in Kilo18:22
marekdaccording to the spec token should have both user_id and _user_name18:22
marekdand the code returns user_id only.18:22
morganfainbergmarekd, right. but _setup_username user_name return isn't used anywhere18:22
morganfainbergthat was my only point, we have it just ... not doing any7thing with it18:23
*** amcrn has quit IRC18:23
morganfainbergand i was wondering if we needed to in that case.18:23
marekdmorganfainberg: and my point is: there should be new bug that will put user_name in line 13618:23
morganfainbergahhhh18:23
morganfainbergnow i get it18:23
*** browne has joined #openstack-keystone18:23
marekd...or change the documentation and erase user_name from the token.18:23
marekd(gerrit reviews are sometimes tricky to read)18:24
morganfainbergi'd like to drop username from the token tbh, it is mutable18:24
morganfainbergnot in this case, but in other cases18:24
marekdso, drop user_name and update docs, right?18:24
morganfainbergi think that falls into API contract break though18:24
*** thedodd has quit IRC18:24
morganfainbergso, no :(18:24
marekdwe had that split forever as i recall18:25
marekdso docs would catch up with code.18:25
marekdcannot do it?18:25
morganfainbergyeah, we likely need to add user_name18:25
*** thedodd has joined #openstack-keystone18:25
marekdlet me propose it18:25
morganfainbergmarekd, sure.18:25
marekdi wonder if it will break anything :D18:26
morganfainbergprobably :P18:26
*** amakarov is now known as amakarov_away18:27
openstackgerritMarek Denis proposed openstack/keystone: Return ``user_name`` in federated tokens.  https://review.openstack.org/13402718:28
henrynashmorganfainberg: thx18:28
henrynashmorganfainberg: if you get a chance to follow the chain up…teh first few already have two +2s…so a quick coup-de-grace might be easy18:31
morganfainbergi am reading them18:31
morganfainbergsome comments but nothing blocking +A18:31
rodrigodswe need https://review.openstack.org/#/c/117786/ merged so we don't have a bug in the API =)18:32
morganfainberglike... don't skip tests, actually verify the "broken" behavior18:32
henrynashmorganfainberg: I’ll be doing some follow-up cleanup patches, so will collect any comments and batch them in18:32
morganfainbergbut largely no major issues.18:32
rodrigodsmorganfainberg, about don't skipping tests, you are making samuelms a happier person18:32
morganfainberghenrynash, ok i pushed go on the first couple patches there18:34
morganfainberghenrynash, i stopped where there wasn't 2x+218:34
henrynashmorganfainberg: thx18:34
morganfainberghenrynash, https://review.openstack.org/#/c/133299/ is where i stopped for now18:34
henrynashmorganfainberg: ok…a godo start18:34
morganfainbergif i didn't have a ton to write up from the summit i'd keep going right now18:34
morganfainbergrodrigods, yes we do need to merge that.18:35
morganfainbergrodrigods, it's on my list to review once i'm done writing things up18:35
morganfainberghenrynash, also commented on the expirimental vs stable spec yesterday18:35
morganfainberghenrynash, thanks for writing that up btw.18:35
henrynashmorganfainberg: yep, updating that…will post another version later today18:35
morganfainbergawesome18:35
morganfainberglargely i think it will have almost no impact on anything besides code structure / communication to the deployers.18:36
morganfainbergand the code structure changes should be minimal. it's just changing how we handle things and make things a little more explicit.18:36
*** thedodd has quit IRC18:37
morganfainberghmm.18:39
morganfainbergso far *most* people can make san antonio for mid-cycle18:39
morganfainbergand only 1 person can't make it18:40
openstackgerritMerged openstack/keystone-specs: Add REMOTE_USER mapping info in federation docs.  https://review.openstack.org/13367418:40
*** htruta has left #openstack-keystone18:40
samuelmshenrynash, ping18:40
*** htruta has joined #openstack-keystone18:40
samuelmshttps://etherpad.openstack.org/p/role-assignment-backend-language18:41
samuelmshenrynash, please take a look at this ^18:41
samuelmshenrynash, my idea is to have a consistent representation of role assignments at Manager and Driver levels18:41
*** thedodd has joined #openstack-keystone18:41
samuelmshenrynash, and then Controller format them as it needs to18:41
rodrigodssamuelms, henrynash ++18:42
morganfainbergnkinder, ping re: getting RH space [looks like we might also have space from Rackspace available, same event location for Barbican so it might make sense to just use that space)18:48
nkindermorganfainberg: that's in SF?18:49
morganfainbergnkinder, the rackspace location is SF18:50
morganfainbergwill be if anything the same space barbican is using.18:50
morganfainbergso same as last time just bay area event space vs. geekdom in SAT18:50
morganfainbergbut i wont know details on that space. HP doesn't have space in sunnyvale, and i think we can't get the PA office auditorium18:51
morganfainbergwell HP *has* space, but it'd be less friendly to a group of ~2018:51
morganfainbergassuming roughly the same turnout18:51
*** arborism has joined #openstack-keystone18:52
*** arborism is now known as amcrn18:53
*** jsavak has joined #openstack-keystone18:58
*** diegows has joined #openstack-keystone18:59
*** joesavak has quit IRC19:02
*** gokrokve has quit IRC19:02
*** gokrokve has joined #openstack-keystone19:02
*** radez_g0` is now known as radez19:06
*** gokrokve has quit IRC19:07
samuelmsnkinder, ping19:09
*** gokrokve has joined #openstack-keystone19:10
*** shakamunyi has quit IRC19:12
*** shakamunyi has joined #openstack-keystone19:13
*** gokrokve has quit IRC19:21
*** gokrokve has joined #openstack-keystone19:21
*** gokrokve has quit IRC19:22
*** gokrokve has joined #openstack-keystone19:22
*** sbasam has joined #openstack-keystone19:27
vhowardgyee: sri basam and i would love some input on our blueprint for catalog filtering by region if you or anyone else has time….a bit confused on if we need to document a spec or not19:28
vhowardhttps://blueprints.launchpad.net/keystone/+spec/catalog-filtering-by-region19:28
gyeemorganfainberg, SF is better if the guys are staying in SF. Believe me, ya don't want to deal with the (*&@#$ traffic in 101.19:28
morganfainberggyee, i agree19:29
samuelmsHi guys, I've pointed out a potential security issue on our Hierarchical Projects patch #11778619:29
samuelmsIt would be great if you could take a look at .. so that we could work on this if necessary19:29
samuelmsgyee, morganfainberg ^19:29
gyeevhoward, looking ...19:29
vhowardthank you very much19:29
sbasamgyee: Thanks19:30
morganfainbergyay for feature branch!19:30
morganfainbergno CVE!19:30
morganfainberg:)19:30
samuelmsmorganfainberg, but we'll get this merged soon on our master right?  :-)19:31
morganfainbergsamuelms, we will, there will be a bit of work to do it, but we will.19:31
nkindersamuelms: pong19:32
morganfainbergsamuelms, so we will merge to the feature branch, fast-forward the feature branch (resolve conflicts) and then merge to master from feature branch19:32
morganfainbergand this *may* not actually be a security issue19:32
*** esp has left #openstack-keystone19:32
morganfainberghowever, when we add the reseller-type break case, it would need to have the hierarchy traversal stop19:33
samuelmsmorganfainberg, cool .. just would like to get some opinions over there ..19:33
samuelmsmorganfainberg, not sure that we could expose ids like that19:33
morganfainbergids largely (except in the case of tokens) are not "secure" data.19:34
morganfainbergthis *may* be ok19:34
morganfainbergbut nkinder might have a clearer view on it19:34
samuelmsnkinder, last Friday you said me I could ping you if we need some patch reviews :)19:34
samuelmsnkinder, morganfainberg exactly19:34
samuelmsnkinder, it'd be great if you could take a look at patch #11778619:35
nkindersamuelms: yep, I remember :)19:35
samuelmshttps://review.openstack.org/#/c/117786/3119:35
gyeevhoward, sbasam, you want to filter on token auth right?19:35
sbasamWe want to filter on the os_region_name so that the catalog size can be limited to just a region19:35
gyeelike POST /v3/auth/tokens?catalog_filter=???19:35
gyeebecause with endpoint groups, you can group them by region if you want19:36
samuelmsnkinder, I've left a couple of comments on that patch (where I think there is a potential security issue)19:37
samuelmsnkinder, will wait for your opinion over there :-)19:37
nkindersamuelms: yeah, reading that now.19:37
samuelmsmorganfainberg, thanks for clarifying (-:19:37
nkinderSo the concern is that the parent ID is viewable for someone with a role on a child19:37
sbasamgyee: You mean to say we can limit the catalog with endpoint grouping?19:37
samuelmsnkinder, exactly19:38
nkindersamuelms: so the ID is just a UUID, which isn't useful in and of itself19:39
nkinderFor a reseller case, you are going to know who you are buying service from19:39
gyeesbasam, yes19:39
gyeeyou can create a group with the region filter19:40
gyeeand assign it to a project19:40
samuelmsnkinder, yes .. for the reseller we'll have to stop going up and down on the tree at some point (when a new domain starts)19:40
nkinderSo I'm not sure if knowing the parent ID is really a problem.  You can't use to get a token at that scope without a role.19:40
*** dtturner has joined #openstack-keystone19:40
gyeesamuelms may have a point there19:40
gyeewe should be able to have ACLs at any point in the tree19:41
gyeelike LDAP19:41
samuelmsnkinder, yes makes sense .. ids by themselves are useless19:41
gyeenkinder, but you can retrieve the whole chain though19:42
nkindergyee: how?19:42
gyeethe entire hierarchy19:42
gyeeof IDs19:43
nkindergyee: yeah, how can I read up past my parent without a role on that parent?19:43
nkindergyee: or is it all parents?19:44
gyeeI think so19:44
*** marcoemorais has quit IRC19:44
*** marcoemorais has joined #openstack-keystone19:44
gyee?parent_as_list should get you everything19:45
gyeeand subtree as a list19:45
sbasamgyee: Need to read up on how endpoint grouping works.  We have tenants/projects which have access to lots of regions. When a tenant is working in a region, we want the catalog size to be limited to just endpoints in that region so that we aren't passing around lots of data.19:45
gyeeI don't think we filter resource based on access19:45
nkinderas a list of IDs, which are just UUIDs19:45
rodrigodsnkinder, the project object is returned19:46
gyeenot just IDs19:46
gyeesee line 42519:46
gyeelist of refs19:46
rodrigodsgyee, ++19:46
raildogyee, nkinder what do you think about to create new options in the policy, to control this options?19:46
raildoso, i can control if a user can list the subtree, or parent, or the full hierarchy19:47
gyeeraildo, problem is oslo policy can't filter resource to be returned19:47
*** amirosh has quit IRC19:47
nkinderOk, so returning the whole project for all parents doesn't seem good.  That exposes too much info19:47
*** amirosh has joined #openstack-keystone19:48
raildoi know, that is not control resource, that is control the action, the user can't use the API call19:48
gyeenkinder, like really like LDAP ACLs, they work nicely for tree structures19:48
gyeeI mean I really like19:48
nkinderJust the IDs sounds OK at first thought, but names could give away info about resellers up the tree19:48
samuelmsmakes sense19:49
morganfainbergdstanek, i know you're on vacation but ping: re DI19:49
nkinderIf you think about it, that's sort of how LDAP works19:49
nkinderYou know the DN of all parents by nature of the DN structure19:49
gyeeyeah man, no industrial espionage :)19:49
nkinderThat doesn't mean you can see any of the contents of parent entries though19:49
nkinderA DN is just the unique reference to an LDAP entry, and an ID is the unique reference to a project19:50
gyeeyep19:50
nkinderAn ID does not convey the hierarchy by itself, but that's OK I think19:50
gyeehow about we change it to just return the IDs?19:51
gyeeI don't think there's a use case for everything else19:51
raildobut this control via the new role visibility, right? if the user can access a "subdomain", i will list the whole hierarhcy19:52
rodrigodsgyee, change to return only the ID for the current impl?19:52
*** amirosh has quit IRC19:52
raildoif a user can't access a subdomain, the subprojects inside this subdomain, don't will be returned19:52
raildobut for now, we don't have this visibility control, so i can't do this implementation19:53
samuelmsnkinder, did you get raildo's point?19:53
nkindersamuelms: I think so.  That's for breaking visibility down the tree, right?19:54
samuelmsnkinder, basically, for reseller we won't get projects from another domain, right?19:54
raildonkinder, yes19:54
samuelmsnkinder, yes19:54
*** ukalifon1 has quit IRC19:54
samuelmsnkinder, if seeing whole information of projects inside the same domain is not a problem19:54
samuelmsnkinder, maybe we can keep this, right?19:55
*** dnalezyt has joined #openstack-keystone19:55
gyeesbasam, endpoint filter should solve your problem, let me know if you have issue with the doc, I'll fix19:55
nkinderIt just gives away name, ID, and description for the projects, right?19:55
rodrigodsnkinder, right19:55
nkinderIf we're not covering the reseller case right now, that's not a big deal19:56
rodrigods++19:56
raildonkinder, sure19:56
nkinderIt should just be made clear that one has full visibility into the hierarchy I think19:56
nkinderLet me see if we lock down list_projects though....19:56
gyeewe do19:56
rodrigodsnkinder, I think we do, and get projects info as well19:57
rodrigodsmight be a good argument agains returning the full ref19:57
nkinderSo we lock it down to domain admins right now in the v3 policy19:57
nkinder...for list_projects19:57
samuelmsnkinder, yes19:57
gyees/domain/project with special properties/19:58
gyee:D19:58
nkinderget_project is locked down to the admin of a project19:58
rodrigodsyeah, but returning only the ID is a bit useless, since there is no way to know about the hierarchy19:59
rodrigodsonly if we return them already in a structured fashion19:59
openstackgerritMerged openstack/keystone: Improve testing of domain federation tokens for inherited roles.  https://review.openstack.org/13282620:00
*** jsavak has quit IRC20:01
samuelmsnkinder, I think we can keep showing the subtree because we'll stop once we get a new domain (for reseller), right?20:02
samuelmsnkinder, but showing up the projects (even inside the same domain) may be an issue20:02
openstackgerritLance Bragstad proposed openstack/keystone: Move base64 unit tests to keystone/tests/unit dir  https://review.openstack.org/13404320:02
openstackgerritLance Bragstad proposed openstack/keystone: Increase test coverage of test_base64utils.py  https://review.openstack.org/13404420:02
*** joesavak has joined #openstack-keystone20:03
*** jaosorior has quit IRC20:03
openstackgerritLance Bragstad proposed openstack/keystone: Move functional tests to keystone/tests/functional  https://review.openstack.org/13355620:13
samuelmsnkinder, what about showing only the ids of parents and subtree of projects that the user has not access to20:14
samuelmsnkinder, but if he has access to any projects in that hierarchy we want to show, then we can show the full info of that project20:14
samuelmsmakes sense?20:14
*** wwriverrat has joined #openstack-keystone20:15
samuelmsI mean, If he could do a 'get project' on that project .. so put the whole info, because he'd be able to do that by himself20:15
*** wwriverrat has left #openstack-keystone20:15
*** edmondsw has joined #openstack-keystone20:21
samuelmsmorganfainberg, nkinder, gyee we'll have to get back on this discussion later ^20:48
samuelmsrodrigods and raildo too :-)20:48
gyeesamuelms, sure20:56
gyeelunch time for the left coast ppl right now it seems :)20:57
*** gyee has quit IRC20:58
*** kobtea has joined #openstack-keystone20:58
*** amirosh has joined #openstack-keystone20:58
*** marg7175 has joined #openstack-keystone21:00
*** amirosh has quit IRC21:03
*** kobtea has quit IRC21:03
dtturnerHi Folks-  Running into a strange one today.  I just setup Mistral in order to kick the tires and notice that calls meant for Heat are ending up on the Mistral endpoint.  This is obviously wreaking havoc on Heat consumers, with 404's and timeouts.21:06
dtturnerThe service endpoints are completely different.  Anyone seen this?21:06
openstackgerritLance Bragstad proposed openstack/keystone: Move test_utils to keystone/tests/unit/  https://review.openstack.org/13398921:08
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: API doc for Inherited Role Assignments to Projects  https://review.openstack.org/13027721:09
raildodtturner, which port you are using ?21:10
*** shakamun_ has joined #openstack-keystone21:10
*** shakamunyi has quit IRC21:10
dtturnerraildo: Hi.  For Mistral?  8989.21:12
openstackgerritRodrigo Duarte proposed openstack/keystone-specs: API doc for Inherited Role Assignments to Projects  https://review.openstack.org/13027721:12
dtturnerraildo: 8000 and 8004 for heat endpoints.  Different IP for heat and mistral endpoints.21:13
raildodtturner, but that is the same in the endpoint?21:13
*** gyee has joined #openstack-keystone21:14
dtturnerraildo, yes.21:14
dtturnerraildo: Looking at output of keystone endpoint-list now.21:15
*** lhcheng_ has quit IRC21:16
raildocan you paste the output?21:17
dtturnerraildo, sure: http://paste.openstack.org/show/132546/21:23
raildotks21:23
*** shakamun_ has quit IRC21:26
*** marg7175 has quit IRC21:27
raildodtturner, this is very weird, maybe you can find the error in the configuration files21:29
raildokeystone stored correctly the endpoints21:29
*** shakamunyi has joined #openstack-keystone21:30
dtturnerraildo, this started upon adding the Mistral service.  Users reported issues with Heat at the same time.  If I stop Mistral, the issues with Heat go away.  I've been banging my hang trying to see how this is happening.21:30
*** samuelms-home has joined #openstack-keystone21:31
raildoMaybe someone has changed any global variable, or something like that21:32
*** lhcheng has joined #openstack-keystone21:33
*** raildo has quit IRC21:36
*** Viswanath has joined #openstack-keystone21:36
rodrigodsayoung, ping21:36
ayoung$ ping ayoung21:37
ayoungping: unknown host ayoung21:37
rodrigodshaha21:37
gyee /join ayoung21:37
rodrigodsayoung, just saw the "kilo graduation plans" ml thread for oslo21:37
rodrigodspolicy was supposed to be there?21:38
ayoungand I just realized I did none of the things I needed to do today21:38
ayoungyes, policy is supposed to be there21:38
gyeewhat's up with the common SDK?21:38
gyeeare we deprecating all the python-*clients?21:39
rodrigodsayoung, but it isn't =/21:39
rodrigodsgyee, thought the SDK intention was to be used by other systems, besides openstack services21:40
*** Viswanath has quit IRC21:40
rodrigodsso you would't need to import separate clients21:40
*** Viswanath has joined #openstack-keystone21:41
gyeewe already have to common CLI21:42
gyees/to/the21:42
*** thiagop has quit IRC21:43
samuelms-homemorganfainberg, just to keep you updated of the things of exposing the ids of parents / subtree21:43
samuelms-homemorganfainberg, in fact we're exposing all project info (name, description) :p21:43
*** sbasam has quit IRC21:43
samuelms-homemorganfainberg, and then nkinder pointed out that this may be a problem21:43
morganfainbergthat sound like an issue21:44
morganfainbergids, not as much21:44
*** marg7175 has joined #openstack-keystone21:44
samuelms-homemorganfainberg, we'll get back on this discussion soon :-)21:44
*** Viswanath has quit IRC21:44
rodrigodsmorganfainberg, samuelms, we have put some thoughts on it here, we have a bit ugly solution21:46
rodrigodswe can discuss later, when they are back21:46
*** zzzeek has quit IRC21:54
*** zzzeek has joined #openstack-keystone21:54
*** marg7175_ has joined #openstack-keystone21:56
morganfainbergrodrigods, sounds good21:58
*** marg7175 has quit IRC21:59
*** amcrn has quit IRC22:04
*** samuelms-home has quit IRC22:04
*** joesavak has quit IRC22:16
openstackgerritMerged openstack/pycadf: Add classifiers for Python 3  https://review.openstack.org/13308822:17
*** gokrokve has quit IRC22:18
*** patrickeast has joined #openstack-keystone22:21
*** nellysmitt has quit IRC22:22
*** edmondsw has quit IRC22:22
*** marg7175_ has quit IRC22:23
*** topol has quit IRC22:25
openstackgerritLance Bragstad proposed openstack/keystone: Move functional tests to keystone/tests/functional  https://review.openstack.org/13355622:26
*** marg7175 has joined #openstack-keystone22:27
openstackgerritLance Bragstad proposed openstack/keystone: Move test_utils to keystone/tests/unit/  https://review.openstack.org/13398922:31
*** patrickeast has quit IRC22:34
rodrigodsayoung, the oslo.policy lib spec is this one: https://review.openstack.org/#/c/133480/2/specs/keystoneclient/policy-enforce.rst, right?22:35
*** patrickeast has joined #openstack-keystone22:35
ayoungrodrigods, partially, but not completely22:35
ayoungrodrigods, it means pulling in a bit more code...let me show what nova does22:36
ayoungWell, what Keystone does, but I like nova's approach as a starting point for other reasons...22:36
ayoungrodrigods, http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/controller.py#n85  is the decorator22:36
rodrigodsayoung, cool, managed to put some tasks regarding those policies, will split them22:36
ayoungand then a lot of the work is done in http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/authorization.py22:37
ayoungrodrigods, in nova it is a deliberate call, not a decorator, but the general work is the same:22:37
ayoungget the token and other data into a format that we can then use to check and enforce policy22:38
ayoungrodrigods, http://git.openstack.org/cgit/openstack/nova/tree/nova/policy.py  is the most of it22:39
rodrigodsayoung, cool, so in the ml thread, dhellmann asked for a spec and I thought that one would be the right place22:40
ayoungrodrigods, actually, we are doing a lot more in Keystone than most of the other projects, because we sometimes have to build up the auth data directly from the database.  However, a library based approach would not need that; getting the auth data would either done from middleware or would be service specific22:40
ayoungYou kjnow what, yeah, use that spec22:41
ayoungits close enough, and we can always expand on what we need to do beyond just the oslo work22:41
rodrigodsayoung, great22:41
rodrigodsthanks for the quick explanation22:41
*** tellesnobrega_ has joined #openstack-keystone22:44
*** marekd is now known as marekd|away22:57
*** thedodd has quit IRC22:58
*** marg7175 has quit IRC22:58
*** marg7175 has joined #openstack-keystone23:02
*** browne has quit IRC23:04
*** browne has joined #openstack-keystone23:04
*** marcoemorais1 has joined #openstack-keystone23:05
*** _cjones_ has quit IRC23:06
*** _cjones_ has joined #openstack-keystone23:09
*** marcoemorais has quit IRC23:09
*** amcrn has joined #openstack-keystone23:12
*** david-lyle is now known as david-lyle_afk23:12
*** nkinder has quit IRC23:18
*** tellesnobrega_ has quit IRC23:20
*** marcoemorais1 has quit IRC23:30
*** marcoemorais has joined #openstack-keystone23:31
*** marg7175 has quit IRC23:32
*** patrickeast has quit IRC23:32
*** patrickeast has joined #openstack-keystone23:33
*** tellesnobrega_ has joined #openstack-keystone23:35
*** nkinder has joined #openstack-keystone23:43
*** tellesnobrega_ has quit IRC23:45
*** kobtea has joined #openstack-keystone23:47
*** kobtea has quit IRC23:52
*** dims_ has joined #openstack-keystone23:54
*** gokrokve has joined #openstack-keystone23:56
*** dims has quit IRC23:57
*** shakamunyi has quit IRC23:58
*** shakamunyi has joined #openstack-keystone23:58
*** nkinder has quit IRC23:59

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