Monday, 2014-06-02

*** pheadron has quit IRC00:51
*** ncoghlan has joined #openstack-keystone00:52
*** topol has joined #openstack-keystone00:57
*** bknudson has left #openstack-keystone01:01
*** ayoung-ZZzz is now known as ayoung01:08
*** pheadron has joined #openstack-keystone01:09
ayoungjamielennox, I was thinking that we should probably keepo the "kerberos"  Client plugin setting the "methdo" value to "external"  as that way it works with the existing documentation we've been writing about Kerberos.  The people that will want it the most are the people with existing kerberos setups01:09
ayoungand they will not have the flexibility to upgrade Keystone to use "kerberos" as the method in the short run01:09
jamielennoxayoung: so at what point do we move away from 'external'?01:09
ayoungNever?01:10
ayoungIf we ever decide to push for a Kerberos in Eventlet solution?>01:10
ayoungWhich I don't want to do, and Jose is OK with putting off?01:10
jamielennoxayoung: the people who currently have kerberos working aren't using the 'external' method anyway - because external is run regardless of the information in the auth body01:11
ayoungjamielennox, they don't have client support at all, or only custom01:11
jamielennoxright - but we aren't changing them too 'kerberos', the people with the current setup won't change01:11
jamielennoxwe're saying for new deployments you should enable the kerberos plugin01:12
jamielennoxwhich will be exactly the same as the basic auth plugin if that ever happens01:12
ayoungjamielennox, what I am saying is that we need kerberos support in the client, and we need it soon01:12
ayoungso you think we should push for that?01:12
ayoungmethod=kerberos?01:13
jamielennoxyes01:13
ayounghttps://review.openstack.org/#/c/95989/01:13
jamielennoxayoung: cool, i think you should assert AuthType == 'Negotiate'01:15
ayoungInteresting.  THat comes through in the env vars, I take it?01:15
jamielennoxyes01:15
jamielennoxAUTH_TYPE i think01:16
jamielennoxand we are saying there that KerberosDomain will be a plugin listed with the others - not external=KerberosDomain01:16
jamielennoxie token,password,kerberos,external01:17
ayoung?01:17
ayoungjamielennox, ah, yes...please annotate all in the review.01:17
ayoungI'll redo it tomorrow.01:17
jamielennoxcool, sounds good01:18
jamielennoxayoung: in future i like the idea of a 'landing page' for everything that doesn't go through the standard /auth/token URL so that kerberos would be more like the federated plugins - but this is a good step01:19
ayoungjamielennox, so...I was also thinking about trying to pull the auth stuff out of the existing past pipeline and put it in its own...not sure what that would take.01:21
*** xianghui has joined #openstack-keystone01:22
jamielennoxout of paste?01:22
ayoungIt might be that we need to have a paste pipeline for each of the modules01:22
ayoungno leave it in past, just its own pipeline01:22
ayounghttp://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone-paste.ini#n8801:22
jamielennoxi've definetly heard this concept before - in theory i like it01:23
ayounginstead of that going to /auth/token  you would have a separate pipeline, and it could be how we throw different things in there01:23
ayoungI have to learn more about paste.01:23
jamielennoxso i agree with morganfainberg that we should move /v3/auth/token so that it's not /v3 and we can seperate crud API version from token API version01:23
ayoungI would like to take the standard pipeline filters and make on reusuable config for them,01:23
jamielennoxand once you've done that a new paste pipeline becomes easier01:23
ayoungso  AUTH_URL  can point to anything...doesn't have to have /v3 in it?01:24
jamielennoxso we can do like keystone:5000/auth/v4 and keystone:5000/v3/users01:24
jamielennoxyou can already mix and match token versions with API versions, so we make them two seperate things01:25
ayoungjamielennox, so we can vary the API for /auth  /user  and so forth...hmmm01:25
ayoungshould be top level modules01:25
jamielennoxayoung: not users01:25
jamielennoxusers is still a v3 concept01:26
ayounglike this /auth /identity   /assignment  /policy01:26
ayoung?01:26
jamielennoxit's just extracting the token producing part of the code into it's own top level01:26
ayoungjamielennox, what would be the new set of "top levels"  then?01:26
jamielennoxsuch that we can have a new token format without having to redo our entire CRUD UI01:26
jamielennoxv2 v3 auth i guess, it would depend on what you need to do as to whether auth/v2 and auth/v3 would need there own pipelines01:27
jamielennoxthe word /auth may not be used01:28
ayoungjamielennox, I'm already on board that the AUTH_URL might be its own thing...cuz you would want to protect it separately in HTTPD.  But you'd still want v3 and v4 together, I' guessing01:30
ayoungIt would be decent if we could figure out a way to get the V3  pieces to work along with that scheme01:31
ayoungit should be possible01:31
jamielennoxayoung: yea not sure, i'd have to see it in practice01:31
ayoungI mean, there is no reason the same thing can't be mounted under :35357/v3  and :35357/identity01:32
ayounghave you messed around with that JSON HOME approach yet?01:32
jamielennoxayoung: no, i don't have any particular interest in that one yet01:33
jamielennoxayoung: it doesn't give us any new information over what we already expose, it's just another new format01:34
jamielennoxand there's still been no official adoption of it yet - just a project or two using it01:34
ayoungIt was my understanding that  it gives us discovery from the top down?01:34
jamielennoxwe could have worked that into our existing discovery01:34
jamielennoxit's been a while since i looked01:34
jamielennoxbut i don't remember it giving us resources etc01:35
jamielennoxoh it does - that's cool01:35
ayoungyeah, that seems to  be the primary thing it does01:36
jamielennoxbut i still haven't looked at it, there's enough formats i'm fighting with already01:36
ayoungyeah...same here.  I'm mostly working on getting the Kerberization of Horizon kicked off... had some success with S4U2Proxy last week.01:37
jamielennoxhmm, that will be cool - there are no python libraries or anything for it, i don't know how to work it in but that should be interesting01:38
jamielennoxpecan will be cool there01:39
jamielennoxayoung: as in it will work without co-locating keystone and horizon?01:42
ayoungright, you log in to horizon, and then horizon talks to a remote keystone01:44
ayounghorizon uses your service ticket, and its own keytab, to get a service ticket against keystone on your behalf01:44
ayoungvery similar to the rule of trusts.01:45
jamielennoxexcellent, i just know you had talked about simplifying the interaction as a first step01:46
ayoungjamielennox, so I need a keystoneclient that I can stick into horizon.  I'm using a modified one right now for coding and testing01:46
jamielennoxok, that's why you're pushing this kerberos auth then01:46
ayoungbut looks like we'll need to upgrade the appraoch in Keystone, which is cool01:47
ayoungyeah, just want to make sure we have a coherent approach01:47
ayoungI'm OK waiting for the Kerberos change in Keystone to go through, just want to make sure it is a deliberate decision01:47
ayoungand not "oh, though would be nice"01:47
ayoungjamielennox, I posted about hte S4U2 Proxy on my blog last week.  Its pretty straightforward, but it does lead to some questions about Horizon in the Non Kerberos cases...like SAML01:49
ayounghttp://adam.younglogic.com/2014/05/kerberos-federation-and-horizon/01:49
ayoungLIke:  If I use SAML, and end up at Horizon, can horizon take the SAML assertion and forward it to Kerberos with any degree of actual security?01:50
ayoungAnd what about if they are using X509 Client certs instead of Kerberos?  What is the delegation story there?01:50
*** stevemar has joined #openstack-keystone01:56
*** dims has quit IRC01:57
*** diegows has quit IRC01:59
*** dims has joined #openstack-keystone01:59
*** dims has quit IRC02:00
ayoungjamielennox, BTW...  https://github.com/admiyo/keystone-examples02:02
jamielennoxayoung: oh, nice - i've had a bunch of little scripts i've thought i should put somewhere02:02
ayoungGive em to me, I'll post em02:08
ayoungOr clone my repo and we can share them....git hub is perfect for that02:09
ayoungjamielennox, yeah, lets start using git hub for  that...02:10
ayoungI think its the right level tool for the goal:02:10
*** Chicago has quit IRC02:14
*** ayoung is now known as ayoung-ZZzz02:16
*** stevemar has quit IRC02:22
*** stevemar has joined #openstack-keystone02:22
*** ncoghlan is now known as ncoghlan_afk02:24
*** dstanek_zzz is now known as dstanek02:25
*** ncoghlan_afk is now known as ncoghlan02:46
*** mberlin1 has joined #openstack-keystone02:54
*** ncoghlan is now known as ncoghlan_afk02:57
*** mberlin has quit IRC02:57
*** gokrokve has joined #openstack-keystone03:09
*** gokrokve has quit IRC03:14
*** stevemar has quit IRC03:18
*** lbragstad has joined #openstack-keystone03:23
*** harlowja_ is now known as harlowja_away03:47
*** dstanek is now known as dstanek_zzz03:49
*** zhiyan_ is now known as zhiyan03:54
*** henrynash has joined #openstack-keystone04:20
*** ncoghlan_afk is now known as ncoghlan04:36
*** gokrokve has joined #openstack-keystone04:41
openstackgerritBrad Topol proposed a change to openstack/keystone: Add instructions for removing pyc files to docs  https://review.openstack.org/9714004:43
*** Abhijeet has joined #openstack-keystone04:56
morganfainbergtopol, shouldn't you be asleep or something? :P04:57
topolmorganfanberg, this is my quiet get to have fun time.04:59
morganfainbergtopol, you want to review code for me while you're at it? sometimes i question my sanity when i commit to reviewing code over the weekend05:00
topolmorganfainberg, sure05:00
* morganfainberg smirks.05:01
*** ncoghlan is now known as ncoghlan_afk05:03
*** ncoghlan_afk is now known as ncoghlan05:03
*** gokrokve has quit IRC05:06
*** ajayaa has joined #openstack-keystone05:17
openstackgerritBrad Topol proposed a change to openstack/keystone: Add cloud auditing notification documentation  https://review.openstack.org/9714605:42
topolmorganfainberg, I feel like a contributor again... Im going to bed05:43
morganfainberghehe05:43
morganfainbergnight dude05:43
*** topol has quit IRC05:49
*** leseb has joined #openstack-keystone05:49
openstackgerritOpenStack Proposal Bot proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/9700506:00
*** leseb has quit IRC06:09
ajayaaHi. When I do os endpoint list I don't see endpoint with v3 address. But I am able to call v3 api06:10
ajayaaIs it expected behaviour?06:11
*** leseb has joined #openstack-keystone06:13
*** jimbaker has quit IRC06:17
*** tomoiaga has joined #openstack-keystone06:38
*** afazekas has quit IRC06:49
openstackgerritAndreas Jaeger proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/9700507:03
*** leseb has quit IRC07:04
*** leseb has joined #openstack-keystone07:05
*** praneshp has joined #openstack-keystone07:06
*** BAKfr has joined #openstack-keystone07:16
marekdmhu: hello. IN your PoC are you lookin at OpenID 2.0 or OpenID Connect protocol?07:32
marekdmhu: I think OpenId 2.0 was superseded by OpenId Connect.07:33
*** ncoghlan is now known as ncoghlan_afk07:40
*** ncoghlan_afk is now known as ncoghlan07:43
*** toddnni has quit IRC07:46
*** toddnni has joined #openstack-keystone07:46
*** nsquare has quit IRC07:47
*** huats has quit IRC07:48
*** huats has joined #openstack-keystone07:49
*** huats has quit IRC07:49
*** huats has joined #openstack-keystone07:49
*** jaosorior has joined #openstack-keystone07:50
*** leseb has quit IRC07:53
*** leseb has joined #openstack-keystone08:01
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Add information regarding HTTPS for SSL enabled endpoints  https://review.openstack.org/9554508:05
*** ncoghlan has quit IRC08:06
*** florentflament has joined #openstack-keystone08:21
*** _afazekas has joined #openstack-keystone08:24
-openstackstatus- NOTICE: setuptools upstream has broken the world. it's a known issue. we're hoping that a solution materializes soon08:31
*** ChanServ changes topic to "setuptools upstream has broken the world. it's a known issue. we're hoping that a solution materializes soon"08:31
*** _afazekas is now known as afazekas08:36
*** leseb has quit IRC08:36
*** andreaf has joined #openstack-keystone08:37
*** leseb has joined #openstack-keystone08:41
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421408:44
*** leseb_ has joined #openstack-keystone08:51
*** leseb has quit IRC08:51
*** henrynash has quit IRC08:59
*** praneshp has quit IRC09:16
*** ajayaa has quit IRC10:12
*** leseb_ has quit IRC10:24
*** ajayaa has joined #openstack-keystone10:36
*** ajayaa has quit IRC10:42
*** leseb has joined #openstack-keystone10:46
*** leseb has quit IRC10:57
*** ukalifon1 has joined #openstack-keystone11:01
*** leseb has joined #openstack-keystone11:09
*** ukalifon1 has quit IRC11:11
*** zhiyan is now known as zhiyan_11:19
*** zhiyan_ is now known as zhiyan11:20
*** diegows has joined #openstack-keystone11:27
*** hrybacki has quit IRC11:27
*** ajayaa has joined #openstack-keystone11:32
*** henrynash has joined #openstack-keystone11:39
*** Abhijeet has quit IRC11:41
*** leseb has quit IRC11:43
*** leseb has joined #openstack-keystone11:51
*** erecio has joined #openstack-keystone12:10
*** dims has joined #openstack-keystone12:12
*** xianghui has quit IRC12:13
*** tomoiaga1 has joined #openstack-keystone12:14
*** tomoiaga has quit IRC12:14
*** tomoiaga1 is now known as tomoiaga12:16
*** dims has quit IRC12:23
*** gordc has joined #openstack-keystone12:27
*** henrynash has quit IRC12:28
*** hrybacki has joined #openstack-keystone12:28
*** dims has joined #openstack-keystone12:30
*** dims has quit IRC12:32
*** dims has joined #openstack-keystone12:32
*** rodrigods has joined #openstack-keystone12:33
*** rodrigods has joined #openstack-keystone12:33
*** radez_g0n3 is now known as radez12:43
*** henrynash has joined #openstack-keystone12:57
openstackgerritJuan Manuel Ollé proposed a change to openstack/keystone: Adding Role for an unexisting user should fail.  https://review.openstack.org/9398212:58
openstackgerritJuan Manuel Ollé proposed a change to openstack/keystone: Adding Role for an unexisting user should fail.  https://review.openstack.org/9398212:59
*** ayoung-ZZzz is now known as ayoung13:01
*** ericvw has joined #openstack-keystone13:02
*** samuelmz_ is now known as samuelmz13:10
*** nkinder has quit IRC13:13
samuelmzayoung, ping13:19
ayoungsamuelmz, ping: unknown host ayoung13:19
samuelmzayoung, :D13:19
samuelmzayoung, I'd like to discuss with you about keystone default roles when using devstack13:20
samuelmzayoung, I think there is an inconsistence and I'd like to know what you think about it13:20
ayoung64 bytes from ayoung (127.0.0.1): icmp_seq=1 ttl=64 time=0.040 ms13:20
*** topol has joined #openstack-keystone13:21
ayoungsamuelmz, write away...I'm listening...er....actively coming  back to read what you write....13:21
samuelmzayoung,  when using devstack to install OS, it sets iniset operator_roles to  'Member' and 'admin' with 'iniset ${SWIFT_CONFIG_PROXY_SERVER} filter:keystoneauth operator_roles "Member, admin"' at https://github.com/cloudbuilders/devstack/blob/master/lib/swift13:21
samuelmzayoung, It may cause an inconsistence in some cases: suppose a cloud admin grants the '_member_' role to a user... then he will not be able to properly use swift13:22
samuelmzayoung, for me, having Member and _member_ roles is inconsistent13:22
*** topol has quit IRC13:24
*** joesavak has joined #openstack-keystone13:24
ayoungsamuelmz, then change the member role in keystone config13:28
ayoungsamuelmz, http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n6913:29
samuelmzayoung, but devstack should consider a single member role, shouldn't? I don't know what is the best place to talk about devstack issues..13:29
*** bknudson has joined #openstack-keystone13:30
ayoungsamuelmz, we created _member_ specifically so it doesn't conflict with existing roles. a User could easily have _member and Member13:30
samuelmzayoung, do they have different semantics? I don't see any reason for having both of them13:31
*** gordc has quit IRC13:32
ayoungsamuelmz, it was due to a migration issue13:32
ayoung we had users assigned directly to projects13:32
ayoungthus two different mechanisms for associating users with projects13:32
ayoungif we blindly made everyone that was "in" a project a "Memeber" of the project we would have been stepping on Swift semantics13:33
samuelmzayoung, as I said, devstack consider Member and admin roles for using swift.. in our private OS cloud, the cloud admin just assigned _member_ to me and then I wasnt able to use swift ..13:33
ayoungsamuelmz, were you able to use it before?13:34
samuelmzayoung, no13:34
samuelmzayoung, but he assigned Member role to me ( != _member_ ), then I became able to use it13:34
*** gordc has joined #openstack-keystone13:35
ayoungsamuelmz, that is a swift issue, then13:35
samuelmzayoung, if you have reasons for having both _member_ and Member, at least devstack should consider both as swift operator_roles13:35
ayoungsamuelmz, there is, as of now, no "standard set of roles" for OpenStack13:35
ayoung_memeber_ was a migration tool13:36
samuelmzayoung, ok13:37
samuelmzayoung, I just do not agree with the way devstack set roles ..13:37
*** stevemar has joined #openstack-keystone13:37
samuelmzayoung, so I think it's a bug in the devstack configuration of OS13:37
rodrigodsayoung, samuelmz or a hardcoded check in Swift for Member role? =)13:38
ayoungsamuelmz, morganfainberg I need to step away from the keyboard.13:38
*** ayoung is now known as ayoung-afk13:38
samuelmzayoung-afk, ok thanks13:38
morganfainbergnp i need to take a break.13:38
marekdmorganfainberg: what time do you have, 6:30?  you are still awake or already awake?13:42
morganfainbergalready awake, but i need to meet someone for lunch today, so gonna head to a coffee shop.13:43
*** jimbaker has joined #openstack-keystone13:43
*** jimbaker has quit IRC13:43
*** jimbaker has joined #openstack-keystone13:43
*** daneyon has joined #openstack-keystone13:44
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Fix tests to use UUID strings rather than ints for IDs  https://review.openstack.org/9062114:00
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Escape strings in URLs  https://review.openstack.org/6613714:00
*** codemonkey_ has joined #openstack-keystone14:01
*** codemonkey_ has left #openstack-keystone14:01
*** codemonkey_ has joined #openstack-keystone14:03
*** codemonkey_ has quit IRC14:05
openstackgerritBrant Knudson proposed a change to openstack/keystone: Add v3 curl examples  https://review.openstack.org/9697314:05
openstackgerritBrant Knudson proposed a change to openstack/keystone: Fix curl example refs in docs  https://review.openstack.org/9696614:05
*** nkinder has joined #openstack-keystone14:06
*** codemonkey_ has joined #openstack-keystone14:07
*** afazekas has quit IRC14:12
*** ajayaa has quit IRC14:12
*** codemonkey_ has quit IRC14:13
*** ChanServ changes topic to "J1 Milestone June 12th! J2 and beyond blueprints require a formalized spec doc: https://git.openstack.org/cgit/openstack/keystone-specs | Please review the proposed specs."14:16
-openstackstatus- NOTICE: setuptools issue was fixed in upstream in 3.7.1 and 4.0.1, please, recheck on bug 132551414:16
*** mgagne has joined #openstack-keystone14:17
*** afazekas has joined #openstack-keystone14:27
*** afazekas has quit IRC14:38
*** andreaf has quit IRC14:40
openstackgerritEric N. Vander Weele proposed a change to openstack/keystone: Add documentation on LDAP 'user_id_attribute'  https://review.openstack.org/9348014:42
*** afazekas has joined #openstack-keystone14:50
*** david-lyle has joined #openstack-keystone14:51
*** vhoward has joined #openstack-keystone14:55
*** tomoiaga has quit IRC14:55
*** daneyon has quit IRC14:57
*** pafuent has joined #openstack-keystone15:03
pafuentHi. I'm using the V3 client and I'm getting this error: http://paste.openstack.org/show/82447/. I checked the code and seems that the HTTPClient is not setting the auth_url keyword argument. Is that a bug or I'm not using the Keystone client properly?15:09
*** smckinney has joined #openstack-keystone15:11
*** smckinney has left #openstack-keystone15:12
*** smckinney has joined #openstack-keystone15:15
*** dc has joined #openstack-keystone15:24
*** morganfainberg is now known as morganfainberg_Z15:25
dcare there security implications to having multiple users in a tenant?15:25
*** ayoung-afk is now known as ayoung15:25
ayoungdc, probably a somewhat.15:29
ayoungdc the RBAC policy is not enough to keep on user from creating a VM and another destroying it, for example15:29
dcayoung: I am implementing keystone with swift. When would you want to have users in the same tenant and when would you want to separate it?15:30
ayoungdc No idea.15:30
ayoungdc It really is based on a lot of factors15:30
ayoungdc when you want to share the administration of virtual machines ,put them in the same project.15:30
smckinneyhello, this is shawn, I met some of you in atlanta15:35
smckinneywanted to reiterate my interest in participating in the authorization work being done in keystone15:36
ayoungsmckinney, welcom aboard15:36
smckinneythanks15:36
ayoungI know there was a lot of stuff we discussed about policy and RBAC....I think there are two trends15:36
ayoung1 is to make better use of the existing mechanisms15:37
ayoung2 is to make them more usable15:37
smckinneywell I have a shovel, need to know where to start digging15:38
ayoungHeh15:38
ayoungsmckinney, well...one thing I'd love someone to look at is...(looking for Blueprint)15:39
ayounghttps://blueprints.launchpad.net/keystone/+spec/endpoint-policy15:40
smckinney(looking at now)15:40
ayoungsmckinney, the short of it is that there is a policy repo in Keystone, but no one is using it15:40
ayoungbecause you can only fetch policy by ID, not by context15:40
pafuentHi. I'm using the V3 client and I'm getting this error: http://paste.openstack.org/show/82447/. I checked the code and seems that the HTTPClient is not setting the auth_url keyword argument. Is that a bug or I'm not using the Keystone client properly?15:42
ayoungpafuent, not using client properly15:43
ayoungpafuent, client needs to know where to get a token in the first place15:43
ayoungnothing else can work without that15:43
pafuentayoung: The thing that I'm not getting is why the HTTPClient is not storing internally the parameter auth_url that I'm passing during the client creation15:44
pafuentayoung: keystone_client.Client(**kwargs)15:45
pafuentayoung: kwargs contains auth_url15:45
ayoungpafuent, really?  Weird15:45
ayoungI'd have to look deeper15:46
smckinneyayoung, by context you mean subject (principal) ?15:46
pafuentayoung: OK. Thanks.15:46
*** leseb has quit IRC15:48
*** gyee has joined #openstack-keystone15:53
*** gokrokve has joined #openstack-keystone15:56
*** leseb has joined #openstack-keystone15:57
*** zhiyan is now known as zhiyan_15:57
*** gokrokve has quit IRC16:04
*** browne has joined #openstack-keystone16:08
smckinneyayoung, er - tenant ?16:11
ayoungsmckinney, not project (tenant) but rather service or endpoint16:11
ayoungprojct would be follow on16:11
smckinneyok, let me do some homework/research16:12
ayoungsmckinney, I intrigued by the idea of per-project policy, but also a little leary of it16:12
ayoungI could see it really easy to lock   a project so you could do nothing with it16:13
ayoungand undoing that would leave it "open wide"16:13
smckinneyshould always fail closed16:13
ayoung?16:13
smckinneybest practice for MAC (mandatory access control) is to fail closed - not open16:14
smckinneythink how unix does it as opposed to windows16:14
ayoungsmckinney, No, I ge that. but  afterwads, if you are resetting the policy on a project, you have to remove some aspect of the project specific policy16:14
*** packet has joined #openstack-keystone16:14
ayoungso if you had an expectation that people need an extra role to do something, and there is no one with that role, nothing can be done16:15
ayoungbut if you remove that restriction, everything can be done.16:15
ayoungsmckinney, I think stackable policy is "a bridge too far" for Juno16:15
ayoungbut the "fetch policy for endpoint" call  could be done easily16:16
ayoungand is a good starting point16:16
smckinneyagreed16:16
smckinneyit will take me a while to get acclimated16:16
ayoungof course.  Let me know if you get stuck16:16
smckinneyok16:17
*** jaosorior has quit IRC16:22
*** topol has joined #openstack-keystone16:26
*** pafuent has left #openstack-keystone16:30
*** marcoemorais has joined #openstack-keystone16:32
*** BAKfr has quit IRC16:35
*** shakamunyi has joined #openstack-keystone16:36
*** radez is now known as radez_g0n316:41
*** morganfainberg_Z is now known as morganfainberg16:44
*** daneyon has joined #openstack-keystone16:46
*** rwsu has joined #openstack-keystone16:46
*** afazekas has quit IRC16:51
*** florentflament has quit IRC16:52
*** harlowja_away is now known as harlowja_16:54
*** andreaf has joined #openstack-keystone16:54
*** sbfox has joined #openstack-keystone17:04
openstackgerritRichard Megginson proposed a change to openstack/keystone: test_user_mixed_case_attribute fails - mail, not email  https://review.openstack.org/9466817:21
openstackgerrithenry-nash proposed a change to openstack/keystone: multi-backend support for identity  https://review.openstack.org/7421417:24
*** nsquare has joined #openstack-keystone17:27
henrynashdolphm: ping17:29
dolphmhenrynash: pong17:30
*** dims has quit IRC17:30
henrynashdolphm: Hi…could you remove your -2 from https://review.openstack.org/#/c/74214/17:30
henrynashdolphm: assuming that was there to block release into IceHouse?17:30
dolphmhenrynash: done17:31
dolphmhenrynash: going to have to propose a -spec for it though!17:31
henrynashdolphm: really? I thought if we landed this in J-1 we were Ok?17:32
*** gokrokve has joined #openstack-keystone17:32
henrynashdolphm: if it’s felt we need a spec, sure I’ll create on of course17:32
dolphmhenrynash: if you think it'll land in j1!17:32
henrynashdolphm: if it doesn’t…..I’ll create a spec…no issue17:33
dolphmhenrynash: i think a spec would be beneficial regardless, just not mandatory for j117:33
henrynashdolphm: I think I agree….I’ll write one up anyway17:34
*** sbfox has quit IRC17:34
*** amcrn has joined #openstack-keystone17:35
morganfainbergyay specs~17:35
*** sbfox has joined #openstack-keystone17:36
*** gokrokve has quit IRC17:45
*** gokrokve has joined #openstack-keystone17:45
ayounghrybacki, I'm not certain who else is looking into json-schema validation, but I am sure someone in here is17:50
morganfainbergayoung, hrybacki, i think stevemar, jamielennox are both. and I will be for some things.17:50
hrybackiayoung, nods17:50
ayoungmorganfainberg, which library we looking at?17:50
openstackgerritSteve Martinelli proposed a change to openstack/keystone: Invalid command referenced in federation documentation  https://review.openstack.org/9729817:51
morganfainbergayoung, sorry was lbragstad not stevemar https://review.openstack.org/#/c/95957/17:51
stevemardolphm, morganfainberg easy review ^^17:51
ayounghrybacki, there ya go17:52
stevemarmorganfainberg, yes, it's lbragstad17:52
hrybackiayoung, morganfainberg++17:52
morganfainbergstevemar, ouch. missed "install" there really?17:52
stevemarmorganfainberg, indeedy17:52
lbragstado/17:53
openstackgerritRichard Megginson proposed a change to openstack/keystone: ldap/core deleteTree not always supported  https://review.openstack.org/7489717:55
marekdjamielennox: o/ Accoding to the docstring here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/session.py#L34 if I actually want to use requests.Session I must pass it in the keystoneclient.session.Session() constructor, right?17:56
*** dims has joined #openstack-keystone17:56
lbragstadmorganfainberg: quick question here: https://review.openstack.org/#/c/95976/4/specs/juno/non-persistent-tokens.rst17:57
morganfainberglbragstad, sure17:57
*** sbfox has quit IRC17:57
lbragstadin the Data Model Impact section, do we just need to know that a migration is needed or should information be included for how that migration will be handled?17:58
lbragstadmodifying an existing table, or creating a new table for example17:58
bknudsonlbragstad: I'd expect the schema to be there.17:58
lbragstadI think the reason  I would agree would be that it would help detail the backward compat path too17:58
morganfainberghm.17:59
lbragstadEx. this is how we plan to suppor the old way, and with the fancy new migration, we plan to deliver XYZ...17:59
lbragstadjust curious if we were going into that kind of detail.. which could be tough given how mature the blueprint idea is... Maybe we don't know how we want to handle the migration, but we know we need one.18:00
morganfainberglbragstad, i don't think we'll get anything in this cycle with that depth18:00
bknudsonif there's a schema then it's obvious that a migration will be required18:00
bknudsonare there any nova specs that have an example?18:00
lbragstadchecking18:01
* morganfainberg goes and looks18:01
*** dims has quit IRC18:01
*** marcoemorais1 has joined #openstack-keystone18:01
* lbragstad nova has a lot of specs18:01
morganfainberghttps://github.com/openstack/nova-specs/blob/master/specs/juno/better-support-for-multiple-networks.rst#data-model-impact18:01
morganfainbergnot very detailed18:02
*** marcoemorais1 has quit IRC18:02
ayounghrybacki, stevemar18:02
ayounghttps://etherpad.openstack.org/p/sample-user-json-schema18:02
*** marcoemorais1 has joined #openstack-keystone18:02
*** marcoemorais has quit IRC18:02
bknudsonwhy even have a data model section if it's not going to provide any info18:03
bknudsondoesn't seem like it's that hard to put some DDL in there.18:03
morganfainbergbknudson, data model could be two things, object structure / class, and SQL schema18:04
lbragstadhttps://github.com/openstack/nova-specs/blob/master/specs/juno/extensible-resource-tracking.rst#data-model-impact18:04
bknudsonmorganfainberg: nova has database objects, so maybe that's what they're referring to.18:04
morganfainbergbknudson, ++ perhaps.18:05
bknudsonalso we've got an ldap backend so should describe how the feature is going to work with that18:06
stevemarayoung, i think lbragstad has a json schema for most keystone entities18:06
morganfainbergbknudson, i'm ok with seeing how it goes as is and requiring DDL if its needed down the line. this one is going to be a lot more rigid than before because i'm going to be converting the ... token format up for that18:06
ayounghrybacki, edit your name in there18:06
ayoungstevemar, of course he does...18:06
stevemarlbragstad, https://etherpad.openstack.org/p/sample-user-json-schema18:06
morganfainbergbknudson, in this case no LDAP, but i'd agree for assignment stuff18:06
morganfainbergbknudson, and/or idenitty18:06
ayounglbragstad, you have these laid out already?18:07
lbragstadayoung yep some18:07
* lbragstad grabs link18:07
lbragstadayoung something similar to https://review.openstack.org/#/c/96266/4/keystone/catalog/schema.py18:07
ayounglbragstad, any for identity?18:09
lbragstadayoung no, only for assignment and catalog at the moment18:09
stevemarayoung, ahh, i gave you false info :(18:10
ayounghrybacki, recommend that you do a code review of  https://review.openstack.org/#/c/96266/4/keystone/catalog/schema.py  and ask lbragstad about anything you don't undertand.  Use the etherpad to document  the identity ones18:10
lbragstadwhich covers domain, project, role, regions, services, and endpoints18:10
hrybackiayoung, kk18:10
dolphmugh - i had made a bunch of unpublished/draft comments on a -spec on friday ... just went to go add a few more & publish and they all vanished :(18:10
dolphmapparently they expire now or something?18:10
dolphmaaand i refreshed and they all re-appeared. do not understand.18:11
morganfainbergdolphm, new patch?18:11
morganfainbergdolphm, loggedin/session timeout?18:11
dolphmmorganfainberg: nope, all on the exact same review/patchset/file18:11
lbragstaddolphm: lol is it because your gerrit account is messed up?18:12
dolphmmorganfainberg: my session had definitely expired in the interim, but i was logged in when they vanished18:12
dolphmlbragstad: i hope not!18:12
dolphmlbragstad: it was on your -spec too!18:12
morganfainbergdolphm, wierd18:12
lbragstaddolphm: you got them back so you can publish them right?18:13
*** dims has joined #openstack-keystone18:13
dolphmlbragstad: yep, give me just a few mins18:13
lbragstadcool18:13
dolphmlbragstad: reviewing them since it was late on friday :)18:13
lbragstadhrybacki: I tried pulling some of the more common schema validation types in a common place: https://review.openstack.org/#/c/86483/14/keystone/common/validation/parameter_types.py18:14
lbragstaddolphm: I've been guilty of that18:14
lbragstadhrybacki: so, feel free to leverage those18:15
hrybackilbragstad, looking over this too, thanks!18:15
lbragstadhrybacki: that way  if something changes in the future, it should minimize refactoring18:15
hrybackilbragstad++18:15
*** nkinder has quit IRC18:18
*** marcoemorais1 has quit IRC18:20
*** marcoemorais has joined #openstack-keystone18:20
dolphmbknudson: published18:26
*** amcrn has quit IRC18:27
morganfainbergbknudson, ping https://review.openstack.org/#/c/91677 - we can abandon this right? we're not doing rally on stable/* iirc?18:27
bknudsonmorganfainberg: abandoned. If we need it we can cherry-pick again.18:27
morganfainbergbknudson, ++18:28
bknudsonor restore it18:28
*** amcrn has joined #openstack-keystone18:28
bknudsondolphm: published what?18:29
dolphmbknudson: oh my bad. lbragstad: published!18:29
*** nkinder has joined #openstack-keystone18:29
lbragstaddolphm: addressing now...18:29
lbragstadthanks!18:29
lbragstaddolphm:  is there a way to change the blueprint in launchpad from keystone-api-validation to api-validation?18:30
morganfainberglbragstad, iirc no.18:30
lbragstadah yep...18:30
lbragstadthere is18:30
morganfainbergthere is?18:30
morganfainbergyou can chang ethe URL?18:30
lbragstadsweet https://blueprints.launchpad.net/keystone/+spec/api-validation18:30
morganfainbergoh neat..18:30
lbragstad'Change details'18:30
* morganfainberg grumbles about non-intuativeness of LP18:31
morganfainbergexcept where it is intuative18:31
lbragstadlol18:31
*** jaosorior has joined #openstack-keystone18:32
htrutastevemar: ping18:37
stevemarhtruta, pong,18:38
stevemari'm still waiting to hear back from dtroyer :(18:38
htrutastevemar: sad :(18:38
dolphmlbragstad: glad you found it :)18:40
*** openstackstatus has quit IRC18:50
*** openstackstatus has joined #openstack-keystone18:51
*** ChanServ sets mode: +v openstackstatus18:51
EmilienMHi there, any core could have a look at https://review.openstack.org/#/c/95601/ ? it's a backport to stable/icehouse18:52
morganfainbergEmilienM, the core team can look at it but dolphm and the stable maintenance team will the be people to can accept (cores can't approve/+2 code for stable/* releases)18:54
morganfainbergEmilienM, just as an FYI.18:54
EmilienMmorganfainberg: it makes sense18:54
EmilienMmorganfainberg: i just wanted ti highlight a patch which is here for some days...18:54
morganfainbergEmilienM, yeah stable takes a bit longer to get reviewed in some cases.18:55
EmilienMmorganfainberg: ok, I don't worry then.18:55
*** richm has joined #openstack-keystone18:56
morganfainbergEmilienM, added a couple people to the review specifically for you18:56
EmilienMmorganfainberg: awesome, thanks18:56
*** sbfox has joined #openstack-keystone18:56
openstackgerritRichard Megginson proposed a change to openstack/keystone: ldap/core deleteTree not always supported  https://review.openstack.org/7489718:58
*** tristanC has quit IRC19:03
morganfainbergayoung, dow e have a location where the start of FreeIPA is installed / packaged for ubuntu19:05
morganfainbergor... is that not available anywhere yet?19:05
ayoungmorganfainberg, I think it is in timo's repo or something19:06
morganfainberghm.19:06
morganfainbergok. /me goes hunting further19:06
ayounghttps://launchpad.net/~tjaalton19:06
ayoungmorganfainberg, https://launchpad.net/freeipa19:07
morganfainbergayoung, yeah client, sssd, and python stuff is all packaged19:08
morganfainbergbut the server seems to be missing19:08
ayounghmmm19:08
morganfainbergayoung, well not packaged yet?19:08
ayoungits somewhere19:09
ayoungmorganfainberg, what version Ubuntu you looking for?19:09
morganfainbergayoung, 14.04 or 12.0419:09
ayoungIs that Trusty?19:09
morganfainberg14.04 is19:09
* ayoung not keeping up19:09
ayounghttps://launchpad.net/ubuntu/trusty/+source/freeipa19:09
morganfainbergayoung, yeah looks like it is client only? https://launchpad.net/ubuntu/trusty/+source/freeipa/3.3.4-0ubuntu319:10
ayoungI thought they were in tjaalton's ppa19:11
morganfainbergayoung, nah his ppa doesn't have freeipa in it https://launchpad.net/~tjaalton/+archive/ppa19:12
*** marcoemorais has quit IRC19:12
ayoungmorganfainberg, he and I are chatting in #freeipa19:12
morganfainbergah let me join that19:12
*** praneshp has joined #openstack-keystone19:14
*** radez_g0n3 is now known as radez19:15
*** andreaf has quit IRC19:17
*** marcoemorais has joined #openstack-keystone19:22
*** leseb has quit IRC19:24
*** marcoemorais1 has joined #openstack-keystone19:26
*** bobt_ has joined #openstack-keystone19:27
*** marcoemorais1 has quit IRC19:27
*** marcoemorais2 has joined #openstack-keystone19:27
*** marcoemorais has quit IRC19:27
*** bobt_ has quit IRC19:28
*** andreaf has joined #openstack-keystone19:30
openstackgerritLance Bragstad proposed a change to openstack/keystone-specs: Purpose keystone-api-validation blueprint  https://review.openstack.org/9595719:32
*** sbfox has quit IRC19:33
*** sbfox has joined #openstack-keystone19:34
*** leseb has joined #openstack-keystone19:40
openstackgerritLance Bragstad proposed a change to openstack/keystone: Make gen_pki.sh bash8 compliant  https://review.openstack.org/9343819:40
*** gyee has quit IRC19:41
*** sbfox1 has joined #openstack-keystone19:42
*** nsquare has quit IRC19:43
*** sbfox has quit IRC19:46
jaosorioris there any template to fill or something of the kind of blueprints?19:46
morganfainbergdolphm, bknudson, ping https://review.openstack.org/#/c/93982/5/keystone/assignment/controllers.py - we definitely want a hard lookup on user/group for grant creation?19:49
morganfainbergdolphm, bknudson, misread some of the comments and placed -2 on it... now re-reading and i'm confused.  i thought we wanted to support non-existent users having grants pre-seeded (e.g. LDAP backend)19:49
bknudsonmorganfainberg: for now it makes sense. If I assign a role to a user there's no reason that user shouldn't exist.19:50
bknudsonmorganfainberg: I don't follow the pre-seeded user grants for ldap... why would I need to do that?19:51
morganfainbergbknudson, hm. ok.19:51
morganfainbergbknudson, it was an argument made earlier19:51
morganfainbergbknudson, i remember participating in that discussion19:52
morganfainbergbknudson, but if it isn't the case, i'm fine with requiring the user/group to exist19:52
bknudsonmorganfainberg: in my opinion it seems like either behavior is ok...19:53
bknudsonsince keystone doesn't know if a user was deleted the role grant could be pointing to a user that doesn't exist anyways.,19:53
bknudsonin the case of ldap19:53
morganfainbergbknudson, right19:53
morganfainbergbknudson, i think the case was LDAP, e.g. "I know i'm adding a user called XYZ but user hasn't been added to LDAP yet, so create the grant anyway"19:54
morganfainbergthough... that becomes more work once henry's uuid mapping patch lands19:55
bknudsonwe'll probably have to change it in the future anyways if we split out the identity backend19:55
morganfainbergbknudson, yeah.19:55
morganfainbergbknudson, i'm tempted to say unless there is a very good reason to start enforcing it, i don't know if we should start now (keep it as is)19:55
bknudsonor if we allow federation to map to users instead of groups19:55
morganfainbergbknudson, ++19:56
dolphmmorganfainberg: bknudson: i personally don't care one way or the other, but we need to make it very clear if we support the non-obvious behavior (bp, keystone docs, tests with explanation, etc), otherwise we will get confused bug reports all day long19:58
stevemarmorganfainberg, i liked the comment "ahhh re-reading now"19:58
*** openstackgerrit has quit IRC19:58
morganfainbergdolphm, i'd prefer keeping it as is allowing for the grants w/o the hard lookup and fix the docs / explicitly test etc19:58
dolphm(but i don't see an *immediate* use case for supporting arbitrary assignments, we've only talked about potential ones)19:58
morganfainbergdolphm, but that is because i believe we're going to get asked for direct assignment to federation users vs groups19:59
morganfainbergdolphm, and the long term desire to split identity out (somewhat)19:59
morganfainbergdolphm, if we put the stake in the sand and validate, i woudn't want to change the behavior back to not validating.20:00
bknudsonI'd expect federated role assignments to come about by some mapping, not assigning users to roles directly20:00
bknudsonattribute values -> roles20:00
morganfainbergbknudson, if we can commit to that, i'm ok with this change. - i just don't want to end up waffling on this api20:00
morganfainbergbknudson, and the behabior20:01
bknudsonnot attribute -> id -> role assignments -> roles20:01
morganfainbergbehavior20:01
morganfainbergomg... i sewar i can type.20:01
* morganfainberg grumbles.20:01
stevemarbehaviour*20:01
morganfainbergstevemar, ... thanks ...20:02
morganfainberg:P20:02
stevemari try20:02
morganfainbergok got some time for oauth?20:02
bknudsonI think there was a bp for not checking user / group exists on assignment20:02
morganfainbergbknudson, in the drivers.20:02
bknudsonbut then it was also based on faulty idea of how federation was going to work20:03
morganfainbergbknudson, controllers are the logical area to do the work cross subsystem.20:03
*** leseb has quit IRC20:03
*** nsquare has joined #openstack-keystone20:03
morganfainbergbknudson, that way we don't need to do the same implementation in every driver20:03
bknudsonbp no-check-id20:04
morganfainbergbknudson, hm.20:04
bknudsonhttps://blueprints.launchpad.net/keystone/+spec/no-check-id20:05
morganfainbergoh so i twas more than just taking it out of the driver20:05
bknudson"Even in LDAP and SQL cases, an admin may need to create role assignments prior to a valid user object being available."20:06
bknudsonstill, not sure why an admin may need to create role assignments before the user is there20:06
*** amcrn has quit IRC20:08
*** openstackgerrit has joined #openstack-keystone20:10
morganfainbergbknudson, i remember the discussions20:12
bknudsonif it's an important use case then I guess a tempest scenario would be good to have.20:14
*** marcoemorais2 has quit IRC20:14
bknudsonI think even with all sorts of docs and tests out there that verify the behavior we're still going to get a constant stream of bugs20:14
*** marcoemorais has joined #openstack-keystone20:14
*** gyee has joined #openstack-keystone20:15
*** hrybacki has quit IRC20:15
*** topol has quit IRC20:17
ayoungrunning tests for a backport, and realized how spoiled I've become by tox and the speedier tests20:19
morganfainbergayoung, havana or icehouse20:20
ayoungicehouse right now...20:20
morganfainbergayoung, yeah, havana makes me blink each time because it's the old nosetests style20:21
ayoungits almost done...had to remember to test_mount20:21
ayoungDidn't want to destroy my tox20:21
morganfainberghehe20:21
morganfainbergayoung, besides the backport stuff - you still working on compressed tokens or off on something else? trying to prioritze what i'm starting to work on (besides spec approvals)20:23
*** leseb has joined #openstack-keystone20:24
morganfainbergbknudson, ok i'm sold, lets hard verify user/group exists again20:26
morganfainbergbknudson, if we need something federated, we do mapping(s)20:26
morganfainbergdolphm, ^20:26
morganfainbergstevemar, ^20:26
morganfainbergbknudson, if we split identity out, we will have a whole other mess to deal with anyway...likely it will have to work just like federation20:27
dolphmmorganfainberg: sounds good20:27
bknudsonmorganfainberg: at first I expect keystone to just forward requests to the identity server but then switch to federation at some point.20:27
morganfainbergdolphm, if Pablo isn't interested in continuing https://review.openstack.org/#/c/86025/ i'll pick that one up.20:27
bknudsona federation plugin20:28
stevemaryeah, i was going to ask to just revert bknudson's patch20:28
morganfainbergbknudson, ++ yeah if it's proxy/forward i expect the same.20:28
morganfainbergstevemar, i think bknudson's patch also removed things from the drivers we should keep cross-subsystem chatter to controllers in either case.20:28
*** nkinder has quit IRC20:28
dolphmmorganfainberg: give him 24 hours or so to respond?20:28
morganfainbergdolphm, yep20:29
dolphmmorganfainberg: know his name on IRC?20:29
morganfainbergdolphm, eh, till the end of the week20:29
morganfainbergdolphm, i know he's been on irc before....20:29
dolphmme too20:29
morganfainbergpcargnel20:29
lbragstadhttps://launchpad.net/~pablo-fernando-cargnelutti20:30
morganfainbergdolphm, nick isn't registerted w/ freenode, so can't see when he was around last20:30
morganfainbergdolphm, what the heck...20:34
morganfainbergdolphm, we have a role grant crud test to ensure non-existent user raises 404, but... we don't check it at the controller?20:35
* morganfainberg blinks20:35
dolphmmorganfainberg: checked in the driver?20:36
morganfainbergdolphm, perhaps.20:36
morganfainbergdolphm, looking but https://github.com/openstack/keystone/blob/master/keystone/tests/test_v3_identity.py#L829 don't see how that is passing at the moment20:36
morganfainbergoh.20:38
dolphmmorganfainberg: ?20:38
morganfainbergis that a domain role?20:38
morganfainbergit's testing20:38
*** dims has quit IRC20:38
morganfainbergnot a project role20:38
*** nkinder has joined #openstack-keystone20:40
dolphmmorganfainberg: i don't follow20:40
morganfainbergthat test is claiming it should 404 if the user doesn't exist, it's trying to create a domain grant for the user20:41
morganfainbergit is obviously raising a 404.20:41
morganfainbergthe test passes20:41
*** smckinney has quit IRC20:41
morganfainbergthe controller / driver don't check for user existence20:41
morganfainbergsomething else is causing the 40420:41
dolphmmorganfainberg: why is that obvious?20:41
morganfainbergdolphm, it's not obvious, i'm confused why the test is passing20:42
morganfainbergdolphm, afaict it should be failing20:42
dolphmmorganfainberg: i'm confused as to why you think it should be failing20:42
dolphmmorganfainberg: AFAICT you be crazy, yo20:42
morganfainberghttps://github.com/openstack/keystone/blob/master/keystone/tests/test_v3_identity.py#L84620:42
morganfainbergit's looking for a 404, grants don't check for existence of the user20:43
dolphmmorganfainberg: if you change it to self.user_id does it pass?20:43
dolphmerr, fail20:43
* morganfainberg checks20:44
morganfainbergdolphm, huh so it does check.20:45
morganfainbergdolphm, wow i'm totally not following this code atm correctly20:45
dolphmmorganfainberg: apply caffeine and reboot20:45
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: Spec for V3 extension advertisement  https://review.openstack.org/9597320:51
morganfainbergdolphm, i think i found it. i think this is a side effect of the filter protect callback20:52
*** amcrn has joined #openstack-keystone20:53
morganfainbergdolphm, https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L48820:53
morganfainbergerm protect (not filter protect)20:53
morganfainbergdolphm, so in V3, it wouldn't succeed even without the changes in https://review.openstack.org/#/c/93982/ because the v3 api has a callback that tries to lookup the user/group if they are part of the request20:56
morganfainbergdolphm, the V2 one has no such callback doing the work20:56
morganfainbergdolphm, the question is, do we want explicit checks, or is a side effect of that callbck sufficient?20:56
morganfainbergbknudson, ^20:57
dolphmmorganfainberg: lol that's terrible :(20:57
*** amcrn has quit IRC20:57
dolphmmorganfainberg: v2 and v3 should behave identically in that regard20:58
morganfainbergdolphm, agreed20:58
bknudsonmorganfainberg: we shouldn't be relying on the side-effect20:58
morganfainbergdolphm, and we should do explicit checks in V2 for sure, but with the change from that review we'll be doing extra lookups on user/group in the decorator callback.20:58
morganfainbergdolphm, i guess we're already bad about lookup things to lookup things then do the work again20:59
bknudsonmight want to change the server so that there isn't a side-effect20:59
morganfainbergbknudson, yeah. i think that might be a massive policy implementation re-think20:59
morganfainbergbknudson, i'm gonna say we should drive that separately.21:00
morganfainbergfrom this review.21:00
ayoungmorganfainberg, WHAT21:00
ayoungI stop paying attention and we decide to backpedal!21:00
morganfainbergayoung, V3 does a hard check of users/groups on grant creation21:00
morganfainbergayoung, it's a side effect of our policy implementation21:01
ayoungmorganfainberg, and that never made sense.21:01
morganfainbergayoung, the call back21:01
ayounglets drop it21:01
morganfainbergayoung, i think if we're talking federated users, all the mappings to roles shoud come from mapping.21:01
morganfainberguser/groups/etc21:01
ayoungwhat argument did I miss?21:01
* ayoung reads further up21:01
morganfainbergfor non federated users what is the use case for greating grants for non-existant users?21:02
morganfainbergayoung, so direct IDP (Sql, or LDAP) why is it bad to check for user/group existence before creating the grant [lets ignore federation atm]21:03
ayoungmorganfainberg, they haven't been entered by HR yet21:03
ayoungmorganfainberg, it couples the two backends21:03
ayoungit makes no difference if they are there or not21:03
morganfainbergayoung, i don't care which way we go as long as V2 and V3 end up consistent.21:04
openstackgerritRodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Add role assignments as concept in Client API V3 docs  https://review.openstack.org/9734521:04
ayoungmorganfainberg, and we can't just "assume away" Federation.  That is the approach that should drive the LDAP work21:04
ayoungnot the other way around21:04
ayoungV2 needs to die21:04
ayoungWe need to stop pandering to the "I need to look up every one of my 100000000000000 users" crowd21:05
*** dims has joined #openstack-keystone21:05
openstackgerritRodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Add role assignments as concept in Client API V3 docs  https://review.openstack.org/9734521:05
bknudsonin V2, I think create user, modify user, etc, is an extension21:05
morganfainbergayoung, we can do all the federation stuff via mapping: (attribute, attribute, etc) == Role21:05
bknudsonso maybe we should look at deprecating the extensions21:05
ayoungbknudson, user_crud21:05
bknudsonleaving the core v2 supported21:05
ayoungbknudson, um...that would be cool21:05
morganfainbergayoung, which is why i said ignore federation - we can work aroudn federation stuff atm. and this change wouldn't affect current OS-FEDERATION items.21:05
bknudsonmaybe that would be more acceptable21:05
morganfainbergayoung, so more to the point, just address the direct IDP scenario21:06
morganfainbergayoung, the rest will follow fine.21:06
ayoungmorganfainberg, the sooner we convince the world that storing users in a custome SQL database is a dumb idea, the better.21:07
*** topol has joined #openstack-keystone21:07
*** dims has quit IRC21:09
morganfainbergso.. with henrynash's universal user_id thing, i think we can fix the callback.21:10
morganfainbergmaybe.21:10
* morganfainberg needs to think on the fix if we're making V3 not check users (consistent with v2)21:10
morganfainbergbecause a change to this might brak anyone who is using advanced policy on grant creation (e.g. ensuring user.domain_id == project.domain_id)21:11
*** arborism has joined #openstack-keystone21:13
ayoungWhat the who now?21:13
ayoung user.domain_id == project.domain_id  is a bad assumption21:13
openstackgerritMarek Denis proposed a change to openstack/python-keystoneclient: Implement SAML2 ECP authentication  https://review.openstack.org/9216621:13
*** daneyon has quit IRC21:14
marekd^^ strange, when I use keystoneclient.session.Session, even with requests.Session() injected it will eventually complain with error keystoneclient.openstack.common.apiclient.exceptions.BadRequest: Expecting to find application/json in Content-Type header. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400). If I inject pure requests.Session() to t21:15
morganfainbergayoung, no i mean the rich v3 cloud policy capabilities21:16
morganfainbergayoung, it relies on being able to lookup any user / group / domain / project / etc attributes in some cases and pass it to enforcement engine21:16
ayoungmorganfainberg, but that particular rule representat a misunderstanding of how policy and role assignments should work21:17
morganfainbergayoung, in v3 cloud policy you could enforce all users can only have roles on their domains21:17
ayoungthere is no relationship between user domain and project domain21:17
morganfainbergayoung. could, not required to.21:17
ayoungmorganfainberg, um...that would be just the kind of thing I would take much glee in trashing21:18
morganfainbergdolphm, ^ is this a ML topic to see what people are doing [if anything] or can we merrily break things like that.21:18
ayoungmorganfainberg, but...actually I don;t even see how that is not enforcable21:19
ayoungit would be quite enforceable21:19
dolphmmorganfainberg: what's the use case that would be broken?21:19
ayoungwhen you assign a role, you would check on the user object passed in, not on a lookup in IdP21:19
dolphmuser.domain_id == project.domain_id as an assumption? (where?)21:19
morganfainbergdolphm, ok so  - if we don't do the hard lookup (fix the grant engine) we need to break some of the more rich v3 cloud policy capabilities21:19
ayounghttp://www.youtube.com/watch?v=s9bT4B1kEvc21:20
morganfainbergdolphm, e.g. the ability to say all users can only have grants on projects in their owning domain21:20
morganfainbergayoung, except policy enforcement happens in the decorator21:20
ayoungmorganfainberg, an...it looks at the arguments21:21
morganfainbergayoung, yep21:21
ayoungnot at the objects fetched from the DB in this case21:21
morganfainbergayoung, you got it21:21
ayoungit would fetch project from DB,but user would be passed in21:21
morganfainbergayoung, only user_id is passed in21:21
ayoungah...but only oin that whoe eveil USer ID insanity we have....crud21:21
morganfainbergayoung, exactly21:21
* ayoung goes back under his rock21:21
morganfainbergayoung, it might be easier for consistency to make the standard grant stuff all do hard lookups. and enhance the mapping engine to get around it (even for local IDP) - move everything to mapping?21:22
morganfainbergdolphm, bknudson, ^ [thoughts]21:22
ayoungits wrong and backwards and we are enabling disfunctional behavior21:23
ayoung..soo pretty much status quo21:23
dolphmmorganfainberg: what does the mapping engine have to "get around?"21:24
morganfainbergdolphm, the mapping engine can do all the work of mapping <any combination of attributes> to a role. vs needing to know a specific user/group id21:25
dolphmmorganfainberg: with scope?21:25
morganfainbergdolphm, scope?21:25
dolphmmorganfainberg: "to a role" ... in what scope?21:26
bknudsonmorganfainberg: I'm not understanding what you're suggesting breaking... isn't it broken as is?21:26
bknudsonmorganfainberg: the server doesn't check if the user exists now, so cloud policy is broken21:26
morganfainbergbknudson, except it does in the decorator callback: https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L488 which is what is passed to the enforcement engine21:27
morganfainbergdolphm, we could map, i guess? to role in <project>?21:27
morganfainbergor role in <thing>?21:28
bknudsonmorganfainberg: ok, so I think you're saying that keystone actually requires a user now, and to change it to not require a user requires changing the policy code.21:28
morganfainbergbknudson, correct, sorry wasn't clear on that (jumping around the conversation some).21:28
bknudsongood god no wonder people complain keystone is slow!21:29
morganfainbergbknudson, and possibly changing the richness of what policy can enforce.21:29
bknudsonThe server could try to get the user, role, etc., and if it fails with not found set the value to None there21:30
bknudsonor don't set it21:30
bknudsonor set it to some dummy value21:30
* morganfainberg finds the more entertaining rabbitholes.21:30
bknudsonthe policy code should be smart enough to handle the missing value21:30
bknudsonmissing attribute21:31
bknudsonI could swear I had a unit test... seems like it would have faile.d21:31
bknudsonmaybe it didn't go through the policy code21:31
*** arborism is now known as amcrn21:32
*** raildo has quit IRC21:34
*** henrynash has quit IRC21:35
openstackgerritRodrigo Duarte Sousa proposed a change to openstack/python-keystoneclient: Changes expcetion raised by v3.trusts.update()  https://review.openstack.org/9735521:50
*** Guest70585 has joined #openstack-keystone21:52
*** anteaya has quit IRC21:54
*** Guest70585 is now known as anteaya21:54
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: Add spec for using JSON Home  https://review.openstack.org/9735921:54
bknudsonwrote up a spec for using JSON Home since people were asking about it21:55
morganfainbergdolphm, back tick all the things: ``All`` ``references`` ``to`` ``token_api.get_token`` ``(````excluding`` ``the`` ``UUID`` ``token provider````)`` ..  :P21:55
*** david-lyle has quit IRC21:55
stevemarmorganfainberg, our consistency with the back ticks is awful21:56
*** andreaf has quit IRC22:02
*** nkinder has quit IRC22:02
*** dims has joined #openstack-keystone22:03
*** andreaf has joined #openstack-keystone22:07
*** dims has quit IRC22:08
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Add spec for non-persistent-tokens  https://review.openstack.org/9597622:08
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Add spec for non-persistent-tokens  https://review.openstack.org/9597622:10
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Add spec for non-persistent-tokens  https://review.openstack.org/9597622:11
*** andreaf has quit IRC22:12
*** jamielennox is now known as jamielennox|away22:12
*** dims has joined #openstack-keystone22:12
openstackgerritBrant Knudson proposed a change to openstack/keystone-specs: Add spec for using JSON Home  https://review.openstack.org/9735922:13
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Properly invalidate cache for get_*_by_name methods  https://review.openstack.org/9708222:14
*** praneshp has quit IRC22:17
*** bknudson has quit IRC22:20
*** leseb has quit IRC22:21
morganfainbergls22:26
*** gordc has quit IRC22:27
*** jaosorior has quit IRC22:32
*** sbfox1 has quit IRC22:35
*** sbfox has joined #openstack-keystone22:38
*** jamielennox|away is now known as jamielennox22:43
jamielennoxmarekd that's not good - did you figure it out/22:47
*** stevemar has quit IRC22:54
*** amerine_ has joined #openstack-keystone22:54
*** nkinder has joined #openstack-keystone22:58
*** amerine has quit IRC22:58
*** harlowja_ has quit IRC23:04
*** harlowja has joined #openstack-keystone23:04
*** dc has quit IRC23:07
jamielennoxhey guys, this one fairly trivial and getting in the way: https://review.openstack.org/#/c/91216/ would appreciate a few looks23:09
*** leseb has joined #openstack-keystone23:22
*** andreaf has joined #openstack-keystone23:23
*** leseb has quit IRC23:26
*** andreaf has quit IRC23:29
*** sbfox has quit IRC23:32
*** rodrigods_ has joined #openstack-keystone23:33
*** joesavak has quit IRC23:35
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Service Token Composite Authorization  https://review.openstack.org/9631523:36
openstackgerritMorgan Fainberg proposed a change to openstack/keystone-specs: Service Token Composite Authorization  https://review.openstack.org/9631523:39
jamielennoxmorganfainberg: much prefer that way to the idea of generating new single use tokens23:42
morganfainberg:)23:42
jamielennoxalso no idea how to handle that in middleware23:43
morganfainbergjamielennox, how to accept another header and present the data?23:46
morganfainbergjamielennox, should be easy23:46
jamielennoxyea, just thinking about blowing out the number of headers we are going to have to present23:47
morganfainbergjamielennox, we already have that code.23:47
jamielennoxneed a better way23:47
morganfainbergjamielennox, 1 extra header?23:47
morganfainbergoh oh23:47
morganfainbergyeah23:47
morganfainbergwell i mean, how else do you pass data from the middleware to the service?23:47
morganfainbergand... does it matter?23:47
morganfainbergthe service token should be very small, no catalog, etc23:48
morganfainbergreally just user, scope (probably usually none) and roles23:48
morganfainbergSC and all the other mojo (trusts, etc) would be left out23:48
morganfainbergmaybe a while list of service token headers to provide23:49
morganfainbergwhite list even23:49
*** diegows has quit IRC23:54
*** stevemar has joined #openstack-keystone23:56
*** sbfox has joined #openstack-keystone23:57
jamielennoxyou're right it really doesn't matter i think23:58
*** amerine_ has quit IRC23:59

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