| *** lhcheng has joined #openstack-keystone | 00:00 | |
| *** lhcheng has quit IRC | 00:04 | |
| *** diegows has joined #openstack-keystone | 00:12 | |
| *** markvoelker has joined #openstack-keystone | 00:16 | |
| *** markvoelker has quit IRC | 00:20 | |
| *** ncoghlan has joined #openstack-keystone | 00:32 | |
| *** rm_work is now known as rm_work|away | 00:35 | |
| *** Akshik has joined #openstack-keystone | 00:43 | |
| *** Akshik has quit IRC | 00:43 | |
| *** markvoelker has joined #openstack-keystone | 00:50 | |
| *** markvoelker has quit IRC | 00:55 | |
| *** lhcheng has joined #openstack-keystone | 01:01 | |
| *** lhcheng has quit IRC | 01:05 | |
| *** boris-42 has joined #openstack-keystone | 01:13 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Using correct keyword for region in v3 https://review.openstack.org/118383 | 01:38 |
|---|---|---|
| *** dimsum__ has joined #openstack-keystone | 01:38 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Add default body for non-abstract empty methods https://review.openstack.org/155962 | 01:38 |
| *** dims_ has joined #openstack-keystone | 01:39 | |
| openstackgerrit | Brant Knudson proposed openstack/python-keystoneclient: Add OS-SIMPLE-CERT support for v3. https://review.openstack.org/142200 | 01:39 |
| *** dimsum__ has quit IRC | 01:43 | |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Document mapping of policy action to operation https://review.openstack.org/155919 | 01:48 |
| *** markvoelker has joined #openstack-keystone | 01:51 | |
| *** markvoelker has quit IRC | 01:57 | |
| *** markvoelker has joined #openstack-keystone | 02:00 | |
| *** diegows has quit IRC | 02:04 | |
| *** stevemar has joined #openstack-keystone | 02:21 | |
| *** ChanServ sets mode: +v stevemar | 02:21 | |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Exposes bug in Federation list projects endpoint https://review.openstack.org/158163 | 02:21 |
| *** erkules_ has joined #openstack-keystone | 02:22 | |
| *** erkules has quit IRC | 02:25 | |
| *** markvoelker has quit IRC | 02:26 | |
| *** markvoelker has joined #openstack-keystone | 02:27 | |
| *** markvoelker has quit IRC | 02:31 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Enable endpoint_policy, endpoint_filter and oauth by default https://review.openstack.org/153842 | 02:41 |
| *** himangi has quit IRC | 02:58 | |
| morganfainberg | stevemar, any thoughts on thread.local() vs passing context in to methods to do exactly nothing with it? | 03:17 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Separate exceptions into their own file https://review.openstack.org/157277 | 03:20 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Extract revocations to file https://review.openstack.org/157279 | 03:20 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Extract SigningDirectory into file https://review.openstack.org/157278 | 03:21 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Extract IdentityServer into file https://review.openstack.org/157282 | 03:21 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Move UserAuthPlugin into its own file https://review.openstack.org/157283 | 03:21 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Break default auth plugin into file https://review.openstack.org/157280 | 03:21 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Extract all TokenCache related classes to file https://review.openstack.org/157281 | 03:21 |
| stevemar | morganfainberg, hadn't given it a thought yet | 03:24 |
| stevemar | morganfainberg, don't know anything about thread.local() and haven't had time to look into it | 03:25 |
| morganfainberg | stevemar, it's how pecan does it. but in short, it is a local() store for <things> that is isolated to a given thread | 03:25 |
| morganfainberg | in eventlet / multithreading it is per greenlet/thread | 03:26 |
| morganfainberg | in multiprocessing (with no threads) it's just the per-process as you'd expect | 03:26 |
| morganfainberg | so you basically do thread_local = threading.local() | 03:26 |
| morganfainberg | and you can store data in it | 03:26 |
| morganfainberg | and access it elsewhere with the same mechanism | 03:26 |
| *** samueldmq_ has quit IRC | 03:28 | |
| jamielennox | morganfainberg, stevemar: can you do: https://review.openstack.org/#/c/157686/ quickly | 03:29 |
| jamielennox | +0,-0 | 03:29 |
| *** tellesnobrega_ has joined #openstack-keystone | 03:31 | |
| *** tellesnobrega_ has quit IRC | 03:31 | |
| stevemar | morganfainberg, i'll look into it soon (maybe tonight, maybe tomorrow) | 03:35 |
| stevemar | jamielennox, done | 03:35 |
| bknudson | thread.local is "spooky action at a distance" and should only be used in the direst of circumstances. | 03:36 |
| *** lhcheng has joined #openstack-keystone | 04:19 | |
| *** rwsu-afk has quit IRC | 04:19 | |
| *** lhcheng has quit IRC | 04:30 | |
| *** spandhe has quit IRC | 04:35 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Make post_test_hook.sh executable https://review.openstack.org/157686 | 04:44 |
| *** spandhe has joined #openstack-keystone | 04:52 | |
| *** himangi has joined #openstack-keystone | 04:52 | |
| *** rushiagr_away is now known as rushiagr | 04:56 | |
| *** lhcheng has joined #openstack-keystone | 05:17 | |
| *** lhcheng has quit IRC | 05:19 | |
| *** pcaruana has quit IRC | 05:45 | |
| *** lhcheng has joined #openstack-keystone | 06:12 | |
| *** rushiagr is now known as rushiagr_away | 06:20 | |
| stevemar | what the heck is 'legacy_endpoint_id' | 06:31 |
| stevemar | bknudson, good to know... | 06:31 |
| lhcheng | stevemar: isn't that the column used to convert the v3 endpoint data model to v2? | 06:33 |
| * stevemar shrugs at lhcheng | 06:34 | |
| stevemar | hows it determined? | 06:34 |
| stevemar | https://bugs.launchpad.net/keystone/+bug/1403408 | 06:34 |
| openstack | Launchpad bug 1403408 in Keystone "Redundant endpoints found in the table "endpoint"" [Undecided,Confirmed] - Assigned to Dave Chen (wei-d-chen) | 06:34 |
| lhcheng | stevemar: one row that stores pubic/internal/admin url for the region/service tpye | 06:35 |
| lhcheng | if you look at the default endpoint data in devstack, there are three records that matches the legacy_endpoint_id | 06:36 |
| lhcheng | the old endpoint data model, have three columns public/internal/admin url | 06:36 |
| lhcheng | instead of one row that we used to have now | 06:36 |
| stevemar | lhcheng, i get that, but does anything still use it now? | 06:37 |
| lhcheng | yeah, when hitting the v2.0/endpoints | 06:38 |
| lhcheng | https://github.com/openstack/keystone/blob/master/keystone/catalog/controllers.py#L72 | 06:38 |
| stevemar | lhcheng, that seems silly | 06:40 |
| lhcheng | stevemar: hmm yeah, the bug can be solve can compound unique constraint check | 06:40 |
| *** erkules_ is now known as erkules | 06:45 | |
| lhcheng | stevemar: 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 IRC | 06:58 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Reference OSC docs in CLI examples https://review.openstack.org/158202 | 07:01 |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Update `os service create` examples in config services https://review.openstack.org/158204 | 07:06 |
| stevemar | lhcheng, ^ | 07:06 |
| *** afazekas_ has joined #openstack-keystone | 07:06 | |
| *** mflobo has joined #openstack-keystone | 07:10 | |
| lhcheng | stevemar: good catch on updating the docs, thanks! | 07:14 |
| stevemar | :D | 07:14 |
| stevemar | sleep time! | 07:14 |
| lhcheng | stevemar: good night! | 07:16 |
| *** stevemar has quit IRC | 07:19 | |
| *** lhcheng has quit IRC | 07:27 | |
| *** rushiagr_away is now known as rushiagr | 07:34 | |
| *** atiwari2 has quit IRC | 07:35 | |
| *** krykowski has joined #openstack-keystone | 07:37 | |
| *** atiwari has joined #openstack-keystone | 07:44 | |
| *** jaosorior has joined #openstack-keystone | 07:54 | |
| *** lhcheng has joined #openstack-keystone | 07:59 | |
| *** henrynash has joined #openstack-keystone | 08:26 | |
| *** ChanServ sets mode: +v henrynash | 08:26 | |
| *** spandhe has quit IRC | 08:47 | |
| *** rushiagr is now known as rushiagr_away | 08:54 | |
| *** jistr has joined #openstack-keystone | 08:55 | |
| *** lhcheng has joined #openstack-keystone | 09:11 | |
| *** lhcheng has quit IRC | 09:12 | |
| *** ncoghlan has quit IRC | 09:31 | |
| openstackgerrit | henry-nash proposed openstack/keystone: Implement backend driver support for domain config https://review.openstack.org/158051 | 09:38 |
| *** henrynash has quit IRC | 09:51 | |
| *** rushiagr_away is now known as rushiagr | 09:58 | |
| *** fmarco76 has joined #openstack-keystone | 10:11 | |
| *** pnavarro has joined #openstack-keystone | 10:19 | |
| jamielennox | stevemar: 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 v2 | 10:19 |
| *** ccard has joined #openstack-keystone | 10:19 | |
| *** ajayaa has joined #openstack-keystone | 10:30 | |
| *** mzbik has joined #openstack-keystone | 10:32 | |
| samueldmq | morning :-) | 10:59 |
| *** krykowski has quit IRC | 11:00 | |
| *** krykowski has joined #openstack-keystone | 11:00 | |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend https://review.openstack.org/157327 | 11:07 |
| *** himangi has joined #openstack-keystone | 11:16 | |
| *** andreaf_ has joined #openstack-keystone | 11:20 | |
| *** andreaf_ has quit IRC | 11:22 | |
| *** aix has joined #openstack-keystone | 11:28 | |
| *** nellysmitt has joined #openstack-keystone | 11:29 | |
| *** diegows has joined #openstack-keystone | 11:36 | |
| *** MasterPiece has joined #openstack-keystone | 11:43 | |
| *** raildo has joined #openstack-keystone | 12:07 | |
| *** henrynash has joined #openstack-keystone | 12:16 | |
| *** ChanServ sets mode: +v henrynash | 12:16 | |
| *** vhoward has quit IRC | 12:19 | |
| *** henrynash has quit IRC | 12:20 | |
| *** henrynash has joined #openstack-keystone | 12:23 | |
| *** ChanServ sets mode: +v henrynash | 12:23 | |
| *** henrynash has quit IRC | 12:25 | |
| *** krykowski has quit IRC | 12:40 | |
| *** dims_ has quit IRC | 12:44 | |
| *** MasterPiece has quit IRC | 12:45 | |
| *** dimsum__ has joined #openstack-keystone | 12:51 | |
| *** zigo has quit IRC | 12:52 | |
| *** diegows has quit IRC | 12:53 | |
| *** zigo has joined #openstack-keystone | 12:56 | |
| *** henrynash has joined #openstack-keystone | 12:59 | |
| *** ChanServ sets mode: +v henrynash | 12:59 | |
| *** nicodemos has joined #openstack-keystone | 13:02 | |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone: Add is_domain field in Project Table https://review.openstack.org/157427 | 13:03 |
| *** krykowski has joined #openstack-keystone | 13:08 | |
| *** henrynash has quit IRC | 13:12 | |
| *** dimsum__ has quit IRC | 13:22 | |
| *** dimsum__ has joined #openstack-keystone | 13:22 | |
| *** lsmola has quit IRC | 13:23 | |
| *** henrynash has joined #openstack-keystone | 13:24 | |
| *** ChanServ sets mode: +v henrynash | 13:24 | |
| *** lsmola has joined #openstack-keystone | 13:27 | |
| *** gordc has joined #openstack-keystone | 13:30 | |
| rodrigods | henrynash, 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 |
| henrynash | rodigods: so what, conceptually, do you need it to be? | 13:37 |
| rodrigods | henrynash, yes... we want to have projects with the same name in the same domain (because the domain table -> project table migration) | 13:37 |
| rodrigods | but parent_id is a nullable column | 13:38 |
| rodrigods | and almost all mysql engines accept multiple null values for constraints | 13:38 |
| henrynash | rodigods: so I remember looking at nullable colums being part of unique constraints | 13:38 |
| rodrigods | henrynash, it considers two null values different | 13:39 |
| *** dimsum__ is now known as dims | 13:39 | |
| henrynash | rodigods: hmm | 13:39 |
| rodrigods | henrynash, we thought of two solutions | 13:39 |
| henrynash | rodigods: you may need to do the checks manually | 13:39 |
| rodrigods | use a flag in the parent_id instead of null | 13:39 |
| rodrigods | or do the check manually in the manager layer | 13:39 |
| bknudson | you don't have to rely on the database to enforce unique constraints, since the only user is keystone. | 13:40 |
| *** bknudson has quit IRC | 13:41 | |
| henrynash | rodigods: I’d agree with bknudson, doing the checks manually isn’t such a terrible thing in our case | 13:41 |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Implement group related methods for LDAP backend https://review.openstack.org/157327 | 13:41 |
| rodrigods | henrynash, great | 13:42 |
| *** joesavak has joined #openstack-keystone | 13:44 | |
| samueldmq | henrynash, I found a bug on federation.... regarding inherited roles from parents ... https://launchpad.net/bugs/1424500 | 13:48 |
| openstack | Launchpad 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 |
| henrynash | samueldmq: yes, saw that…. | 13:49 |
| henrynash | samueldmq: haven’t had a chance to look clsoely at it…but good practice to great a test that shows the failure first…nice | 13:49 |
| samueldmq | henrynash, :) | 13:50 |
| samueldmq | henrynash, I was planning to modify list_role_assignments ... | 13:50 |
| samueldmq | henrynash, it should receive honor_group, honor_inheritance ... that would be True by default | 13:50 |
| samueldmq | henrynash, then the federation methods could call it with honor_inheritance = True and honor_group = False to get group assingments | 13:50 |
| samueldmq | henrynash, if you remember .. we had a conversation in the past about this .. | 13:51 |
| henrynash | samueldmq: 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 |
| samueldmq | henrynash, I think it will add a few lines in the code | 13:53 |
| henrynash | samuledmq: ok, do a patch and I’ll happily review | 13:53 |
| samueldmq | henrynash, I'll add such support in a separate patch .. so we can look at it separately from the big refactoring | 13:53 |
| samueldmq | henrynash, great thx | 13:53 |
| henrynash | sameuldmq; sounds good | 13:53 |
| samueldmq | henrynash, ack, will work on this later today ,... working on reseller today :-) | 13:54 |
| *** ljfisher has joined #openstack-keystone | 13:55 | |
| samueldmq | henrynash, btw, I have a question related to domain specific backends ... | 13:55 |
| henrynash | samueldmq: sure | 13:55 |
| samueldmq | henrynash, the additional domains will created on a SQL resource backend, right? | 13:56 |
| henrynash | samueldmq: yes | 13:56 |
| samueldmq | henrynash, k ... this is causing tests to fail once we have a is_domain project per domain ..... :/ | 13:57 |
| samueldmq | henrynash, but now I have info needed to fix it .. thx | 13:57 |
| henrynash | samueldmq: yes, we’ll need to change it a little bit for that | 13:58 |
| samueldmq | henrynash, but now I have info needed to fix it .. thx | 13:58 |
| henrynash | ok | 13:58 |
| samueldmq | oops .. repeated the message .... in fact I tried to go to the terminal and re-run last tests | 13:59 |
| samueldmq | sorry | 13:59 |
| samueldmq | :-) | 13:59 |
| samueldmq | henrynash, ^ | 13:59 |
| *** ayoung has joined #openstack-keystone | 14:00 | |
| *** ChanServ sets mode: +v ayoung | 14:00 | |
| *** krykowski_ has joined #openstack-keystone | 14:01 | |
| *** krykowski has quit IRC | 14:02 | |
| *** bknudson has joined #openstack-keystone | 14:05 | |
| *** ChanServ sets mode: +v bknudson | 14:05 | |
| *** diegows has joined #openstack-keystone | 14:12 | |
| *** Guest28285 is now known as mgagne | 14:13 | |
| *** mgagne has joined #openstack-keystone | 14:13 | |
| *** krykowski_ has quit IRC | 14:14 | |
| *** richm has joined #openstack-keystone | 14:14 | |
| *** henrynash has quit IRC | 14:15 | |
| openstackgerrit | Hugo Nicodemos proposed openstack/keystone: Add tests to get subprojects of the parent_id https://review.openstack.org/158314 | 14:15 |
| *** nkinder has quit IRC | 14:26 | |
| *** stevemar has joined #openstack-keystone | 14:33 | |
| *** ChanServ sets mode: +v stevemar | 14:33 | |
| *** ajayaa has quit IRC | 14:37 | |
| *** rushiagr is now known as rushiagr_away | 14:42 | |
| openstackgerrit | Marco Fargetta proposed openstack/keystone: IdP ID registration and validation https://review.openstack.org/152156 | 14:45 |
| marekd | fmarco76: ^^ thanks for the patch. | 14:45 |
| *** henrynash has joined #openstack-keystone | 14:50 | |
| *** ChanServ sets mode: +v henrynash | 14:50 | |
| *** jsavak has joined #openstack-keystone | 15:00 | |
| openstackgerrit | Marek Denis proposed openstack/keystone: Ehncance user identification in mapping engine https://review.openstack.org/154934 | 15:00 |
| *** joesavak has quit IRC | 15:03 | |
| *** mzbik has quit IRC | 15:11 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 15:16 | |
| *** nkinder has joined #openstack-keystone | 15:17 | |
| *** rushiagr_away is now known as rushiagr | 15:18 | |
| *** ajayaa has joined #openstack-keystone | 15:20 | |
| marekd | stevemar: henrynash: what's the final decision actually, are we dropping 'extra' column from backends? | 15:28 |
| henrynash | marekd: no | 15:28 |
| stevemar | henrynash, i thought we were? | 15:29 |
| henrynash | marekd: but we agreed on bp that allows a deployer to set a config value which will prevent peopel storing data there | 15:29 |
| henrynash | marekd: but it is still supported by default | 15:29 |
| *** Ephur has joined #openstack-keystone | 15:31 | |
| ayoung | https://www.openstack.org/vote-vancouver/presentation/dynamic-policy-for-access-control | 15:33 |
| lbragstad | stevemar: thanks for the review. I'll be pushing a revision up soon! | 15:34 |
| marekd | henrynash: stevemar: and 'extra' attributed is stored as BLOB in DB? | 15:34 |
| henrynash | marekd: yes, JsonBlob | 15:34 |
| stevemar | ayoung, +3! | 15:34 |
| ayoung | w00t~! | 15:34 |
| marekd | henrynash: JsonBlob is a Text | 15:34 |
| henrynash | marekd: I believe so | 15:35 |
| *** carlosmarin has joined #openstack-keystone | 15:35 | |
| *** ajayaa has quit IRC | 15:35 | |
| *** zigo_ has joined #openstack-keystone | 15:36 | |
| *** radez_g0n3 is now known as radez | 15:38 | |
| *** mattfarina has joined #openstack-keystone | 15:41 | |
| stevemar | henrynash, you mean you're *not* at interconnect? | 15:42 |
| henrynash | stevemar: no, sir! | 15:42 |
| stevemar | henrynash, i will have little luck finding people this week | 15:43 |
| stevemar | henrynash, whats the point of the sql bits here: https://review.openstack.org/#/c/147612/14/keystone/tests/unit/test_backend_ldap.py | 15:43 |
| henrynash | stevemar: so true | 15:43 |
| *** radez is now known as radez_g0n3 | 15:43 | |
| henrynash | stevemar: 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 |
| henrynash | steevmar: want to get all the domain-config stuff up to day, first | 15:44 |
| stevemar | henrynash, can you take of that in another patch (the comments i mean) | 15:44 |
| stevemar | i think the filtering patch is good and want to push it through | 15:45 |
| henrynash | stevemar: sure, happy to do that…I’ll add a coment to that effect | 15:45 |
| stevemar | though there could be a few more tests :) | 15:45 |
| stevemar | currently just 'startsWith' is exercised | 15:46 |
| *** aix has quit IRC | 15:47 | |
| henrynash | stevemar: that’s true….although the same could be said for the sql filtering….probably need an improvement all round | 15:47 |
| henrynash | stevemar: I’ll raise a defect about that in general | 15:48 |
| stevemar | cool cool | 15:48 |
| marekd | stevemar: henrynash: regarding https://bugs.launchpad.net/keystone/+bug/1405726 is it possible that db2 driver is broken ? | 15:50 |
| openstack | Launchpad bug 1405726 in Keystone "getting scoped federation token fails when using db2" [Undecided,New] | 15:50 |
| marekd | looks like only db2 fails on that | 15:51 |
| stevemar | marekd, i did some research on that, apparently Db2 fails in general when DISTINCT is used in conjunction with certain string types | 15:51 |
| marekd | stevemar: and Keystone must support DB2 | 15:51 |
| marekd | (?) | 15:51 |
| stevemar | marekd, preferably, but it's not written that we do | 15:52 |
| marekd | so i wonder how is it possible that it fails here and not in 8 other places where distinct was used...? | 15:52 |
| stevemar | marekd, where else is it used? | 15:53 |
| marekd | stevemar: http://pasteraw.com/10fhbp8p79vxdaateer97ud2ppwnbf4 | 15:54 |
| stevemar | marekd, well endpoint policy isn't being exercised | 15:54 |
| marekd | :( | 15:55 |
| stevemar | and the other bits in assignment backend seem federation related | 15:55 |
| marekd | ugh | 15:55 |
| *** rushiagr is now known as rushiagr_away | 15:55 | |
| marekd | list_user_ids_for_projects ... i think this not federation related. | 15:56 |
| stevemar | list_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_project | 15:56 |
| stevemar | that one isn't | 15:56 |
| stevemar | marekd, but list_user_ids_for_project actually uses a parameter (distinct('actor_id')) | 15:56 |
| stevemar | i wonder if that's the issue | 15:56 |
| marekd | i dont like sorting in memory if the db should be doing that for me. | 15:56 |
| marekd | i don't feel like removing 'distinct' option. | 15:59 |
| marekd | stevemar: what did he mean by saying "Cast the json blob to VARCHAR?" Where he wants to do this? | 15:59 |
| stevemar | marekd, i'm not sure what that means | 16:00 |
| marekd | stevemar: i will comment on the bug. | 16:01 |
| *** ChanServ sets mode: +o dolphm | 16:02 | |
| ayoung | htruta, raildo, https://review.openstack.org/#/c/116081/9/keystoneclient/tests/unit/v3/test_roles.py,cm is 'tail' and actuiall kwarg, or is it a norm you are using for arg passing inside the client only? | 16:04 |
| openstackgerrit | Merged openstack/keystone: Check consumer and project id before creating request token https://review.openstack.org/145701 | 16:05 |
| *** fmarco76 has left #openstack-keystone | 16:07 | |
| *** fmarco76 has joined #openstack-keystone | 16:09 | |
| *** jorge1 has joined #openstack-keystone | 16:09 | |
| *** fmarco76 has left #openstack-keystone | 16:10 | |
| marekd | lbragstad: https://review.openstack.org/#/c/157890/3/keystone/common/config.py,cm when using choices, available options are somehow presented to the user? | 16:17 |
| marekd | lbragstad: otherwise, maybe it's better to help as it used to be, and treat choices as a first pass of input validation? | 16:17 |
| lbragstad | marekd: 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 |
| lbragstad | marekd: but it does do input validation, | 16:18 |
| marekd | lbragstad: so what happens if i put wrong options? | 16:18 |
| lbragstad | marekd: bknudson just suggested that the help text should be removed if we're using choices. | 16:18 |
| lbragstad | marekd: it should blow up | 16:19 |
| marekd | fails, and some template "Wrong option provided. Available options: %s" % choices is returned? | 16:19 |
| marekd | if the user doesnt see available options we should keep it in help | 16:19 |
| bknudson | the help text from oslo.config should include the choices... otherwise I think that's a bug in oslo.config | 16:19 |
| marekd | bknudson: ok | 16:20 |
| htruta | ayoung: it is a norm | 16:21 |
| *** devlaps has joined #openstack-keystone | 16:21 | |
| *** rushiagr_away is now known as rushiagr | 16:21 | |
| ayoung | htruta, posted my response on the review. go with the underscore "norm" from python as a cleaner approach. | 16:22 |
| *** Tahmina has joined #openstack-keystone | 16:23 | |
| htruta | ayoung: cool. the tail was a suggestion by wanghong in the patch 6 or 7 | 16:24 |
| htruta | I'll make it as you suggested | 16:24 |
| ayoung | yeah...and not a horrible one. | 16:24 |
| ayoung | Just, naming is hard, and we need to make sure things are self documenting. | 16:24 |
| lbragstad | morganfainberg: didn't you have a suggestion related to stevemar's comments here: https://review.openstack.org/#/c/145317/20/keystone/token/provider.py about how we can determine if token persistence is being used? | 16:29 |
| *** Tahmina has quit IRC | 16:29 | |
| lbragstad | morganfainberg: I tried throwing it in the __init__() but hit import/config related issues | 16:30 |
| htruta | ayoung: got it | 16:33 |
| bknudson | we could have a dummy persistence provider. | 16:33 |
| bknudson | that doesn't actually persist anything. | 16:33 |
| htruta | ayoung: so, you suggest having a '_inherited_to_projects' kwarg? | 16:33 |
| *** Tahmina has joined #openstack-keystone | 16:34 | |
| ayoung | htruta, 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 here | 16:35 |
| ayoung | the _ 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 |
| htruta | ayoung: yes. | 16:36 |
| htruta | I'm okay with tha | 16:36 |
| htruta | I wonder what bknudson would say about it | 16:37 |
| bknudson | htruta: about what? | 16:37 |
| *** ajayaa has joined #openstack-keystone | 16:38 | |
| htruta | about the idea to change the kwarg 'tail' to something like '_inherited_to_projects' in here: https://review.openstack.org/#/c/116081/9/keystoneclient/base.py | 16:39 |
| htruta | bknudson: ^ | 16:39 |
| morganfainberg | lbragstad: yeah I had a | 16:40 |
| morganfainberg | Paste explaining the diff | 16:40 |
| lbragstad | morganfainberg: can I build it in the _persistence Property method? | 16:40 |
| morganfainberg | lbragstad: let me show you if I can find it. | 16:40 |
| morganfainberg | lbragstad: I just made an @property on the driver that returned true/false | 16:41 |
| lbragstad | morganfainberg: gotcha, | 16:41 |
| openstackgerrit | Henrique Truta proposed openstack/python-keystoneclient: Creating parameter to list inherited role assignments https://review.openstack.org/117300 | 16:41 |
| lbragstad | morganfainberg: doing something similar since we have the _persistence property method already | 16:41 |
| morganfainberg | Then instead of checking if driver str == klwt, self.driver.needs_persistence | 16:41 |
| morganfainberg | Or some such. | 16:41 |
| morganfainberg | Sure | 16:41 |
| lbragstad | ok | 16:41 |
| lbragstad | not sure what i have is going to work, but I'll play with it | 16:42 |
| *** devlaps has quit IRC | 16:42 | |
| morganfainberg | I also ran into a byte_str bug when running a devstack with the POC code | 16:42 |
| bknudson | htruta: build_url should be somewhat generic, so using something generic like "tail" makes more sense than something specific like '_inherited_to_projects' | 16:43 |
| morganfainberg | Fernet was un happy. | 16:43 |
| morganfainberg | And it raised an exception. | 16:43 |
| morganfainberg | lbragstad: on validate I think. When using horizon. I can reproduce the exception easily. | 16:44 |
| lbragstad | ok | 16:45 |
| morganfainberg | lbragstad: the v2 token stuff should be less work once we have v3 working correctly. I think you're pretty close tbh. | 16:45 |
| htruta | bknudson: so, are you ok with tail? or do you have any suggestion? | 16:45 |
| htruta | ayoung: ^ | 16:45 |
| lbragstad | morganfainberg: yeah, I plan to tackle that soon | 16:45 |
| morganfainberg | lbragstad: figured :) | 16:45 |
| ayoung | htruta, I prefer '_inherited_to_projects' | 16:45 |
| bknudson | htruta: I'm ok with tail... it's not the most descriptive. Would be nice if it was [] rather than string. | 16:45 |
| ayoung | but ifwe do 'tai'l for a function..it shoud be an explicit parameter | 16:46 |
| ayoung | I concur with bknudson that the more generic term should be used for a general purpose utility | 16:46 |
| morganfainberg | lbragstad: 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 |
| ayoung | tail implies it is the last item...is that what you mean htruta ? | 16:47 |
| morganfainberg | lbragstad: I can prob help with that front once we're closer. | 16:47 |
| lbragstad | morganfainberg: makes sense, that would be good | 16:47 |
| ayoung | morganfainberg, 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-keystone | 16:48 | |
| ayoung | I think we might be painting ourselves into a corner with "we know who signed these" implicit in the implementation | 16:48 |
| morganfainberg | ayoung: the nice thing is that enhancement should be stupidly easy to add once the base code is there :) | 16:48 |
| ayoung | I'm not going to hold things up...but | 16:48 |
| ayoung | that is my hope, yes | 16:48 |
| ayoung | morganfainberg, BTW, my guess is the 255 char limit is really an artifact of memcache design that makes 250 bytes the key size | 16:49 |
| morganfainberg | ayoung: 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 |
| ayoung | I think (deduced from what I've read) that memcache will use a 255 length string as is, but will Hash a longer one | 16:50 |
| morganfainberg | ayoung: nah 255 is about where people get complaining about extra overhead. But less than 500 is pretty damn good. | 16:50 |
| htruta | ayoung: yes. tail was meant to be the last item only | 16:50 |
| ayoung | morganfainberg, I think we will get someone looking at the data. BUt we can break them | 16:50 |
| morganfainberg | ayoung: 1k is where people *really* start complaining. | 16:51 |
| ayoung | htruta, something is wonky with that convention...I'' remove the -1 though | 16:51 |
| morganfainberg | ayoung: 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 |
| htruta | ayoung: cool. thanks | 16:53 |
| morganfainberg | lbragstad: so yeah. Totally on board with your direction. Looks like some | 16:54 |
| morganfainberg | Minor massaging to clean things up. | 16:54 |
| morganfainberg | lbragstad: and fernet looks like a good option over keyczar. | 16:55 |
| *** gyee has joined #openstack-keystone | 16:55 | |
| *** ChanServ sets mode: +v gyee | 16:55 | |
| morganfainberg | dolphm: ^^ (new token stuff). | 16:55 |
| dolphm | morganfainberg: cool | 16:56 |
| morganfainberg | lbragstad, dolphm: http://paste.openstack.org/show/180655/ | 16:59 |
| lbragstad | morganfainberg: the fernet stuff was all dolphm, I think that will work well. Just need to figure out the signing stuff with it. | 17:00 |
| morganfainberg | that error ^^ was using the latest patch w/ dolph's fernet thing and setting horizon to use v3 then trying to login via horizon | 17:01 |
| dolphm | lbragstad: ^^ 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 other | 17:01 |
| morganfainberg | i didn't have time to dig in further yet | 17:01 |
| dolphm | morganfainberg: oh yeah, i saw you paste that backtrace on friday | 17:01 |
| morganfainberg | but this is my setup to make sure we get some real coverage going here | 17:02 |
| morganfainberg | since this touches something we haven't really mucked with too much in what ~4 cycles? | 17:02 |
| *** rwsu has joined #openstack-keystone | 17:05 | |
| ayoung | morganfainberg, dolphm lbragstad had a conversation with our team. Interesting suggestion came up over key management | 17:09 |
| ayoung | morganfainberg, dolphm lbragstad we already use python-keyring. | 17:10 |
| dolphm | in the client | 17:10 |
| ayoung | Use that as the managment interface, and then we can use all the things it abstracts as key stores | 17:10 |
| ayoung | to include the kernel keyring | 17:10 |
| ayoung | dolphm, yeah, we don't have it as a server dependency | 17:10 |
| ayoung | but it splits the management off from python-crypto into appropriate layers | 17:11 |
| ayoung | sound about right? | 17:11 |
| dolphm | ayoung: sounds like good intermediate step before supporting barbican | 17:14 |
| ayoung | dolphm, You really think it should go in Barbican? | 17:15 |
| dolphm | ayoung: i'd like keys to be outside of keystone's responsibility | 17:15 |
| ayoung | I thought they were trying to not be the keys store for undercloud things, just for end user things, | 17:15 |
| ayoung | Ah... | 17:15 |
| lbragstad | fwiw, 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 more | 17:16 |
| *** csoukup has joined #openstack-keystone | 17:16 | |
| ayoung | So.. 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 stuff | 17:17 |
| ayoung | I would think that a Keystone server could keep the Key in memory, and if the server crashes...oh well. | 17:17 |
| ayoung | We 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-keystone | 17:18 | |
| ayoung | Now, for the "many keystones sharing a key" deployements, it would mean using Kite or comparable, but that still is not escrowed | 17:18 |
| *** thedodd has joined #openstack-keystone | 17:21 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/145317 | 17:21 |
| lbragstad | jorge_munoz: thanks for the review, comments addressed ^ | 17:24 |
| samueldmq | hi guys .... I just found a bug on our driver_hints | 17:26 |
| samueldmq | bug #1424745 | 17:26 |
| openstack | bug 1424745 in Keystone "SQL is not able to honor multiple filters in driver_hints.Hints()" [Undecided,New] https://launchpad.net/bugs/1424745 - Assigned to Samuel de Medeiros Queiroz (samueldmq) | 17:26 |
| samueldmq | morganfainberg, henrynash ^ | 17:26 |
| *** jistr has quit IRC | 17:29 | |
| *** radez_g0n3 is now known as radez | 17:30 | |
| *** himangi has quit IRC | 17:31 | |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone: Change project name constraint https://review.openstack.org/158372 | 17:36 |
| *** tqtran has joined #openstack-keystone | 17:41 | |
| *** david8hu has joined #openstack-keystone | 17:43 | |
| *** spandhe has joined #openstack-keystone | 17:44 | |
| *** lhcheng has joined #openstack-keystone | 17:50 | |
| *** lhcheng has quit IRC | 17:50 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Add is_domain field in Project Table https://review.openstack.org/157427 | 17:50 |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone: Change project name constraint https://review.openstack.org/158372 | 17:50 |
| *** afazekas_ has quit IRC | 18:07 | |
| *** david-lyle_afk is now known as david-lyle | 18:09 | |
| openstackgerrit | henry-nash proposed openstack/keystone: Implement backend driver support for domain config https://review.openstack.org/158051 | 18:09 |
| *** _cjones_ has quit IRC | 18:10 | |
| openstackgerrit | David J Hu proposed openstack/keystone: Version independent token issuance pipeline https://review.openstack.org/150629 | 18:14 |
| *** _cjones_ has joined #openstack-keystone | 18:15 | |
| *** carlosmarin has quit IRC | 18:19 | |
| *** pnavarro has quit IRC | 18:20 | |
| *** rushiagr is now known as rushiagr_away | 18:27 | |
| morganfainberg | ayoung, all stuff we can discuss for managing the keys | 18:27 |
| *** lhcheng has joined #openstack-keystone | 18:27 | |
| morganfainberg | ayoung, 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 important | 18:28 |
| *** harlowja has joined #openstack-keystone | 18:33 | |
| ayoung | morganfainberg, 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 |
| morganfainberg | ayoung, yes. | 18:36 |
| ayoung | So...I wonder if Kite/Keyring is a possibility | 18:36 |
| ayoung | Not that I really want to code it | 18:36 |
| morganfainberg | ayoung, probably. | 18:36 |
| morganfainberg | ayoung, i mean, no reason it can't be | 18:36 |
| ayoung | We Coo | 18:46 |
| openstackgerrit | Telles Mota Vidal Nóbrega proposed openstack/keystone: List projects filtering by is_domain flag https://review.openstack.org/158398 | 18:46 |
| ayoung | Damn...I shall never attempt to mimic that again. | 18:46 |
| openstackgerrit | Telles Mota Vidal Nóbrega proposed openstack/keystone: List projects filtering by is_domain flag https://review.openstack.org/158398 | 18:49 |
| *** jaosorior has quit IRC | 18:51 | |
| *** Tahmina has quit IRC | 18:53 | |
| morganfainberg | ayoung, yeah don't mimic that again ;) | 18:57 |
| ayoung | Concur | 18:57 |
| * morganfainberg looks at gearman more | 18:59 | |
| morganfainberg | gearman is so much better than rabbit... | 18:59 |
| morganfainberg | it's like something designed for RPC (all personal opinion) | 18:59 |
| *** amerine_ has quit IRC | 19:01 | |
| morganfainberg | dolphm, ayoung, bknudson, gyee, henrynash, dstanek, marekd, stevemar, topol, jamielennox, ping: please review https://review.openstack.org/#/c/148730/ and the following patch today if you could. | 19:07 |
| dstanek | morganfainberg: shore | 19:08 |
| morganfainberg | erm, presceeding | 19:08 |
| morganfainberg | not following | 19:08 |
| morganfainberg | :P | 19:08 |
| ayoung | morganfainberg, All I saw was "policy" and I was like...yeah | 19:09 |
| morganfainberg | huh? | 19:09 |
| ayoung | the recrusive patch... | 19:10 |
| morganfainberg | ayoung, oh yeah | 19:10 |
| ayoung | Both actions would require new rules in the policy.json file along with new API endpoints to control/represent them. | 19:10 |
| ayoung | We 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 somewierdthing | 19:11 |
| *** ajayaa has quit IRC | 19:11 | |
| morganfainberg | bknudson, re: https://review.openstack.org/#/c/156509/1/api/v3/identity-api-v3.rst 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 it | 19:13 |
| morganfainberg | into endpoints | 19:13 |
| morganfainberg | bknudson, 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 |
| bknudson | morganfainberg: not being in regions is a good reason to not have the endpoints in the normal catalog | 19:16 |
| morganfainberg | bknudson, 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 |
| ayoung | This conversation happend over a year ago. Federation was originally going to list IdPs in the service catalog. | 19:17 |
| morganfainberg | i'm ok if we make the SP list more generic so you can list things like say CloudFoundry there. | 19:17 |
| bknudson | morganfainberg: most users of the token aren't going to care about the SPs, though, are they? | 19:17 |
| morganfainberg | bknudson, i would guess it could be a lot of users will and a lot wont | 19:17 |
| morganfainberg | bknudson, 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 |
| bknudson | also, it's always going to be the same, right? | 19:18 |
| morganfainberg | or are you spreading around load across different SP clouds? | 19:18 |
| morganfainberg | or is it just burst | 19:18 |
| morganfainberg | it 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 SP | 19:19 |
| rodrigods | ayoung, yeah... called "rule" the policy portion of the new API endpoint (recursive patch) | 19:19 |
| morganfainberg | bknudson, because the SAML is based upon your local information, not just that you can "auth" with your local cloud. | 19:19 |
| ayoung | rodrigods, 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 |
| bknudson | I need a scoped token to get the service providers? | 19:21 |
| morganfainberg | yes. | 19:21 |
| morganfainberg | because 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 that | 19:22 |
| openstackgerrit | Merged openstack/keystone: Enable filtering in LDAP backend for listing entities https://review.openstack.org/147612 | 19:22 |
| rodrigods | ayoung, it is being called target in the policy lib: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L23 | 19:22 |
| bknudson | the catalog doesn't limit access... it's security through obscurity | 19:22 |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 19:23 |
| morganfainberg | bknudson, no keystone will not issue SAML for the SP unless it's in the catalog | 19:23 |
| rodrigods | ayoung, anyway... do you think this name is a blocker in the spec? | 19:23 |
| morganfainberg | bknudson, therefore it is actually enforced, not security through security | 19:23 |
| ayoung | Nope | 19:23 |
| morganfainberg | bknudson, or that is the intention | 19:23 |
| ayoung | rodrigods, it just ghot me thinking about policy... | 19:23 |
| morganfainberg | bknudson, s/security$/obscurity | 19:23 |
| morganfainberg | bknudson, and the SAML must be targeted to the SP, it's not *any* SAML that a keystone issues will work with the SP | 19:25 |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Fixes test_multiple_filters filters definition https://review.openstack.org/158411 | 19:26 |
| bknudson | ok... maybe I | 19:26 |
| bknudson | maybe I'm just not a fan of adding another element to the "catalog" array? | 19:27 |
| bknudson | I wouldn't be surprised if users were expecting a "catalog" entry to have "endpoints", "type", etc. | 19:27 |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Exposes bug in SQL when honoring driver_hints https://review.openstack.org/158412 | 19:27 |
| bknudson | I guess I don't see why { "service_providers": []} is better than { "endpoints": [], "type": "service_providers" } | 19:28 |
| bknudson | does the current keystoneclient code even work with a catalog like this? | 19:29 |
| lbragstad | yes | 19:31 |
| lbragstad | s/yes// | 19:31 |
| lbragstad | wrong window | 19:31 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Keystone Lightweight Tokens (KLWT) https://review.openstack.org/145317 | 19:31 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Use revocation events for lightweight tokens https://review.openstack.org/158414 | 19:31 |
| bknudson | looks like keystoneclient requires ['type'] in the service catalog: http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/service_catalog.py#n108 | 19:32 |
| morganfainberg | Ksc 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 |
| bknudson | ksc doesn't ignore it. | 19:35 |
| bknudson | oh, it's got a catch for keyerror | 19:36 |
| morganfainberg | Yep. | 19:36 |
| *** pnavarro has joined #openstack-keystone | 19:37 | |
| bknudson | seems like if we used { "endpoints": [], "type": "service_providers" } then the client would just work. | 19:38 |
| *** pdesai has joined #openstack-keystone | 19:39 | |
| morganfainberg | My 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 |
| morganfainberg | Which is why I thought the sp list being explicitly different was good. | 19:41 |
| stevemar | bknudson, aren't we just bastardizing endpoints instead of services at that point | 19:42 |
| dolphm | morganfainberg: ++ | 19:42 |
| bknudson | I thought we were hoping to get rid of the "public" / "internal" / "admin" endpoints anyways. | 19:43 |
| bknudson | endpoints are a bastard already | 19:43 |
| bknudson | and 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 |
| dolphm | bknudson: i'd like to get rid of "admin" -- public / internal have clear uses | 19:44 |
| morganfainberg | dolphm: ++ | 19:45 |
| bknudson | publishing internal endpoints externally is not useful. | 19:45 |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Enhance user identification in mapping engine https://review.openstack.org/154934 | 19:46 |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Make Rule.Processor_UserType class public https://review.openstack.org/157711 | 19:46 |
| bknudson | how about move the "service_providers" out of the "catalog" ? | 19:46 |
| morganfainberg | bknudson: where to? Something that requires another api call to check if you can use them? | 19:47 |
| morganfainberg | This feels like catalog type data | 19:47 |
| bknudson | I guess that doesn't fit the general model. | 19:47 |
| morganfainberg | But it doesn't conform to service/endpoint data models. | 19:47 |
| dolphm | i don't think a centralized catalog should be trying to determine if the client can reach a specific network or not | 19:48 |
| *** openstackgerrit has quit IRC | 19:51 | |
| *** openstackgerrit has joined #openstack-keystone | 19:52 | |
| morganfainberg | jamielennox: 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 |
| morganfainberg | Or sessions | 19:53 |
| *** browne has joined #openstack-keystone | 19:56 | |
| morganfainberg | ayoung: you know i misread your topic as "Adam can do everything..." ;) | 20:00 |
| *** pdesai1 has joined #openstack-keystone | 20:01 | |
| *** pdesai has quit IRC | 20:03 | |
| *** gabriel-bezerra has joined #openstack-keystone | 20:04 | |
| *** rm_work|away is now known as rm_work | 20:07 | |
| *** stevemar has quit IRC | 20:07 | |
| *** markvoelker has joined #openstack-keystone | 20:07 | |
| *** drjones has joined #openstack-keystone | 20:10 | |
| *** c_soukup has joined #openstack-keystone | 20:10 | |
| *** _cjones_ has quit IRC | 20:10 | |
| *** csoukup has quit IRC | 20:11 | |
| *** c_soukup has quit IRC | 20:14 | |
| lhcheng | dolphm: 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 IRC | 20:17 | |
| lhcheng | dolphm: it is an old code, thought you might have insight on it. | 20:17 |
| dolphm | lhcheng: 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 |
| lhcheng | dolphm: here is the related code: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L60 | 20:18 |
| dolphm | lhcheng: so it shouldn't override anything but __init__() | 20:19 |
| lhcheng | dolphm: 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 |
| lhcheng | dolphm: yeah.. that might be the right way to go, while keeping the test working. | 20:20 |
| lhcheng | dolphm: don't we need to override the get_catalog() too: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/kvs.py#L24 | 20:21 |
| lhcheng | dolphm: it relies that there is a service catalog stored for each project/user combination | 20:22 |
| dolphm | lhcheng: the "hybrid" behavior? | 20:22 |
| *** csoukup has joined #openstack-keystone | 20:22 | |
| lhcheng | dolphm: the templated catalog driver having 1.) get_catalog() reading from template file 2) kvs behavior for the crud operations | 20:23 |
| dolphm | morganfainberg: can we just kill the kvs & templated catalog drivers as "broken and unmaintained" | 20:23 |
| dolphm | lhcheng: why do you have an interest in fixing it? | 20:23 |
| dolphm | it almost looks like the templated version of get_catalog would work better than the kvs version | 20:25 |
| lhcheng | dolphm: we're actually not using it, just picking up outstanding bugs in keystone. | 20:25 |
| dolphm | if the kvs version works at all | 20:25 |
| dolphm | lhcheng: i'd propose to fix it by deleting it, because clearly no one has supported it | 20:26 |
| lhcheng | dolphm: maybe I should just put the bug back :) https://bugs.launchpad.net/keystone/+bug/1156298 | 20:26 |
| openstack | Launchpad 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 |
| lhcheng | dolphm: hmm true | 20:26 |
| lhcheng | dolphm: mark this as deprecated for now then? | 20:27 |
| dolphm | lhcheng: i'm surprised it's not already deprecated | 20:27 |
| dolphm | lhcheng: is it even useable? if not, deletion makes more sense than a deprecation cycle | 20:28 |
| dolphm | lhcheng: i'd also be curious what impact deleting it would have on our tests | 20:28 |
| lhcheng | dolphm: the get_catalog() do work | 20:28 |
| lhcheng | dolphm: tried setting it up, typical operations works on KSC like crud on user/project | 20:29 |
| dolphm | lhcheng: does the kvs one work in the real world? | 20:29 |
| *** stevemar has joined #openstack-keystone | 20:30 | |
| *** ChanServ sets mode: +v stevemar | 20:30 | |
| lhcheng | dolphm: 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 |
| lhcheng | dolphm: no idea if the kvs work in the real world :) | 20:31 |
| dolphm | lhcheng: that's probably the reason the backend still exists! | 20:31 |
| dstanek | lhcheng: dolphm: i have code that fixes the templated catalog; and deletes kvs | 20:31 |
| dolphm | dstanek: what does it take to fix templated? | 20:31 |
| lhcheng | dolphm: heh no one wants to fix the test. | 20:32 |
| lhcheng | dstanek: nice! | 20:32 |
| dolphm | lhcheng: except dstanek | 20:32 |
| dstanek | dolphm: it doesn't seem too terrible; i'm cleaning commits to push now actually | 20:33 |
| lhcheng | dstanek: \o/ | 20:33 |
| dstanek | it seems that we actually have tests for the templated catalog that really shouldn't exist | 20:33 |
| *** harlowja has quit IRC | 20:34 | |
| *** harlowja_ has joined #openstack-keystone | 20:34 | |
| lhcheng | dstanek: yeah, a lot. it is inheriting the catalog crud tests | 20:34 |
| stevemar | morganfainberg, so bknudson seems very anti-thread.local() - should i continue to look into it? | 20:37 |
| stevemar | bknudson, how serious were your comments about it | 20:37 |
| morganfainberg | stevemar, and he should be. | 20:37 |
| openstackgerrit | David Stanek proposed openstack/keystone: Uses SQL catalog driver for v2 REST tests https://review.openstack.org/158438 | 20:38 |
| dstanek | stevemar: i hate thread local too! | 20:38 |
| dstanek | lhcheng: see that commit ^ | 20:39 |
| bknudson | stevemar: serious. | 20:39 |
| lhcheng | dstanek: yeah, I saw that issue too while trying to fix the catalog test. | 20:40 |
| lhcheng | dstanek: so templated catalog, should really support write? as in writing back to file or in-memory? | 20:41 |
| dstanek | lhcheng: i also have a patch coming that separates kvs from templated | 20:41 |
| dstanek | lhcheng: it supports write (almost) right now | 20:41 |
| lhcheng | dstanek: I should asked you first, I was looking at these over the weekend :P | 20:41 |
| dstanek | that's the issue; you can create_* and get them back with the list operations, but never in the get_catalog | 20:42 |
| lhcheng | dstanek: yeah, the get_catalog() in kvs is just broken | 20:43 |
| *** jogo has joined #openstack-keystone | 20:45 | |
| morganfainberg | rodrigods, raildo, samueldmq, ping: re reseller spec | 20:45 |
| lhcheng | dstanek: 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 |
| raildo | morganfainberg, hi :) | 20:45 |
| morganfainberg | rodrigods, 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 you | 20:45 |
| dstanek | lhcheng: i didn't realize that there are multiple bugs for this | 20:45 |
| morganfainberg | re given the ability to +2 it, (so you +2, and a keystone core +2 to merge it). | 20:46 |
| gyee | morganfainberg, just commented on https://review.openstack.org/#/c/148730/ | 20:46 |
| morganfainberg | once the feature is done (reseller in this case) we can merge the whole branch to master. This is totally optional | 20:46 |
| morganfainberg | raildo, rodrigods, samueldmq, and the final merge to master requires more core-reviewer eyes. | 20:47 |
| *** jorge1 has left #openstack-keystone | 20:47 | |
| openstackgerrit | Telles Mota Vidal Nóbrega proposed openstack/keystone: List projects filtering by is_domain flag https://review.openstack.org/158398 | 20:47 |
| morganfainberg | but i'll let jogo explain a little more in detail. | 20:47 |
| morganfainberg | i *think* the reseller work is a good candidate for this. | 20:47 |
| morganfainberg | gyee, thanks. | 20:47 |
| raildo | morganfainberg, something similar what we did with HMT in the past? | 20:48 |
| samueldmq | morganfainberg, would this late the reseller code merge? | 20:48 |
| morganfainberg | samueldmq, it would not change the target of k3 | 20:48 |
| morganfainberg | samueldmq, if it doesn't land in k3, we're past freeze for it anyway. | 20:49 |
| morganfainberg | this *may* be too late to try with reseller, jogo - but we can see. | 20:49 |
| morganfainberg | raildo, it's a little different. | 20:49 |
| gyee | morganfainberg, 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 -1 | 20:49 |
| *** csoukup has quit IRC | 20:49 | |
| jogo | morganfainberg raildo samueldmq: not exactly the same | 20:50 |
| morganfainberg | gyee, 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 |
| lhcheng | dstanek: yeah, you want to just pickup those bug so you can keep track all templated catalog related bugs? https://bugs.launchpad.net/keystone/+bug/1156298, https://bugs.launchpad.net/keystone/+bug/1424373 | 20:50 |
| openstack | Launchpad 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 |
| openstack | Launchpad bug 1424373 in Keystone "Service CRUD is allowed in templated catalog" [Wishlist,New] - Assigned to Lin Hua Cheng (lin-hua-cheng) | 20:50 |
| jogo | one difference is people who are not general keystone-cores can get +2 power on the feature branch | 20:51 |
| samueldmq | jogo, what would be the advantage of this? | 20:51 |
| morganfainberg | gyee, 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 IRC | 20:51 | |
| jogo | Create new branch with different ‘core’ team. This can only be done by core (sponsor). | 20:52 |
| gyee | morganfainberg, it'll work either way, its more of a question of consistency | 20:52 |
| jogo | new 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 |
| jogo | main core team evaluates feature at end, and merges it into master | 20:52 |
| jogo | require core(s?) besides branch sponsor to review it. | 20:52 |
| jogo | review at end *should* not be as detailed as a per patch review. design review vs. code review. | 20:52 |
| jogo | delete feature branch | 20:52 |
| jogo | disadvantages | 20:52 |
| jogo | uniform code quality issue? | 20:52 |
| jogo | cannot distribute separately | 20:52 |
| jogo | my notes on the topic: ^ | 20:52 |
| jogo | samueldmq: to make it easier to land the feature, by empowering people who are working on the feature to get +2 power over there branch | 20:53 |
| jogo | so instead of requiring two keystone cores to review each patch, you would just need two feature branch cores to review each patch. | 20:54 |
| jogo | which should be easier to do | 20:54 |
| morganfainberg | also 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 |
| samueldmq | jogo, and keystone cores to only approve it to get merged on master at the end, right? | 20:54 |
| jogo | samueldmq: 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 |
| raildo | jogo, morganfainberg I like the idea, but who will participate in this new 'core' team? | 20:55 |
| raildo | someone for nova-core? | 20:55 |
| gyee | what are we taling about? | 20:55 |
| gyee | raildo, "new core team"? | 20:56 |
| raildo | ayoung, henrynash, gyee ? | 20:56 |
| gyee | which project? | 20:56 |
| jogo | raildo: the keystone core sponsor can decide who gets feature branch core. most likely the people who are interested in the feature | 20:56 |
| raildo | jogo, great. | 20:56 |
| samueldmq | jogo, ++ | 20:56 |
| * gyee is seeing fogs | 20:56 | |
| samueldmq | gyee, yep .. see a few messages back from jogo .. | 20:56 |
| raildo | gyee, a feature branch to reseller, with a "new core team" | 20:56 |
| jogo | gyee: talking about short lived feature branches with there own 'feature-branch core team' | 20:57 |
| morganfainberg | raildo, 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 branch | 20:57 |
| raildo | morganfainberg, i get it. | 20:57 |
| jogo | morganfainberg: exactly | 20:57 |
| raildo | morganfainberg, 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 |
| morganfainberg | raildo, of course. and like i said it might be too close to k3 to really try this | 20:58 |
| morganfainberg | but next cycle we might jump on this for a bp. | 20:58 |
| morganfainberg | if this doesn't work | 20:58 |
| morganfainberg | jogo, lets circle up @ keystone meeting tomorrow to confirm | 20:59 |
| morganfainberg | jogo, that way if there are any other concerns we can address them there as well. | 20:59 |
| gyee | raildo, jogo, I see. But "big merge" from feature branch to master still require keystone core policy right? | 20:59 |
| morganfainberg | jogo, and/or timing issues. | 20:59 |
| samueldmq | morganfainberg, ++ makes sense ... let's see other cores views... if they have any concern about trying this now | 20:59 |
| samueldmq | gyee, yep | 20:59 |
| raildo | morganfainberg, this will be perfect, we can confirm and define the core team tomorrow in the meeting | 20:59 |
| morganfainberg | gyee, yes. the merge from topic branch -> master requires keystone core (not topic core) | 21:00 |
| jogo | gyee: yes | 21:00 |
| jogo | morganfainberg: sounds great, thanks! | 21:00 |
| lhcheng | morganfainberg: opened a bug in django_openstack_auth to make the parsing of service catalog less error prone: https://bugs.launchpad.net/django-openstack-auth/+bug/1424825 | 21:00 |
| openstack | Launchpad bug 1424825 in django-openstack-auth "Parsing of service catalog should be less error prone" [Undecided,New] | 21:00 |
| morganfainberg | jogo, please add yourself here: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Main_Agenda | 21:01 |
| jogo | thanks everyone! | 21:01 |
| morganfainberg | jogo, :) | 21:01 |
| samueldmq | jogo, np :) | 21:01 |
| morganfainberg | jogo, 1800 UTC and you'll be the first topic. | 21:01 |
| jogo | morganfainberg: should I add the topic as well? or will you | 21:01 |
| morganfainberg | jogo, add the topic there. | 21:01 |
| dstanek | lhcheng: ok | 21:01 |
| jogo | oh I see | 21:01 |
| morganfainberg | anyone can add the topic. | 21:01 |
| dstanek | dolphm: you still around? | 21:02 |
| morganfainberg | jogo, makes it easier for me to let people jump in vs. specifically adding topics. | 21:02 |
| stevemar | bknudson, btw, can you take a looksy at https://review.openstack.org/#/c/153842/ - it's rebased on master now, as you had requested | 21:03 |
| *** nicodemos has quit IRC | 21:03 | |
| openstackgerrit | Steve Martinelli proposed openstack/keystone: Remove incubated version of oslo policy https://review.openstack.org/157158 | 21:04 |
| morganfainberg | stevemar oh we released oslo.policy? score | 21:04 |
| bknudson | oslo.policy isn't released... still needs some changes. | 21:04 |
| stevemar | morganfainberg, it was a quiet release | 21:04 |
| morganfainberg | stevemar, ah. | 21:04 |
| morganfainberg | bknudson, stevemar, ++ | 21:04 |
| stevemar | bknudson, we did actually tag a release, but didn't announce | 21:04 |
| bknudson | ok... dhellmann said that there were some changes needed to oslo.policy? | 21:05 |
| bknudson | based on some comments in a review. | 21:05 |
| *** bknudson has quit IRC | 21:05 | |
| dolphm | dstanek: yes | 21:05 |
| stevemar | bknudson, 2 of the comments were unnecessary, as I was using CONF.blah instead of accessing them from the Enforcer | 21:06 |
| openstackgerrit | David Stanek proposed openstack/keystone: Removes KVS catalog backend https://review.openstack.org/158442 | 21:06 |
| openstackgerrit | David Stanek proposed openstack/keystone: WIP: Support read operations for templated catalogs https://review.openstack.org/158443 | 21:06 |
| stevemar | and the other one was a test fixture request, but I worked around it | 21:06 |
| dstanek | dolphm: untested hack from this morning https://review.openstack.org/158443 | 21:06 |
| dstanek | that's just to support read operations | 21:06 |
| jogo | morganfainberg: and done | 21:07 |
| morganfainberg | jogo, awesome! :) | 21:07 |
| morganfainberg | jogo, 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 time | 21:07 |
| *** raildo is now known as raildo_away | 21:08 | |
| jogo | sounds like a plan | 21:08 |
| dolphm | dstanek: what's with _DictKvs? | 21:09 |
| dstanek | dolphm: i added that to the prior commit - until this morning i didn't think i would be getting rid of it so fast | 21:10 |
| dolphm | dstanek: lol but why did you implement it? | 21:10 |
| dolphm | / why is it necessary | 21:10 |
| dolphm | oh that's from https://review.openstack.org/#/c/158442/1/keystone/common/kvs/legacy.py | 21:11 |
| dstanek | dolphm: it already existed | 21:11 |
| morganfainberg | dolphm, yeah that was already there | 21:11 |
| dstanek | dolphm: yeah, until this morngin i was planning on keeping all of the kvs methods around and just deprecate them | 21:11 |
| dstanek | that was before i took over https://bugs.launchpad.net/keystone/+bug/1289078 | 21:12 |
| openstack | Launchpad 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 IRC | 21:12 | |
| dolphm | dstanek: i like the result of the last 2 changes combined -- any reason not to squash? the intermediate state is less appealing | 21:13 |
| dstanek | dolphm: i wasn't sure if which we would want; deprecate all the things or fixed | 21:14 |
| dstanek | i was going to bring it up in the meeting tomorrow - does backward compatibility matter here... | 21:15 |
| morganfainberg | so.. if we wouldn't break people deploying this with things just "fixed" | 21:15 |
| *** markvoelker has joined #openstack-keystone | 21:15 | |
| morganfainberg | i'd say just fix | 21:15 |
| morganfainberg | if it would break people, deprecate and fix | 21:15 |
| dstanek | so right now all of the templated methods almost work | 21:15 |
| *** markvoelker has quit IRC | 21:15 | |
| dstanek | you can create stuff and get a list of it back | 21:16 |
| *** markvoelker has joined #openstack-keystone | 21:16 | |
| dolphm | !almost! | 21:16 |
| openstack | dolphm: Error: "almost!" is not a valid command. | 21:16 |
| dstanek | but it will never be in the catalog | 21:16 |
| morganfainberg | ahahha | 21:16 |
| morganfainberg | openstack, your so silly | 21:16 |
| dstanek | it could break people, but IMO they are already broken and probably don't know it | 21:16 |
| * morganfainberg waits for the obligatory s/your/you're from the bot or someone else | 21:16 | |
| dolphm | !An invalid command | 21:17 |
| openstack | dolphm: Error: "An" is not a valid command. | 21:17 |
| dolphm | damn | 21:17 |
| dstanek | !a valid command | 21:18 |
| openstack | dstanek: Error: "a" is not a valid command. | 21:18 |
| morganfainberg | !! | 21:18 |
| openstack | morganfainberg: Error: "!" is not a valid command. | 21:18 |
| stevemar | morganfainberg, hey, do you know what the comment here is; https://review.openstack.org/#/c/148624/9..15/keystone/tests/unit/test_v3_auth.py | 21:20 |
| morganfainberg | stevemar, it's the same thing i do with config_overrides in other tests | 21:20 |
| morganfainberg | stevemar, i think | 21:21 |
| morganfainberg | what is self.orig_policy_file used for? | 21:22 |
| dstanek | stevemar: 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 alias | 21:22 |
| *** pdesai1 has quit IRC | 21:22 | |
| morganfainberg | stevemar, it also looks like self.orig_policy_file may not be used | 21:22 |
| stevemar | ah yay | 21:22 |
| stevemar | yep, it's not | 21:23 |
| *** radez is now known as radez_g0n3 | 21:23 | |
| stevemar | i wonder if rules even needs to be reset | 21:23 |
| lbragstad | jorge_munoz: I'm going to push another version of the revocation patch for lightweight tokens. | 21:26 |
| lbragstad | jorge_munoz: just wanted to give you a heads up in case your working on it | 21:26 |
| lbragstad | jorge_munoz: adding some more test cases with disabled users. | 21:27 |
| *** rushiagr_away is now known as rushiagr | 21:27 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone: Use revocation events for lightweight tokens https://review.openstack.org/158414 | 21:28 |
| *** samueldmq is now known as samueldmq-away | 21:30 | |
| *** pdesai has joined #openstack-keystone | 21:31 | |
| *** pnavarro has quit IRC | 21:35 | |
| morganfainberg | stevemar, if rules needs to be reset, it likely should be an addCleanup not a "oh just reset these things" | 21:35 |
| dstanek | alias wft='rm -rf .testrepository; tox' | 21:38 |
| dstanek | problem fixed | 21:38 |
| * morganfainberg disappears for a bit to stare at gearman + oslo.messaging | 21:42 | |
| morganfainberg | ping me if you need me. | 21:42 |
| *** karimb has joined #openstack-keystone | 21:45 | |
| *** samueldmq has joined #openstack-keystone | 21:48 | |
| *** karimb has quit IRC | 21:48 | |
| *** abhirc has joined #openstack-keystone | 21:52 | |
| *** gabriel-bezerra has quit IRC | 21:58 | |
| *** henrynash has quit IRC | 22:01 | |
| *** pdesai has quit IRC | 22:02 | |
| *** csoukup has joined #openstack-keystone | 22:10 | |
| stevemar | dstanek, nice alias | 22:10 |
| dstanek | that's actually in my zsh aliases now | 22:11 |
| stevemar | dstanek, i believe you | 22:11 |
| dstanek | wtf -e functional | 22:11 |
| stevemar | morganfainberg, 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 changes | 22:12 |
| morganfainberg | stevemar, cool | 22:12 |
| stevemar | dhellmann, it would require another release of oslo.policy to make use of sigmavirus24's 'from_dict' change | 22:13 |
| stevemar | dhellmann, then actually adding it to g-r | 22:13 |
| dhellmann | stevemar: we can make another release in the morning, if the code is ready | 22:13 |
| openstackgerrit | David Stanek proposed openstack/keystone: Support for running functional federation tests https://review.openstack.org/139137 | 22:13 |
| openstackgerrit | David Stanek proposed openstack/keystone: enables bashate checking on dsvm code https://review.openstack.org/151309 | 22:13 |
| openstackgerrit | David Stanek proposed openstack/keystone: adds a devstack plugin for running a pysaml2 IdP https://review.openstack.org/151310 | 22:13 |
| openstackgerrit | David Stanek proposed openstack/keystone: adds a devstack plugin for setting up federation https://review.openstack.org/151311 | 22:13 |
| openstackgerrit | David Stanek proposed openstack/keystone: adds a tox target for functional tests https://review.openstack.org/150528 | 22:13 |
| openstackgerrit | David Stanek proposed openstack/keystone: Adds an initial functional test https://review.openstack.org/158466 | 22:13 |
| morganfainberg | stevemar, let me know when you post it/ anything that needs eyes before morning | 22:14 |
| * sigmavirus24 waves | 22:14 | |
| stevemar | dhellmann, 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 not | 22:15 |
| stevemar | sigmavirus24, https://review.openstack.org/#/c/148624/ !! | 22:15 |
| *** pdesai has joined #openstack-keystone | 22:15 | |
| sigmavirus24 | so much red stevemar | 22:15 |
| stevemar | sigmavirus24, only in 1 file :P | 22:16 |
| sigmavirus24 | it only takes 1 =P | 22:16 |
| *** radez_g0n3 is now known as radez | 22:16 | |
| *** nellysmitt has quit IRC | 22:16 | |
| *** nellysmitt has joined #openstack-keystone | 22:16 | |
| *** nellysmitt has quit IRC | 22:17 | |
| *** aix has joined #openstack-keystone | 22:26 | |
| *** mattfarina has quit IRC | 22:28 | |
| *** rushiagr is now known as rushiagr_away | 22:29 | |
| *** harlowja_ has quit IRC | 22:29 | |
| *** harlowja has joined #openstack-keystone | 22:30 | |
| *** gabriel-bezerra has joined #openstack-keystone | 22:30 | |
| *** pdesai has quit IRC | 22:32 | |
| mfisch | jamielennox: you around? | 22:34 |
| stevemar | mfisch, try again in 4 hours | 22:37 |
| mfisch | oh yeah, thx | 22:38 |
| *** Tahmina has joined #openstack-keystone | 22:45 | |
| *** pdesai has joined #openstack-keystone | 22:46 | |
| *** pdesai has quit IRC | 22:47 | |
| *** radez is now known as radez_g0n3 | 22:55 | |
| mfisch | jamielennox: unping | 22:57 |
| *** chrisshattuck has joined #openstack-keystone | 22:58 | |
| *** pdesai has joined #openstack-keystone | 23:00 | |
| jamielennox | mfisch: yea | 23:03 |
| jamielennox | stevemar: the timezones aren't that far of | 23:04 |
| *** harlowja has quit IRC | 23:04 | |
| *** rwsu is now known as rwsu-afk | 23:04 | |
| stevemar | jamielennox, ha, jokes on you, now i can ask you ksc questions | 23:04 |
| *** raildo has joined #openstack-keystone | 23:04 | |
| jamielennox | stevemar, gyee: i was waiting till today to talk about some of this service_catalog stuff | 23:05 |
| jamielennox | lhcheng: i put a comment on your bug 1424825 don't have DOA handle the catalog, let the plugins do that for you | 23:05 |
| openstack | bug 1424825 in django-openstack-auth "Parsing of service catalog should be less error prone" [Undecided,New] https://launchpad.net/bugs/1424825 | 23:05 |
| lhcheng | jamielennox: yeah, thanks for that! Didn't notice that auth plugins also exposes a get_endpoint() method | 23:06 |
| *** stevemar has quit IRC | 23:07 | |
| jamielennox | lhcheng: 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 it | 23:07 |
| lhcheng | jamielennox: 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 |
| jamielennox | clients shouldn't need it | 23:07 |
| *** stevemar has joined #openstack-keystone | 23:07 | |
| *** ChanServ sets mode: +v stevemar | 23:07 | |
| jamielennox | lhcheng: 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 it | 23:08 |
| jamielennox | i don't know how to get there yet | 23:08 |
| jamielennox | still figuring out some other DOA stuff | 23:08 |
| lhcheng | jamielennox: 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 IRC | 23:14 | |
| *** devlaps has joined #openstack-keystone | 23:14 | |
| *** harlowja has joined #openstack-keystone | 23:16 | |
| *** amaurymedeiros has quit IRC | 23:20 | |
| *** amaurymedeiros has joined #openstack-keystone | 23:20 | |
| gyee | jamielennox, what's your view on service catalog? | 23:21 |
| jamielennox | gyee: torn | 23:21 |
| jamielennox | initially i was thinking that k2k should be unscoped only but i see that doesn't make sense | 23:22 |
| jamielennox | from a practical point of view i don't think the current service catalog code will handle it | 23:22 |
| jamielennox | the way we check for type is kind of dumb | 23:22 |
| gyee | but ksc accept a generic filter no? | 23:23 |
| gyee | which is basically a dict | 23:23 |
| jamielennox | I think that the service catalog is a directory of things that the current token lets you access - and by that definition an external keystone counts | 23:23 |
| jamielennox | however the way you use that endpoint is going to be completely diferent | 23:23 |
| gyee | right, its just for endpoint lookup, nothing more | 23:24 |
| jamielennox | i'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 work | 23:24 |
| gyee | what are you going to do with that endpoint is strictly between you and the service provider | 23:24 |
| gyee | since the days of xml schema are long gone :) | 23:25 |
| jamielennox | i can see more benefit in iterating service providers than i do from endpoints though | 23:26 |
| jamielennox | and 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 type | 23:26 |
| gyee | what? I thought get_endpoint accepts a filter | 23:27 |
| jamielennox | it does | 23:27 |
| jamielennox | but it returns a single string | 23:27 |
| gyee | which is the url | 23:28 |
| *** jsavak has quit IRC | 23:28 | |
| jamielennox | yea, | 23:29 |
| *** amerine has joined #openstack-keystone | 23:30 | |
| gyee | which is good enough | 23:32 |
| gyee | unless we need more than a url | 23:32 |
| gyee | as everything else should be discoverable | 23:32 |
| gyee | via json home or other mechanisms | 23:32 |
| jamielennox | gyee: don't you think we want to standardize that a little more? | 23:33 |
| jamielennox | at the moment the service catalog holds together because of a convention pretty much defined by devstack | 23:33 |
| jamielennox | so my concern with the current get_endpoint only returning a string is you are asking for something particular | 23:35 |
| *** krtaylor has quit IRC | 23:35 | |
| jamielennox | and it was designed specifically to be used by multiple clients via request(..., endpoint_filter={}) rather than plugin.get_endpoint() | 23:35 |
| jamielennox | so 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 IRC | 23:36 | |
| jamielennox | wouldn'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 there | 23:36 |
| jamielennox | " | 23:36 |
| gyee | jamielennox, GET /v3/services?type=abc | 23:37 |
| *** gordc has quit IRC | 23:37 | |
| gyee | to me, catalog in token data service two purposes | 23:38 |
| jamielennox | gyee: if you're going to do that we don't need a catalog | 23:38 |
| gyee | 1) lookup endpoints user have access to | 23:38 |
| gyee | 2) endpoint constraints | 23:38 |
| gyee | there's no point of show services user have no access to | 23:39 |
| gyee | showing | 23:39 |
| jamielennox | agreed | 23:40 |
| *** abhirc has quit IRC | 23:41 | |
| *** abhirc has joined #openstack-keystone | 23:41 | |
| *** csoukup has quit IRC | 23:46 | |
| *** krtaylor has joined #openstack-keystone | 23:47 | |
| *** MasterPiece has joined #openstack-keystone | 23:53 | |
| *** mfisch has joined #openstack-keystone | 23:54 | |
| *** mfisch has quit IRC | 23:54 | |
| *** mfisch has joined #openstack-keystone | 23:54 | |
| *** pdesai has quit IRC | 23:58 | |
| *** Tahmina has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!