Monday, 2015-02-23

*** lhcheng has joined #openstack-keystone00:00
*** lhcheng has quit IRC00:04
*** diegows has joined #openstack-keystone00:12
*** markvoelker has joined #openstack-keystone00:16
*** markvoelker has quit IRC00:20
*** ncoghlan has joined #openstack-keystone00:32
*** rm_work is now known as rm_work|away00:35
*** Akshik has joined #openstack-keystone00:43
*** Akshik has quit IRC00:43
*** markvoelker has joined #openstack-keystone00:50
*** markvoelker has quit IRC00:55
*** lhcheng has joined #openstack-keystone01:01
*** lhcheng has quit IRC01:05
*** boris-42 has joined #openstack-keystone01:13
openstackgerritMerged openstack/python-keystoneclient: Using correct keyword for region in v3
*** dimsum__ has joined #openstack-keystone01:38
openstackgerritMerged openstack/python-keystoneclient: Add default body for non-abstract empty methods
*** dims_ has joined #openstack-keystone01:39
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Add OS-SIMPLE-CERT support for v3.
*** dimsum__ has quit IRC01:43
openstackgerritBrant Knudson proposed openstack/keystone: Document mapping of policy action to operation
*** markvoelker has joined #openstack-keystone01:51
*** markvoelker has quit IRC01:57
*** markvoelker has joined #openstack-keystone02:00
*** diegows has quit IRC02:04
*** stevemar has joined #openstack-keystone02:21
*** ChanServ sets mode: +v stevemar02:21
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Exposes bug in Federation list projects endpoint
*** erkules_ has joined #openstack-keystone02:22
*** erkules has quit IRC02:25
*** markvoelker has quit IRC02:26
*** markvoelker has joined #openstack-keystone02:27
*** markvoelker has quit IRC02:31
openstackgerritSteve Martinelli proposed openstack/keystone: Enable endpoint_policy, endpoint_filter and oauth by default
*** himangi has quit IRC02:58
morganfainbergstevemar, any thoughts on thread.local() vs passing context in to methods to do exactly nothing with it?03:17
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Separate exceptions into their own file
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Extract revocations to file
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Extract SigningDirectory into file
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Extract IdentityServer into file
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Move UserAuthPlugin into its own file
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Break default auth plugin into file
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Extract all TokenCache related classes to file
stevemarmorganfainberg, hadn't given it a thought yet03:24
stevemarmorganfainberg, don't know anything about thread.local() and haven't had time to look into it03:25
morganfainbergstevemar, it's how pecan does it. but in short, it is a local() store for <things> that is isolated to a given thread03:25
morganfainbergin eventlet / multithreading it is per greenlet/thread03:26
morganfainbergin multiprocessing (with no threads) it's just the per-process as you'd expect03:26
morganfainbergso you basically do thread_local = threading.local()03:26
morganfainbergand you can store data in it03:26
morganfainbergand access it elsewhere with the same mechanism03:26
*** samueldmq_ has quit IRC03:28
jamielennoxmorganfainberg, stevemar: can you do: quickly03:29
*** tellesnobrega_ has joined #openstack-keystone03:31
*** tellesnobrega_ has quit IRC03:31
stevemarmorganfainberg, i'll look into it soon (maybe tonight, maybe tomorrow)03:35
stevemarjamielennox, done03:35
bknudsonthread.local is "spooky action at a distance" and should only be used in the direst of circumstances.03:36
*** lhcheng has joined #openstack-keystone04:19
*** rwsu-afk has quit IRC04:19
*** lhcheng has quit IRC04:30
*** spandhe has quit IRC04:35
openstackgerritMerged openstack/python-keystoneclient: Make executable
*** spandhe has joined #openstack-keystone04:52
*** himangi has joined #openstack-keystone04:52
*** rushiagr_away is now known as rushiagr04:56
*** lhcheng has joined #openstack-keystone05:17
*** lhcheng has quit IRC05:19
*** pcaruana has quit IRC05:45
*** lhcheng has joined #openstack-keystone06:12
*** rushiagr is now known as rushiagr_away06:20
stevemarwhat the heck is 'legacy_endpoint_id'06:31
stevemarbknudson, good to know...06:31
lhchengstevemar: isn't that the column used to convert the v3 endpoint data model to v2?06:33
* stevemar shrugs at lhcheng 06:34
stevemarhows it determined?06:34
openstackLaunchpad bug 1403408 in Keystone "Redundant endpoints found in the table "endpoint"" [Undecided,Confirmed] - Assigned to Dave Chen (wei-d-chen)06:34
lhchengstevemar: one row that stores pubic/internal/admin url for the region/service tpye06:35
lhchengif you look at the default endpoint data in devstack,  there are three records that matches the legacy_endpoint_id06:36
lhchengthe old endpoint data model, have three columns public/internal/admin url06:36
lhchenginstead of one row that we used to have now06:36
stevemarlhcheng, i get that, but does anything still use it now?06:37
lhchengyeah, when hitting the v2.0/endpoints06:38
stevemarlhcheng, that seems silly06:40
lhchengstevemar: hmm yeah, the bug can be solve can compound unique constraint check06:40
*** erkules_ is now known as erkules06:45
lhchengstevemar: I guess for backward compatibility for v2.0/endpoints, there is probably another way to do it. but it works..06:45
*** himangi has quit IRC06:58
openstackgerritSteve Martinelli proposed openstack/keystone: Reference OSC docs in CLI examples
openstackgerritSteve Martinelli proposed openstack/keystone: Update `os service create` examples in config services
stevemarlhcheng, ^07:06
*** afazekas_ has joined #openstack-keystone07:06
*** mflobo has joined #openstack-keystone07:10
lhchengstevemar: good catch on updating the docs, thanks!07:14
stevemarsleep time!07:14
lhchengstevemar: good night!07:16
*** stevemar has quit IRC07:19
*** lhcheng has quit IRC07:27
*** rushiagr_away is now known as rushiagr07:34
*** atiwari2 has quit IRC07:35
*** krykowski has joined #openstack-keystone07:37
*** atiwari has joined #openstack-keystone07:44
*** jaosorior has joined #openstack-keystone07:54
*** lhcheng has joined #openstack-keystone07:59
*** henrynash has joined #openstack-keystone08:26
*** ChanServ sets mode: +v henrynash08:26
*** spandhe has quit IRC08:47
*** rushiagr is now known as rushiagr_away08:54
*** jistr has joined #openstack-keystone08:55
*** lhcheng has joined #openstack-keystone09:11
*** lhcheng has quit IRC09:12
*** ncoghlan has quit IRC09:31
openstackgerrithenry-nash proposed openstack/keystone: Implement backend driver support for domain config
*** henrynash has quit IRC09:51
*** rushiagr_away is now known as rushiagr09:58
*** fmarco76 has joined #openstack-keystone10:11
*** pnavarro has joined #openstack-keystone10:19
jamielennoxstevemar: it's because in v2 an endpoint was the combo of public/internal/admin - in v3 an endpoint is one of each, so the legacy is if it was created under a v2 scheme it's whats show under v210:19
*** ccard has joined #openstack-keystone10:19
*** ajayaa has joined #openstack-keystone10:30
*** mzbik has joined #openstack-keystone10:32
samueldmqmorning :-)10:59
*** krykowski has quit IRC11:00
*** krykowski has joined #openstack-keystone11:00
openstackgerritMarcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend
*** himangi has joined #openstack-keystone11:16
*** andreaf_ has joined #openstack-keystone11:20
*** andreaf_ has quit IRC11:22
*** aix has joined #openstack-keystone11:28
*** nellysmitt has joined #openstack-keystone11:29
*** diegows has joined #openstack-keystone11:36
*** MasterPiece has joined #openstack-keystone11:43
*** raildo has joined #openstack-keystone12:07
*** henrynash has joined #openstack-keystone12:16
*** ChanServ sets mode: +v henrynash12:16
*** vhoward has quit IRC12:19
*** henrynash has quit IRC12:20
*** henrynash has joined #openstack-keystone12:23
*** ChanServ sets mode: +v henrynash12:23
*** henrynash has quit IRC12:25
*** krykowski has quit IRC12:40
*** dims_ has quit IRC12:44
*** MasterPiece has quit IRC12:45
*** dimsum__ has joined #openstack-keystone12:51
*** zigo has quit IRC12:52
*** diegows has quit IRC12:53
*** zigo has joined #openstack-keystone12:56
*** henrynash has joined #openstack-keystone12:59
*** ChanServ sets mode: +v henrynash12:59
*** nicodemos has joined #openstack-keystone13:02
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone: Add is_domain field in Project Table
*** krykowski has joined #openstack-keystone13:08
*** henrynash has quit IRC13:12
*** dimsum__ has quit IRC13:22
*** dimsum__ has joined #openstack-keystone13:22
*** lsmola has quit IRC13:23
*** henrynash has joined #openstack-keystone13:24
*** ChanServ sets mode: +v henrynash13:24
*** lsmola has joined #openstack-keystone13:27
*** gordc has joined #openstack-keystone13:30
rodrigodshenrynash, ping... have some time to discuss db constraints? (how can we change the project_name constraint from domain_id + name to also include the parent_id)13:36
henrynashrodigods: so what, conceptually, do you need it to be?13:37
rodrigodshenrynash, yes... we want to have projects with the same name in the same domain (because the domain table -> project table migration)13:37
rodrigodsbut parent_id is a nullable column13:38
rodrigodsand almost all mysql engines accept multiple null values for constraints13:38
henrynashrodigods: so I remember looking at nullable colums being part of unique constraints13:38
rodrigodshenrynash, it considers two null values different13:39
*** dimsum__ is now known as dims13:39
henrynashrodigods: hmm13:39
rodrigodshenrynash, we thought of two solutions13:39
henrynashrodigods: you may need to do the checks manually13:39
rodrigodsuse a flag in the parent_id instead of null13:39
rodrigodsor do the check manually in the manager layer13:39
bknudsonyou don't have to rely on the database to enforce unique constraints, since the only user is keystone.13:40
*** bknudson has quit IRC13:41
henrynashrodigods: I’d agree with bknudson, doing the checks manually isn’t such a terrible thing in our case13:41
openstackgerritMarcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend
rodrigodshenrynash, great13:42
*** joesavak has joined #openstack-keystone13:44
samueldmqhenrynash, I found a bug on federation.... regarding inherited roles from parents  ...
openstackLaunchpad bug 1424500 in Keystone "Federation list projects endpoint does not honor project inherited role assignments" [Undecided,New] - Assigned to Samuel de Medeiros Queiroz (samueldmq)13:48
henrynashsamueldmq: yes, saw that….13:49
henrynashsamueldmq: haven’t had a chance to look clsoely at it…but good practice to great a test that shows the failure first…nice13:49
samueldmqhenrynash, :)13:50
samueldmqhenrynash, I was planning to modify list_role_assignments ...13:50
samueldmqhenrynash, it should receive honor_group, honor_inheritance ... that would be True by default13:50
samueldmqhenrynash, then the federation methods could call it with honor_inheritance = True and honor_group = False to get group assingments13:50
samueldmqhenrynash, if you remember .. we had a conversation in the past about this ..13:51
henrynashsamueldmq: yes…at the time we said, we’ll not use it for federation calls….but it would, of course, be good if we could (as long as it doesn’t make the code to complex)13:51
samueldmqhenrynash, I think it will add a few lines in the code13:53
henrynashsamuledmq: ok, do a patch and I’ll happily review13:53
samueldmqhenrynash, I'll add such support in a separate patch .. so we can look at it separately from the big refactoring13:53
samueldmqhenrynash, great thx13:53
henrynashsameuldmq; sounds good13:53
samueldmqhenrynash, ack, will work on this later today ,... working on reseller today :-)13:54
*** ljfisher has joined #openstack-keystone13:55
samueldmqhenrynash, btw, I have a question related to domain specific backends ...13:55
henrynashsamueldmq: sure13:55
samueldmqhenrynash, the additional domains will created on a SQL resource backend, right?13:56
henrynashsamueldmq: yes13:56
samueldmqhenrynash, k ... this is causing tests to fail once we have a is_domain project per domain ..... :/13:57
samueldmqhenrynash, but now I have info needed to fix it .. thx13:57
henrynashsamueldmq: yes, we’ll need to change it a little bit for that13:58
samueldmqhenrynash, but now I have info needed to fix it .. thx13:58
samueldmqoops .. repeated the message .... in fact I tried to go to the terminal and re-run last tests13:59
samueldmqhenrynash, ^13:59
*** ayoung has joined #openstack-keystone14:00
*** ChanServ sets mode: +v ayoung14:00
*** krykowski_ has joined #openstack-keystone14:01
*** krykowski has quit IRC14:02
*** bknudson has joined #openstack-keystone14:05
*** ChanServ sets mode: +v bknudson14:05
*** diegows has joined #openstack-keystone14:12
*** Guest28285 is now known as mgagne14:13
*** mgagne has joined #openstack-keystone14:13
*** krykowski_ has quit IRC14:14
*** richm has joined #openstack-keystone14:14
*** henrynash has quit IRC14:15
openstackgerritHugo Nicodemos proposed openstack/keystone: Add tests to get subprojects of the parent_id
*** nkinder has quit IRC14:26
*** stevemar has joined #openstack-keystone14:33
*** ChanServ sets mode: +v stevemar14:33
*** ajayaa has quit IRC14:37
*** rushiagr is now known as rushiagr_away14:42
openstackgerritMarco Fargetta proposed openstack/keystone: IdP ID registration and validation
marekdfmarco76: ^^ thanks for the patch.14:45
*** henrynash has joined #openstack-keystone14:50
*** ChanServ sets mode: +v henrynash14:50
*** jsavak has joined #openstack-keystone15:00
openstackgerritMarek Denis proposed openstack/keystone: Ehncance user identification in mapping engine
*** joesavak has quit IRC15:03
*** mzbik has quit IRC15:11
*** sigmavirus24_awa is now known as sigmavirus2415:16
*** nkinder has joined #openstack-keystone15:17
*** rushiagr_away is now known as rushiagr15:18
*** ajayaa has joined #openstack-keystone15:20
marekdstevemar: henrynash: what's the final decision actually, are we dropping 'extra' column from backends?15:28
henrynashmarekd: no15:28
stevemarhenrynash, i thought we were?15:29
henrynashmarekd: but we agreed on bp that allows a deployer to set a config value which will prevent peopel storing data there15:29
henrynashmarekd: but it is still supported by default15:29
*** Ephur has joined #openstack-keystone15:31
lbragstadstevemar: thanks for the review. I'll be pushing a revision up soon!15:34
marekdhenrynash: stevemar: and 'extra' attributed is stored as BLOB in DB?15:34
henrynashmarekd: yes, JsonBlob15:34
stevemarayoung, +3!15:34
marekdhenrynash: JsonBlob is a Text15:34
henrynashmarekd: I believe so15:35
*** carlosmarin has joined #openstack-keystone15:35
*** ajayaa has quit IRC15:35
*** zigo_ has joined #openstack-keystone15:36
*** radez_g0n3 is now known as radez15:38
*** mattfarina has joined #openstack-keystone15:41
stevemarhenrynash, you mean you're *not* at interconnect?15:42
henrynashstevemar: no, sir!15:42
stevemarhenrynash, i will have little luck finding people this week15:43
stevemarhenrynash, whats the point of the sql bits here:
henrynashstevemar: so true15:43
*** radez is now known as radez_g0n315:43
henrynashstevemar: ah yes, sorry, haven’t had a chance to invesitgaet that - I wtote that such a long time again I can’t remember!15:44
henrynashsteevmar: want to get all the domain-config stuff up to day, first15:44
stevemarhenrynash, can you take of that in another patch (the comments i mean)15:44
stevemari think the filtering patch is good and want to push it through15:45
henrynashstevemar: sure, happy to do that…I’ll add a coment to that effect15:45
stevemarthough there could be a few more tests :)15:45
stevemarcurrently just 'startsWith' is exercised15:46
*** aix has quit IRC15:47
henrynashstevemar: that’s true….although the same could be said for the sql filtering….probably need an improvement all round15:47
henrynashstevemar: I’ll raise a defect about that in general15:48
stevemarcool cool15:48
marekdstevemar: henrynash: regarding is it possible that db2 driver is broken ?15:50
openstackLaunchpad bug 1405726 in Keystone "getting scoped federation token fails when using db2" [Undecided,New]15:50
marekdlooks like only db2 fails on that15:51
stevemarmarekd, i did some research on that, apparently Db2 fails in general when DISTINCT is used in conjunction with certain string types15:51
marekdstevemar: and Keystone  must support DB215:51
stevemarmarekd, preferably, but it's not written that we do15:52
marekdso i wonder how is it possible that it fails here and not in 8 other places where distinct was used...?15:52
stevemarmarekd, where else is it used?15:53
stevemarmarekd, well endpoint policy isn't being exercised15:54
stevemarand the other bits in assignment backend seem federation related15:55
*** rushiagr is now known as rushiagr_away15:55
marekdlist_user_ids_for_projects ... i think this not federation related.15:56
stevemarlist_domain_ids_for_groups, list_domain_ids_for_user, list_role_ids_for_groups_on_domain, list_role_ids_for_groups_on_project, list_role_ids_for_groups_on_project15:56
stevemarthat one isn't15:56
stevemarmarekd, but list_user_ids_for_project actually uses a parameter (distinct('actor_id'))15:56
stevemari wonder if that's the issue15:56
marekdi dont like sorting in memory if the db should be doing that for me.15:56
marekdi don't feel like removing 'distinct' option.15:59
marekdstevemar: what did he mean by saying "Cast the json blob to VARCHAR?" Where he wants to do this?15:59
stevemarmarekd, i'm not sure what that means16:00
marekdstevemar: i will comment on the bug.16:01
*** ChanServ sets mode: +o dolphm16:02
ayounghtruta,   raildo,,cm   is 'tail'  and actuiall kwarg, or is it a norm you are using for arg passing inside the client only?16:04
openstackgerritMerged openstack/keystone: Check consumer and project id before creating request token
*** fmarco76 has left #openstack-keystone16:07
*** fmarco76 has joined #openstack-keystone16:09
*** jorge1 has joined #openstack-keystone16:09
*** fmarco76 has left #openstack-keystone16:10
marekdlbragstad:,cm when using choices, available options are somehow presented to the user?16:17
marekdlbragstad: otherwise, maybe it's better to help as it used to be, and treat choices as a first pass of input validation?16:17
lbragstadmarekd: correct, I need to generated the new sample.config on that patch just to see if the config generator does anything special with choices when generating the configuration file.16:18
lbragstadmarekd: but it does do input validation,16:18
marekdlbragstad: so what happens if i put wrong options?16:18
lbragstadmarekd: bknudson just suggested that the help text should be removed if we're using choices.16:18
lbragstadmarekd: it should blow up16:19
marekdfails, and some template "Wrong option provided. Available options: %s" % choices is returned?16:19
marekdif the user doesnt see available options we should keep it in help16:19
bknudsonthe help text from oslo.config should include the choices... otherwise I think that's a bug in oslo.config16:19
marekdbknudson: ok16:20
htrutaayoung: it is a norm16:21
*** devlaps has joined #openstack-keystone16:21
*** rushiagr_away is now known as rushiagr16:21
ayounghtruta, posted my response on the review.  go with the underscore "norm" from python as a cleaner approach.16:22
*** Tahmina has joined #openstack-keystone16:23
htrutaayoung: cool. the tail was a suggestion by wanghong in the patch 6 or 716:24
htrutaI'll make it as you suggested16:24
ayoungyeah...and not a horrible one.16:24
ayoungJust,  naming is hard, and we need to make sure things are self documenting.16:24
lbragstadmorganfainberg: didn't you have a suggestion related to stevemar's comments here: about how we can determine if token persistence is being used?16:29
*** Tahmina has quit IRC16:29
lbragstadmorganfainberg: I tried throwing it in the __init__() but hit import/config related issues16:30
htrutaayoung: got it16:33
bknudsonwe could have a dummy persistence provider.16:33
bknudsonthat doesn't actually persist anything.16:33
htrutaayoung: so, you suggest having a '_inherited_to_projects' kwarg?16:33
*** Tahmina has joined #openstack-keystone16:34
ayounghtruta, don't you think that is the least surprising, and most clear  value to use?  I'm open to other suggestions, just trying to meet the intention here16:35
ayoungthe _  is not just python specific, but it really is a norm as well.  But it is less likely to conflict with an explicit argument, which is what you want, right?16:36
htrutaayoung: yes.16:36
htrutaI'm okay with tha16:36
htrutaI wonder what bknudson would say about it16:37
bknudsonhtruta: about what?16:37
*** ajayaa has joined #openstack-keystone16:38
htrutaabout the idea to change the kwarg 'tail' to something like '_inherited_to_projects' in here:
htrutabknudson: ^16:39
morganfainberglbragstad: yeah I had a16:40
morganfainbergPaste explaining the diff16:40
lbragstadmorganfainberg: can I build it in the _persistence Property method?16:40
morganfainberglbragstad: let me show you if I can find it.16:40
morganfainberglbragstad: I just made an @property on the driver that returned true/false16:41
lbragstadmorganfainberg: gotcha,16:41
openstackgerritHenrique Truta proposed openstack/python-keystoneclient: Creating parameter to list inherited role assignments
lbragstadmorganfainberg: doing something similar since we have the _persistence property method already16:41
morganfainbergThen instead of checking if driver str == klwt, self.driver.needs_persistence16:41
morganfainbergOr some such.16:41
lbragstadnot sure what i have is going to work, but I'll play with it16:42
*** devlaps has quit IRC16:42
morganfainbergI also ran into a byte_str bug when running a devstack with the POC code16:42
bknudsonhtruta: build_url should be somewhat generic, so using something generic like "tail" makes more sense than something specific like '_inherited_to_projects'16:43
morganfainbergFernet was un happy.16:43
morganfainbergAnd it raised an exception.16:43
morganfainberglbragstad: on validate I think. When using horizon. I can reproduce the exception easily.16:44
morganfainberglbragstad: the v2 token stuff should be less work once we have v3 working correctly. I think you're pretty close tbh.16:45
htrutabknudson: so, are you ok with tail? or do you have any suggestion?16:45
htrutaayoung: ^16:45
lbragstadmorganfainberg: yeah, I plan to tackle that soon16:45
morganfainberglbragstad: figured :)16:45
ayounghtruta, I prefer  '_inherited_to_projects'16:45
bknudsonhtruta: I'm ok with tail... it's not the most descriptive. Would be nice if it was [] rather than string.16:45
ayoungbut ifwe do 'tai'l for a shoud be an explicit parameter16:46
ayoungI concur with bknudson that the more generic term should be used for a general purpose utility16:46
morganfainberglbragstad: I also want to get these tokens actively tested via gate as soon as they land. I'm thinking we use the eventlet job - so some devstack/gate changes. Once we get to full functional it'll be easier.16:47
ayoungtail implies it is the last that what you mean htruta ?16:47
morganfainberglbragstad: I can prob help with that front once we're closer.16:47
lbragstadmorganfainberg: makes sense, that would be good16:47
ayoungmorganfainberg, for AETokens...I would feel a lot better about them if they had an indicator in them of who signed them.16:47
*** devlaps has joined #openstack-keystone16:48
ayoungI think we might be painting ourselves into a corner with "we know who signed these" implicit in the implementation16:48
morganfainbergayoung: the nice thing is that enhancement should be stupidly easy to add once the base code is there :)16:48
ayoungI'm not going to hold things up...but16:48
ayoungthat is my hope, yes16:48
ayoungmorganfainberg, BTW, my guess is the 255 char limit is really an artifact of memcache design that makes 250 bytes the  key size16:49
morganfainbergayoung: and I expect that we will do more of those type of enhancements along the way. I also expect to document the data in the token-Id encoded will be "private" so we can change it as long as we are careful - but no deployer should be directly inspecting it.16:49
ayoungI think (deduced from what I've read) that memcache will use a 255 length string as is, but will Hash a longer one16:50
morganfainbergayoung: nah 255 is about where people get complaining about extra overhead. But less than 500 is pretty damn good.16:50
htrutaayoung: yes. tail was meant to be the last item only16:50
ayoungmorganfainberg, I think we will get someone looking at the data.  BUt we can break them16:50
morganfainbergayoung: 1k is where people *really* start complaining.16:51
ayounghtruta, something is wonky with that convention...I'' remove the -1 though16:51
morganfainbergayoung: exactly. They can look at the data but it is meant to be a black box. ;) we should be in our rights to break them if needed and they aren't asking keystone to validate it.16:51
htrutaayoung: cool. thanks16:53
morganfainberglbragstad: so yeah. Totally on board with your direction. Looks like some16:54
morganfainbergMinor massaging to clean things up.16:54
morganfainberglbragstad: and fernet looks like a good option over keyczar.16:55
*** gyee has joined #openstack-keystone16:55
*** ChanServ sets mode: +v gyee16:55
morganfainbergdolphm: ^^ (new token stuff).16:55
dolphmmorganfainberg: cool16:56
morganfainberglbragstad, dolphm:
lbragstadmorganfainberg: the fernet stuff was all dolphm, I think that will work well. Just need to figure out the signing stuff with it.17:00
morganfainbergthat error ^^ was using the latest patch w/ dolph's fernet thing and setting horizon to use v3 then trying to login via horizon17:01
dolphmlbragstad: ^^ my task for today. i'd much rather only support one or the other approach though, if there's a distinct advantage one way or the other17:01
morganfainbergi didn't have time to dig in further yet17:01
dolphmmorganfainberg: oh yeah, i saw you paste that backtrace on friday17:01
morganfainbergbut this is my setup to make sure we get some real coverage going here17:02
morganfainbergsince this touches something we haven't really mucked with too much in what ~4 cycles?17:02
*** rwsu has joined #openstack-keystone17:05
ayoungmorganfainberg, dolphm lbragstad had a conversation with our team.  Interesting suggestion came up over key management17:09
ayoungmorganfainberg, dolphm lbragstad we already use python-keyring.17:10
dolphmin the client17:10
ayoungUse that as the managment interface, and then we can use all the things it abstracts as key stores17:10
ayoungto include the kernel keyring17:10
ayoungdolphm, yeah, we don't have it as a server dependency17:10
ayoungbut it splits the management off from python-crypto into appropriate layers17:11
ayoungsound about right?17:11
dolphmayoung: sounds like good intermediate step before supporting barbican17:14
ayoungdolphm, You really think it should go in Barbican?17:15
dolphmayoung: i'd like keys to be outside of keystone's responsibility17:15
ayoungI thought they were trying to not be the keys store for undercloud things, just for end user things,17:15
lbragstadfwiw, I talked to the barbican team a little bit about what we were doing with keys and they would be willing to hear some use cases once we have things firmed up a little more17:16
*** csoukup has joined #openstack-keystone17:16
ayoungSo.. LWT keys will be short lived.  If one is tossed,  it means that tokens are reported as invalid, and users need to request new tokens.  Keys like that typically don't go into a store house.  the KRA stuff in DOgtag was for encryption keys...escrow type stuff17:17
ayoungI would think that a Keystone server could keep the Key in memory, and if the server crashes...oh well.17:17
ayoungWe can do some form of persistence to guard against that, but I think we should have a design goal that the key never leaves the keystone server.17:18
*** _cjones_ has joined #openstack-keystone17:18
ayoungNow,  for the "many keystones sharing a key"  deployements, it would mean using Kite or comparable, but that still is not escrowed17:18
*** thedodd has joined #openstack-keystone17:21
openstackgerritLance Bragstad proposed openstack/keystone: Keystone Lightweight Tokens (KLWT)
lbragstadjorge_munoz: thanks for the review, comments addressed ^17:24
samueldmqhi guys .... I just found a bug on our driver_hints17:26
samueldmqbug #142474517:26
openstackbug 1424745 in Keystone "SQL is not able to honor multiple filters in driver_hints.Hints()" [Undecided,New] - Assigned to Samuel de Medeiros Queiroz (samueldmq)17:26
samueldmqmorganfainberg, henrynash ^17:26
*** jistr has quit IRC17:29
*** radez_g0n3 is now known as radez17:30
*** himangi has quit IRC17:31
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone: Change project name constraint
*** tqtran has joined #openstack-keystone17:41
*** david8hu has joined #openstack-keystone17:43
*** spandhe has joined #openstack-keystone17:44
*** lhcheng has joined #openstack-keystone17:50
*** lhcheng has quit IRC17:50
openstackgerritRodrigo Duarte proposed openstack/keystone: Add is_domain field in Project Table
openstackgerritRodrigo Duarte proposed openstack/keystone: Change project name constraint
*** afazekas_ has quit IRC18:07
*** david-lyle_afk is now known as david-lyle18:09
openstackgerrithenry-nash proposed openstack/keystone: Implement backend driver support for domain config
*** _cjones_ has quit IRC18:10
openstackgerritDavid J Hu proposed openstack/keystone: Version independent token issuance pipeline
*** _cjones_ has joined #openstack-keystone18:15
*** carlosmarin has quit IRC18:19
*** pnavarro has quit IRC18:20
*** rushiagr is now known as rushiagr_away18:27
morganfainbergayoung, all stuff we can discuss for managing the keys18:27
*** lhcheng has joined #openstack-keystone18:27
morganfainbergayoung, i think those are all things to look at. but i am inclined to think we need some level of durability on the key since we would *prefer* they don't get lost. that said, it isn't the end of the world if they are so extreme levels are less important18:28
*** harlowja has joined #openstack-keystone18:33
ayoungmorganfainberg, if the key is shared among multiple Keystone servers via Kite, then a machine that drops just rejoins the ring when it comes back up.  For the stand alone server deployment,  storing a symmetric key in non-volitile storage is probably OK, so long as the machine is properly secured.18:35
morganfainbergayoung, yes.18:36
ayoungSo...I wonder if Kite/Keyring is a possibility18:36
ayoungNot that I really want to code it18:36
morganfainbergayoung, probably.18:36
morganfainbergayoung, i mean, no reason it can't be18:36
ayoungWe Coo18:46
openstackgerritTelles Mota Vidal Nóbrega proposed openstack/keystone: List projects filtering by is_domain flag
ayoungDamn...I shall never attempt to mimic that again.18:46
openstackgerritTelles Mota Vidal Nóbrega proposed openstack/keystone: List projects filtering by is_domain flag
*** jaosorior has quit IRC18:51
*** Tahmina has quit IRC18:53
morganfainbergayoung, yeah don't mimic that again ;)18:57
* morganfainberg looks at gearman more18:59
morganfainberggearman is so much better than rabbit...18:59
morganfainbergit's like something designed for RPC (all personal opinion)18:59
*** amerine_ has quit IRC19:01
morganfainbergdolphm, ayoung, bknudson, gyee, henrynash, dstanek, marekd, stevemar, topol, jamielennox, ping: please review and the following patch today if you could.19:07
dstanekmorganfainberg: shore19:08
morganfainbergerm, presceeding19:08
morganfainbergnot following19:08
ayoungmorganfainberg, All I saw was "policy" and I was like...yeah19:09
ayoungthe recrusive patch...19:10
morganfainbergayoung, oh yeah19:10
ayoungBoth actions would require new rules in the policy.json file along with new API endpoints to control/represent them.19:10
ayoungWe need a better term than "rules"  for these.  That really is what should be meant by "endpoint"  isn't it?  What we call an endp;oint iws kindof a host or a service or somewierdthing19:11
*** ajayaa has quit IRC19:11
morganfainbergbknudson, re: my big concern here is that a lot of the constructs for "endpoints" and "services" are not applicable for the SPs and worse, we're changing a lot of the data provided (SPs don't have "regions"). we already backed ourselves into this corner once with trying to pin the SP stuff onto regions. we decided that was wrong and now we're tyring to pin it19:13
morganfainberg into endpoints19:13
morganfainbergbknudson, i'm thinking we need to define SPs (which would be non-keystone-token-enabled things) into it's own section, where the concepts don't really apply the same way as services/endpoints.19:14
bknudsonmorganfainberg: not being in regions is a good reason to not have the endpoints in the normal catalog19:16
morganfainbergbknudson, but we need them to be part of the catalog response so you can act on the SPs. adding another round trip to keystone to ask for SPs is awful ux. "i get a token, oh i want to know if i have SPs ask keystone, then ask keystone for SAML, then do the k2k request"19:17
ayoungThis conversation happend over a year ago.  Federation was originally going to list IdPs in the service catalog.19:17
morganfainbergi'm ok if we make the SP list more generic so you can list things like say CloudFoundry there.19:17
bknudsonmorganfainberg: most users of the token aren't going to care about the SPs, though, are they?19:17
morganfainbergbknudson, i would guess it could be a lot of users will and a lot wont19:17
morganfainbergbknudson, it depends on the reason you're using the k2k federation. Are you consuming a service that is not in your local cloud? e.g. sahara?19:18
bknudsonalso, it's always going to be the same, right?19:18
morganfainbergor are you spreading around load across different SP clouds?19:18
morganfainbergor is it just burst19:18
morganfainbergit wont always be the same, you might have 10 SPs, some SPs may be added or removed. a given project/domain may not have access to a given SP19:19
rodrigodsayoung, yeah... called "rule" the policy portion of the new API endpoint (recursive patch)19:19
morganfainbergbknudson, because the SAML is based upon your local information, not just that you can "auth" with your local cloud.19:19
ayoungrodrigods, I would think the right term should be something like Policy Enforcement Point (PEP)  or Policy Decision Point (PDP)  based on the XACML  docs I've seen.19:20
bknudsonI need a scoped token to get the service providers?19:21
morganfainbergbecause if you want to limit who can access say resources in a public cloud to only users of domain PublicWebSite, you should be able to do that19:22
openstackgerritMerged openstack/keystone: Enable filtering in LDAP backend for listing entities
rodrigodsayoung, it is being called target in the policy lib:
bknudsonthe catalog doesn't limit access... it's security through obscurity19:22
openstackgerritRaildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller
morganfainbergbknudson, no keystone will not issue SAML for the SP unless it's in the catalog19:23
rodrigodsayoung, anyway... do you think this name is a blocker in the spec?19:23
morganfainbergbknudson, therefore it is actually enforced, not security through security19:23
morganfainbergbknudson, or that is the intention19:23
ayoungrodrigods, it just ghot me thinking about policy...19:23
morganfainbergbknudson, s/security$/obscurity19:23
morganfainbergbknudson, and the SAML must be targeted to the SP, it's not *any* SAML that a keystone issues will work with the SP19:25
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Fixes test_multiple_filters filters definition
bknudsonok... maybe I19:26
bknudsonmaybe I'm just not a fan of adding another element to the "catalog" array?19:27
bknudsonI wouldn't be surprised if users were expecting a "catalog" entry to have "endpoints", "type", etc.19:27
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Exposes bug in SQL when honoring driver_hints
bknudsonI guess I don't see why { "service_providers": []} is better than { "endpoints": [], "type": "service_providers" }19:28
bknudsondoes the current keystoneclient code even work with a catalog like this?19:29
lbragstadwrong window19:31
openstackgerritLance Bragstad proposed openstack/keystone: Keystone Lightweight Tokens (KLWT)
openstackgerritLance Bragstad proposed openstack/keystone: Use revocation events for lightweight tokens
bknudsonlooks like keystoneclient requires ['type'] in the service catalog:
morganfainbergKsc would work but that is because it should ignore it. New ksc would support it. Since we are defining the response now new ksc should be fine that way.19:35
bknudsonksc doesn't ignore it.19:35
bknudsonoh, it's got a catch for keyerror19:36
*** pnavarro has joined #openstack-keystone19:37
bknudsonseems like if we used { "endpoints": [], "type": "service_providers" } then the client would just work.19:38
*** pdesai has joined #openstack-keystone19:39
morganfainbergMy only concern is providing new/very different info in the endpoint list. So it won't confirm to current endpoint data (we need the sp-url etc)19:41
morganfainbergWhich is why I thought the sp list being explicitly different was good.19:41
stevemarbknudson, aren't we just bastardizing endpoints instead of services at that point19:42
dolphmmorganfainberg: ++19:42
bknudsonI thought we were hoping to get rid of the "public" / "internal" / "admin" endpoints anyways.19:43
bknudsonendpoints are a bastard already19:43
bknudsonand why would somebody be looking at endpoints for a type='service_providers' unless the application knows how to talk to 'service_provider' endpoints.19:44
dolphmbknudson: i'd like to get rid of "admin" -- public / internal have clear uses19:44
morganfainbergdolphm: ++19:45
bknudsonpublishing internal endpoints externally is not useful.19:45
openstackgerritSteve Martinelli proposed openstack/keystone: Enhance user identification in mapping engine
openstackgerritSteve Martinelli proposed openstack/keystone: Make Rule.Processor_UserType class public
bknudsonhow about move the "service_providers" out of the "catalog" ?19:46
morganfainbergbknudson: where to? Something that requires another api call to check if you can use them?19:47
morganfainbergThis feels like catalog type data19:47
bknudsonI guess that doesn't fit the general model.19:47
morganfainbergBut it doesn't conform to service/endpoint data models.19:47
dolphmi don't think a centralized catalog should be trying to determine if the client can reach a specific network or not19:48
*** openstackgerrit has quit IRC19:51
*** openstackgerrit has joined #openstack-keystone19:52
morganfainbergjamielennox: how hard would it be to add in some DNS serv record lookup support into the auth plugins? Or does that not really make sense?19:53
morganfainbergOr sessions19:53
*** browne has joined #openstack-keystone19:56
morganfainbergayoung: you know i misread your topic as "Adam can do everything..." ;)20:00
*** pdesai1 has joined #openstack-keystone20:01
*** pdesai has quit IRC20:03
*** gabriel-bezerra has joined #openstack-keystone20:04
*** rm_work|away is now known as rm_work20:07
*** stevemar has quit IRC20:07
*** markvoelker has joined #openstack-keystone20:07
*** drjones has joined #openstack-keystone20:10
*** c_soukup has joined #openstack-keystone20:10
*** _cjones_ has quit IRC20:10
*** csoukup has quit IRC20:11
*** c_soukup has quit IRC20:14
lhchengdolphm: I am currently looking at the templated catalog driver, it is inheriting from the kvs driver.  all the crud operation from kvs driver is inherited as well.  That doesn't right.20:17
*** thedodd has quit IRC20:17
lhchengdolphm: it is an old code, thought you might have insight on it.20:17
dolphmlhcheng: i actually think that pattern should be extended much further -- the templated driver, if we have any interest in keeping it, should do nothing but populate an in-memory kvs driver on __init__()20:18
lhchengdolphm: here is the related code:
dolphmlhcheng: so it shouldn't override anything but __init__()20:19
lhchengdolphm: I tried stripping the crud operations on the templated catalog, but our tests are relying on the hybrid behavior of the templated catalog. :(20:19
lhchengdolphm: yeah.. that might be the right way to go, while keeping the test working.20:20
lhchengdolphm: don't we need to override the get_catalog() too:
lhchengdolphm: it relies that there is a service catalog stored for each project/user combination20:22
dolphmlhcheng: the "hybrid" behavior?20:22
*** csoukup has joined #openstack-keystone20:22
lhchengdolphm: the templated catalog driver having 1.) get_catalog() reading from template file 2) kvs behavior for the crud operations20:23
dolphmmorganfainberg: can we just kill the kvs & templated catalog drivers as "broken and unmaintained"20:23
dolphmlhcheng: why do you have an interest in fixing it?20:23
dolphmit almost looks like the templated version of get_catalog would work better than the kvs version20:25
lhchengdolphm: we're actually not using it, just picking up outstanding bugs in keystone.20:25
dolphmif the kvs version works at all20:25
dolphmlhcheng: i'd propose to fix it by deleting it, because clearly no one has supported it20:26
lhchengdolphm: maybe I should just put the bug back :)
openstackLaunchpad bug 1156298 in Keystone "templated Catalog backend does not support listing services or endpoints" [Medium,Confirmed] - Assigned to Lin Hua Cheng (lin-hua-cheng)20:26
lhchengdolphm: hmm true20:26
lhchengdolphm: mark this as deprecated for now then?20:27
dolphmlhcheng: i'm surprised it's not already deprecated20:27
dolphmlhcheng: is it even useable? if not, deletion makes more sense than a deprecation cycle20:28
dolphmlhcheng: i'd also be curious what impact deleting it would have on our tests20:28
lhchengdolphm: the get_catalog() do work20:28
lhchengdolphm: tried setting it up, typical operations works on KSC like crud on user/project20:29
dolphmlhcheng: does the kvs one work in the real world?20:29
*** stevemar has joined #openstack-keystone20:30
*** ChanServ sets mode: +v stevemar20:30
lhchengdolphm: for the tests, they'll be work needed. our tests relies heavily on it.  Tried switching the test to use catalog sql backend, but it doesn't work out of the box, it would require some work.20:30
lhchengdolphm: no idea if the kvs work in the real world :)20:31
dolphmlhcheng: that's probably the reason the backend still exists!20:31
dstaneklhcheng: dolphm: i have code that fixes the templated catalog; and deletes kvs20:31
dolphmdstanek: what does it take to fix templated?20:31
lhchengdolphm: heh no one wants to fix the test.20:32
lhchengdstanek: nice!20:32
dolphmlhcheng: except dstanek20:32
dstanekdolphm: it doesn't seem too terrible; i'm cleaning commits to push now actually20:33
lhchengdstanek: \o/20:33
dstanekit seems that we actually have tests for the templated catalog that really shouldn't exist20:33
*** harlowja has quit IRC20:34
*** harlowja_ has joined #openstack-keystone20:34
lhchengdstanek: yeah, a lot. it is inheriting the catalog crud tests20:34
stevemarmorganfainberg, so bknudson seems very anti-thread.local() - should i continue to look into it?20:37
stevemarbknudson, how serious were your comments about it20:37
morganfainbergstevemar, and he should be.20:37
openstackgerritDavid Stanek proposed openstack/keystone: Uses SQL catalog driver for v2 REST tests
dstanekstevemar: i hate thread local too!20:38
dstaneklhcheng: see that commit ^20:39
bknudsonstevemar: serious.20:39
lhchengdstanek: yeah, I saw that issue too while trying to fix the catalog test.20:40
lhchengdstanek: so templated catalog, should really support write? as in writing back to file or in-memory?20:41
dstaneklhcheng: i also have a patch coming that separates kvs from templated20:41
dstaneklhcheng: it supports write (almost) right now20:41
lhchengdstanek: I should asked you first, I was looking at these over the weekend :P20:41
dstanekthat's the issue; you can create_* and get them back with the list operations, but never in the get_catalog20:42
lhchengdstanek: yeah, the get_catalog() in kvs is just broken20:43
*** jogo has joined #openstack-keystone20:45
morganfainbergrodrigods, raildo, samueldmq, ping: re reseller spec20:45
lhchengdstanek: I'll leave the bug reported as is for now, maybe after your changes goes in, all the issues have already been fixed :)20:45
raildomorganfainberg, hi :)20:45
morganfainbergrodrigods, raildo, samueldmq, want to ask if you guys would be interested in trying out a new concept for a feature branch and how it's merged to the code base - jogo can describe it more in depth, but it's basically creating a short-lived topic branch where you20:45
dstaneklhcheng: i didn't realize that there are multiple bugs for this20:45
morganfainbergre given the ability to +2 it, (so you +2, and a keystone core +2 to merge it).20:46
gyeemorganfainberg, just commented on
morganfainbergonce the feature is done (reseller in this case) we can merge the whole branch to master.  This is totally optional20:46
morganfainbergraildo, rodrigods, samueldmq, and the final merge to master requires more core-reviewer eyes.20:47
*** jorge1 has left #openstack-keystone20:47
openstackgerritTelles Mota Vidal Nóbrega proposed openstack/keystone: List projects filtering by is_domain flag
morganfainbergbut i'll let jogo explain a little more in detail.20:47
morganfainbergi *think* the reseller work is a good candidate for this.20:47
morganfainberggyee, thanks.20:47
raildomorganfainberg, something similar what we did with HMT in the past?20:48
samueldmqmorganfainberg, would this late the reseller code merge?20:48
morganfainbergsamueldmq, it would not change the target of k320:48
morganfainbergsamueldmq, if it doesn't land in k3, we're past freeze for it anyway.20:49
morganfainbergthis *may* be too late to try with reseller, jogo - but we can see.20:49
morganfainbergraildo, it's a little different.20:49
gyeemorganfainberg, for the service provider thingy, I am OK with which ever direction we are heading, I just won't put a +2 on it as it currently constitutues, I can remove the -120:49
*** csoukup has quit IRC20:49
jogomorganfainberg raildo samueldmq: not exactly the same20:50
morganfainberggyee, thats fine. i didn't want to go against your opionion if it was very strongly against. the reasons are laid out but we have more people in the conversation now. we could make either work.20:50
lhchengdstanek: yeah, you want to just pickup those bug so you can keep track all templated catalog related bugs?,
openstackLaunchpad bug 1156298 in Keystone "templated Catalog backend does not support listing services or endpoints" [Medium,Confirmed] - Assigned to Lin Hua Cheng (lin-hua-cheng)20:50
openstackLaunchpad bug 1424373 in Keystone "Service CRUD is allowed in templated catalog" [Wishlist,New] - Assigned to Lin Hua Cheng (lin-hua-cheng)20:50
jogoone difference is people who are not general keystone-cores can get +2 power on the feature branch20:51
samueldmqjogo, what would be the advantage of this?20:51
morganfainberggyee, the data being as different as it is, makes it a bad candidate for the normal endpoint section. we did a clear definition of what endpoints look like. i don't want to change that definition.20:51
*** markvoelker has quit IRC20:51
jogoCreate new branch with different ‘core’ team. This can only be done by core (sponsor).20:52
gyeemorganfainberg, it'll work either way, its more of a question of consistency20:52
jogonew team follows 2 +2s. responsible for merging in master. Do not require main core team to 2 +2 each patch on feature branch.20:52
jogomain core team evaluates feature at end, and merges it into master20:52
jogorequire core(s?) besides branch sponsor to review it.20:52
jogoreview at end *should* not  be as detailed as a per patch review. design review vs. code review.20:52
jogodelete feature branch20:52
jogouniform code quality issue?20:52
jogocannot distribute separately20:52
jogomy notes on the topic: ^20:52
jogosamueldmq: to make it easier to land the feature, by empowering people who are working on the feature to get +2 power over there branch20:53
jogoso instead of requiring two keystone cores to review each patch, you would just need two feature branch cores to review each patch.20:54
jogowhich should be easier to do20:54
morganfainbergalso anyone else feel free to weigh in on this idea ^ i mean, i don't want anyone to feel like we're doing this without other core consent (i support this idea for the right cases, but if we have big concerns...)20:54
samueldmqjogo, and keystone cores to only approve it to get merged on master at the end, right?20:54
jogosamueldmq: yes. although to create the feature branch would require a keystone-core to sponsor it and decide who should get core on the feature branch etc.20:55
raildojogo, morganfainberg  I like the idea, but who will participate in this new 'core' team?20:55
raildosomeone for nova-core?20:55
gyeewhat are we taling about?20:55
gyeeraildo, "new core team"?20:56
raildoayoung, henrynash, gyee ?20:56
gyeewhich project?20:56
jogoraildo: the keystone core sponsor can decide who gets feature branch core. most likely the people who are interested in the feature20:56
raildojogo, great.20:56
samueldmqjogo, ++20:56
* gyee is seeing fogs20:56
samueldmqgyee, yep .. see a few messages back from jogo ..20:56
raildogyee, a feature branch to reseller, with a "new core team"20:56
jogogyee: talking about short lived feature branches with there own 'feature-branch core team'20:57
morganfainbergraildo, so for example if henrynash [picking on him because he's quiet] sponsors it, he could assign a core like rodrigods and raildo, then you'd get Henry to +2 things, and one of raildo and rodrigods to +2 it on the feature branch20:57
raildomorganfainberg, i get it.20:57
jogomorganfainberg: exactly20:57
raildomorganfainberg, I like the idea. i'll just talk with rodrigods and come back with the confirmation, ok?20:58
raildo(he is not here, right now)20:58
morganfainbergraildo, of course. and like i said it might be too close to k3 to really try this20:58
morganfainbergbut next cycle we might jump on this for a bp.20:58
morganfainbergif this doesn't work20:58
morganfainbergjogo, lets circle up @ keystone meeting tomorrow to confirm20:59
morganfainbergjogo, that way if there are any other concerns we can address them there as well.20:59
gyeeraildo, jogo, I see. But "big merge" from feature branch to master still require keystone core policy right?20:59
morganfainbergjogo, and/or timing issues.20:59
samueldmqmorganfainberg, ++ makes sense ... let's see other cores views... if they have any concern about trying this now20:59
samueldmqgyee, yep20:59
raildomorganfainberg, this will be perfect, we can confirm and define the core team tomorrow in the meeting20:59
morganfainberggyee, yes. the merge from topic branch -> master requires keystone core (not topic core)21:00
jogogyee: yes21:00
jogomorganfainberg: sounds great, thanks!21:00
lhchengmorganfainberg: opened a bug in django_openstack_auth to make the parsing of service catalog less error prone:
openstackLaunchpad bug 1424825 in django-openstack-auth "Parsing of service catalog should be less error prone" [Undecided,New]21:00
morganfainbergjogo, please add yourself here:
jogothanks everyone!21:01
morganfainbergjogo, :)21:01
samueldmqjogo, np :)21:01
morganfainbergjogo, 1800 UTC and you'll be the first topic.21:01
jogomorganfainberg: should I add the topic as well? or will you21:01
morganfainbergjogo, add the topic there.21:01
dstaneklhcheng: ok21:01
jogooh I see21:01
morganfainberganyone can add the topic.21:01
dstanekdolphm: you still around?21:02
morganfainbergjogo, makes it easier for me to let people jump in vs. specifically adding topics.21:02
stevemarbknudson, btw, can you take a looksy at - it's rebased on master now, as you had requested21:03
*** nicodemos has quit IRC21:03
openstackgerritSteve Martinelli proposed openstack/keystone: Remove incubated version of oslo policy
morganfainbergstevemar oh we released oslo.policy? score21:04
bknudsonoslo.policy isn't released... still needs some changes.21:04
stevemarmorganfainberg, it was a quiet release21:04
morganfainbergstevemar, ah.21:04
morganfainbergbknudson, stevemar, ++21:04
stevemarbknudson, we did actually tag a release, but didn't announce21:04
bknudsonok... dhellmann said that there were some changes needed to oslo.policy?21:05
bknudsonbased on some comments in a review.21:05
*** bknudson has quit IRC21:05
dolphmdstanek: yes21:05
stevemarbknudson, 2 of the comments were unnecessary, as I was using CONF.blah instead of accessing them from the Enforcer21:06
openstackgerritDavid Stanek proposed openstack/keystone: Removes KVS catalog backend
openstackgerritDavid Stanek proposed openstack/keystone: WIP: Support read operations for templated catalogs
stevemarand the other one was a test fixture request, but I worked around it21:06
dstanekdolphm: untested hack from this morning
dstanekthat's just to support read operations21:06
jogomorganfainberg: and done21:07
morganfainbergjogo, awesome! :)21:07
morganfainbergjogo, and if [due to k3] timing is bad we can aim for something in L, i expect to open specs for L just after K3, so good lead time21:07
*** raildo is now known as raildo_away21:08
jogosounds like a plan21:08
dolphmdstanek: what's with _DictKvs?21:09
dstanekdolphm: i added that to the prior commit - until this morning i didn't think i would be getting rid of it so fast21:10
dolphmdstanek: lol but why did you implement it?21:10
dolphm / why is it necessary21:10
dolphmoh that's from
dstanekdolphm: it already existed21:11
morganfainbergdolphm, yeah that was already there21:11
dstanekdolphm: yeah, until this morngin i was planning on keeping all of the kvs methods around and just deprecate them21:11
dstanekthat was before i took over
openstackLaunchpad bug 1156298 in Keystone "duplicate for #1289078 templated Catalog backend does not support listing services or endpoints" [Medium,Confirmed] - Assigned to David Stanek (dstanek)21:12
*** ayoung has quit IRC21:12
dolphmdstanek: i like the result of the last 2 changes combined -- any reason not to squash? the intermediate state is less appealing21:13
dstanekdolphm: i wasn't sure if which we would want; deprecate all the things or fixed21:14
dstaneki was going to bring it up in the meeting tomorrow - does backward compatibility matter here...21:15
morganfainbergso.. if we wouldn't break people deploying this with things just "fixed"21:15
*** markvoelker has joined #openstack-keystone21:15
morganfainbergi'd say just fix21:15
morganfainbergif it would break people, deprecate and fix21:15
dstanekso right now all of the templated methods almost work21:15
*** markvoelker has quit IRC21:15
dstanekyou can create stuff and get a list of it back21:16
*** markvoelker has joined #openstack-keystone21:16
openstackdolphm: Error: "almost!" is not a valid command.21:16
dstanekbut it will never be in the catalog21:16
morganfainbergopenstack, your so silly21:16
dstanekit could break people, but IMO they are already broken and probably don't know it21:16
* morganfainberg waits for the obligatory s/your/you're from the bot or someone else21:16
dolphm!An invalid command21:17
openstackdolphm: Error: "An" is not a valid command.21:17
dstanek!a valid command21:18
openstackdstanek: Error: "a" is not a valid command.21:18
openstackmorganfainberg: Error: "!" is not a valid command.21:18
stevemarmorganfainberg, hey, do you know what the comment here is;
morganfainbergstevemar, it's the same thing i do with config_overrides in other tests21:20
morganfainbergstevemar, i think21:21
morganfainbergwhat is self.orig_policy_file used for?21:22
dstanekstevemar: it looks like he things we are setting the value for the test and unsetting after, but the code looks like it just makes an alias21:22
*** pdesai1 has quit IRC21:22
morganfainbergstevemar, it also looks like self.orig_policy_file may not be used21:22
stevemarah yay21:22
stevemaryep, it's not21:23
*** radez is now known as radez_g0n321:23
stevemari wonder if rules even needs to be reset21:23
lbragstadjorge_munoz: I'm going to push another version of the revocation patch for lightweight tokens.21:26
lbragstadjorge_munoz: just wanted to give you a heads up in case your working on it21:26
lbragstadjorge_munoz: adding some more test cases with disabled users.21:27
*** rushiagr_away is now known as rushiagr21:27
openstackgerritLance Bragstad proposed openstack/keystone: Use revocation events for lightweight tokens
*** samueldmq is now known as samueldmq-away21:30
*** pdesai has joined #openstack-keystone21:31
*** pnavarro has quit IRC21:35
morganfainbergstevemar, if rules needs to be reset, it likely should be an addCleanup not a "oh just reset these things"21:35
dstanekalias wft='rm -rf .testrepository; tox'21:38
dstanekproblem fixed21:38
* morganfainberg disappears for a bit to stare at gearman + oslo.messaging21:42
morganfainbergping me if you need me.21:42
*** karimb has joined #openstack-keystone21:45
*** samueldmq has joined #openstack-keystone21:48
*** karimb has quit IRC21:48
*** abhirc has joined #openstack-keystone21:52
*** gabriel-bezerra has quit IRC21:58
*** henrynash has quit IRC22:01
*** pdesai has quit IRC22:02
*** csoukup has joined #openstack-keystone22:10
stevemardstanek, nice alias22:10
dstanekthat's actually in my zsh aliases now22:11
stevemardstanek, i believe you22:11
dstanekwtf -e functional22:11
stevemarmorganfainberg, dhellmann i'll post a follow up patch for the oslo.policy changes to the tests, since i think there are no issues with the actual code changes22:12
morganfainbergstevemar, cool22:12
stevemardhellmann, it would require another release of oslo.policy to make use of sigmavirus24's 'from_dict' change22:13
stevemardhellmann, then actually adding it to g-r22:13
dhellmannstevemar: we can make another release in the morning, if the code is ready22:13
openstackgerritDavid Stanek proposed openstack/keystone: Support for running functional federation tests
openstackgerritDavid Stanek proposed openstack/keystone: enables bashate checking on dsvm code
openstackgerritDavid Stanek proposed openstack/keystone: adds a devstack plugin for running a pysaml2 IdP
openstackgerritDavid Stanek proposed openstack/keystone: adds a devstack plugin for setting up federation
openstackgerritDavid Stanek proposed openstack/keystone: adds a tox target for functional tests
openstackgerritDavid Stanek proposed openstack/keystone: Adds an initial functional test
morganfainbergstevemar, let me know when you post it/ anything that needs eyes before morning22:14
* sigmavirus24 waves22:14
stevemardhellmann, i think we're good for the morning, there are no open changes to oslo.policy and if we're all good with the changes to keystone then i don't see a reason why not22:15
stevemarsigmavirus24, !!22:15
*** pdesai has joined #openstack-keystone22:15
sigmavirus24so much red stevemar22:15
stevemarsigmavirus24, only in 1 file :P22:16
sigmavirus24it only takes 1 =P22:16
*** radez_g0n3 is now known as radez22:16
*** nellysmitt has quit IRC22:16
*** nellysmitt has joined #openstack-keystone22:16
*** nellysmitt has quit IRC22:17
*** aix has joined #openstack-keystone22:26
*** mattfarina has quit IRC22:28
*** rushiagr is now known as rushiagr_away22:29
*** harlowja_ has quit IRC22:29
*** harlowja has joined #openstack-keystone22:30
*** gabriel-bezerra has joined #openstack-keystone22:30
*** pdesai has quit IRC22:32
mfischjamielennox: you around?22:34
stevemarmfisch, try again in 4 hours22:37
mfischoh yeah, thx22:38
*** Tahmina has joined #openstack-keystone22:45
*** pdesai has joined #openstack-keystone22:46
*** pdesai has quit IRC22:47
*** radez is now known as radez_g0n322:55
mfischjamielennox: unping22:57
*** chrisshattuck has joined #openstack-keystone22:58
*** pdesai has joined #openstack-keystone23:00
jamielennoxmfisch: yea23:03
jamielennoxstevemar: the timezones aren't that far of23:04
*** harlowja has quit IRC23:04
*** rwsu is now known as rwsu-afk23:04
stevemarjamielennox, ha, jokes on you, now i can ask you ksc questions23:04
*** raildo has joined #openstack-keystone23:04
jamielennoxstevemar, gyee: i was waiting till today to talk about some of this service_catalog stuff23:05
jamielennoxlhcheng: i put a comment on your bug 1424825 don't have DOA handle the catalog, let the plugins do that for you23:05
openstackbug 1424825 in django-openstack-auth "Parsing of service catalog should be less error prone" [Undecided,New]
lhchengjamielennox: yeah, thanks for that! Didn't notice that auth plugins also exposes a get_endpoint() method23:06
*** stevemar has quit IRC23:07
jamielennoxlhcheng: yep - so there is no way to iterate through a catalog which horizon might have a case for, but in general horizon shouldn't need it23:07
lhchengjamielennox: there is another set of code in horizon that tries to parse the raw service catalog, have to clean that up as well.23:07
jamielennoxclients shouldn't need it23:07
*** stevemar has joined #openstack-keystone23:07
*** ChanServ sets mode: +v stevemar23:07
jamielennoxlhcheng: i want to see what we can do about passing the ksc.Session and auth plugin through to the rest of horizon so that clients can be instantiated with it23:08
jamielennoxi don't know how to get there yet23:08
jamielennoxstill figuring out some other DOA stuff23:08
lhchengjamielennox: I agree clients should not handle the manual parsing of the catalog. There is a code in horizon that handles parsing of the v2/v3 format of service catalog, we need to clean that up too :( hopefully get_endpoint() will provide all the filtering horizon needed.23:10
*** devlaps has quit IRC23:14
*** devlaps has joined #openstack-keystone23:14
*** harlowja has joined #openstack-keystone23:16
*** amaurymedeiros has quit IRC23:20
*** amaurymedeiros has joined #openstack-keystone23:20
gyeejamielennox, what's your view on service catalog?23:21
jamielennoxgyee: torn23:21
jamielennoxinitially i was thinking that k2k should be unscoped only but i see that doesn't make sense23:22
jamielennoxfrom a practical point of view i don't think the current service catalog code will handle it23:22
jamielennoxthe way we check for type is kind of dumb23:22
gyeebut ksc accept a generic filter no?23:23
gyeewhich is basically a dict23:23
jamielennoxI think that the service catalog is a directory of things that the current token lets you access - and by that definition an external keystone counts23:23
jamielennoxhowever the way you use that endpoint is going to be completely diferent23:23
gyeeright, its just for endpoint lookup, nothing more23:24
jamielennoxi'm trying to come up with what i think is a good experience from a client (language/implementation agnostic) perspective and i'm not sure how we expect this bursting to work23:24
gyeewhat are you going to do with that endpoint is strictly between you and the service provider23:24
gyeesince the days of xml schema are long gone :)23:25
jamielennoxi can see more benefit in iterating service providers than i do from endpoints though23:26
jamielennoxand again i'm trying not to bring too much current implementation problems into it, but the exposure we currently give is get_endpoint for a service type23:26
gyeewhat? I thought get_endpoint accepts a filter23:27
jamielennoxit does23:27
jamielennoxbut it returns a single string23:27
gyeewhich is the url23:28
*** jsavak has quit IRC23:28
*** amerine has joined #openstack-keystone23:30
gyeewhich is good enough23:32
gyeeunless we need more than a url23:32
gyeeas everything else should be discoverable23:32
gyeevia json home or other mechanisms23:32
jamielennoxgyee: don't you think we want to standardize that a little more?23:33
jamielennoxat the moment the service catalog holds together because of a convention pretty much defined by devstack23:33
jamielennoxso my concern with the current get_endpoint only returning a string is you are asking for something particular23:35
*** krtaylor has quit IRC23:35
jamielennoxand it was designed specifically to be used by multiple clients via request(..., endpoint_filter={}) rather than plugin.get_endpoint()23:35
jamielennoxso yes, you could find the endpoint for a service provider based on a filter - but do you think that would be the common use case?23:36
*** mfisch has quit IRC23:36
jamielennoxwouldn't it be more, "hey show me all other service providers, run out get me a token on all of them, and then lets see what i can do there23:36
gyeejamielennox, GET /v3/services?type=abc23:37
*** gordc has quit IRC23:37
gyeeto me, catalog in token data service two purposes23:38
jamielennoxgyee: if you're going to do that we don't need a catalog23:38
gyee1) lookup endpoints user have access to23:38
gyee2) endpoint constraints23:38
gyeethere's no point of show services user have no access to23:39
*** abhirc has quit IRC23:41
*** abhirc has joined #openstack-keystone23:41
*** csoukup has quit IRC23:46
*** krtaylor has joined #openstack-keystone23:47
*** MasterPiece has joined #openstack-keystone23:53
*** mfisch has joined #openstack-keystone23:54
*** mfisch has quit IRC23:54
*** mfisch has joined #openstack-keystone23:54
*** pdesai has quit IRC23:58
*** Tahmina has quit IRC23:59

Generated by 2.14.0 by Marius Gedminas - find it at!