| *** adrian_otto has joined #openstack-keystone | 00:01 | |
| *** dave-mccowan has quit IRC | 00:08 | |
| *** tqtran has quit IRC | 00:25 | |
| *** catintheroof has quit IRC | 00:25 | |
| *** mfisch has quit IRC | 00:28 | |
| *** mfisch has joined #openstack-keystone | 00:29 | |
| *** mfisch has quit IRC | 00:29 | |
| *** mfisch has joined #openstack-keystone | 00:29 | |
| *** tqtran has joined #openstack-keystone | 00:43 | |
| *** Marcellin__ has quit IRC | 00:49 | |
| *** rcernin has quit IRC | 01:01 | |
| *** adrian_otto has quit IRC | 01:28 | |
| *** adrian_otto has joined #openstack-keystone | 01:28 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone: WIP - Allow user to change own expired password https://review.openstack.org/404022 | 01:30 |
|---|---|---|
| *** davechen_afk is now known as davechen | 01:31 | |
| *** zhangjl has joined #openstack-keystone | 01:33 | |
| *** narasimha_SV has quit IRC | 01:37 | |
| *** shuquan has joined #openstack-keystone | 01:40 | |
| *** gyee has quit IRC | 01:40 | |
| *** shuquan has quit IRC | 01:49 | |
| *** shuquan_ has joined #openstack-keystone | 01:50 | |
| *** adrian_otto has quit IRC | 01:52 | |
| *** chrisplo has quit IRC | 01:56 | |
| *** shuquan_1 has joined #openstack-keystone | 02:01 | |
| *** shuquan_ has quit IRC | 02:03 | |
| *** magic has joined #openstack-keystone | 02:12 | |
| *** agrebennikov has quit IRC | 02:13 | |
| *** xiaoyang has quit IRC | 02:16 | |
| *** spzala has quit IRC | 02:18 | |
| *** guoshan has joined #openstack-keystone | 02:21 | |
| *** browne has quit IRC | 02:28 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_projects https://review.openstack.org/405359 | 02:41 |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_projects https://review.openstack.org/405359 | 02:42 |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: WIP: Do not skip test_acess https://review.openstack.org/407221 | 02:42 |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_credentials https://review.openstack.org/405044 | 02:42 |
| *** Ephur has quit IRC | 02:44 | |
| *** edmondsw has quit IRC | 02:55 | |
| *** woodster_ has quit IRC | 02:56 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: Refactor test_projects https://review.openstack.org/405359 | 02:58 |
| openstackgerrit | Rodrigo Duarte proposed openstack/python-keystoneclient: WIP: Do not skip test_acess https://review.openstack.org/407221 | 02:58 |
| *** adrian_otto has joined #openstack-keystone | 03:17 | |
| *** udesale has joined #openstack-keystone | 03:23 | |
| *** adrian_otto has quit IRC | 03:23 | |
| *** adrian_otto has joined #openstack-keystone | 03:25 | |
| *** adrian_otto has quit IRC | 03:33 | |
| *** adrian_otto has joined #openstack-keystone | 03:33 | |
| *** spzala has joined #openstack-keystone | 03:42 | |
| *** code-R has joined #openstack-keystone | 03:42 | |
| *** adrian_otto has quit IRC | 03:43 | |
| *** adrian_otto has joined #openstack-keystone | 03:43 | |
| *** code-R_ has joined #openstack-keystone | 03:45 | |
| *** adrian_otto has quit IRC | 03:46 | |
| *** adrian_otto has joined #openstack-keystone | 03:47 | |
| *** adrian_otto has quit IRC | 03:47 | |
| *** code-R has quit IRC | 03:48 | |
| *** adrian_otto has joined #openstack-keystone | 03:48 | |
| *** links has joined #openstack-keystone | 03:52 | |
| *** adrian_otto1 has joined #openstack-keystone | 03:58 | |
| *** code-R_ has quit IRC | 03:59 | |
| *** code-R has joined #openstack-keystone | 03:59 | |
| *** zhangjl has quit IRC | 03:59 | |
| *** adrian_otto1 has quit IRC | 04:00 | |
| *** zhangjl has joined #openstack-keystone | 04:00 | |
| *** adrian_otto has quit IRC | 04:01 | |
| *** guoshan has quit IRC | 04:02 | |
| *** tqtran has quit IRC | 04:03 | |
| *** masber has joined #openstack-keystone | 04:07 | |
| openstackgerrit | Merged openstack/keystone: Remove CONF.os_inherit.enabled https://review.openstack.org/405679 | 04:12 |
| *** smaktub has joined #openstack-keystone | 04:16 | |
| smaktub | Hi. Are multiple endpoints for same service supported? | 04:17 |
| smaktub | For example, If I add first endpoint with url http://controller:5000/v2.0 and another with http://controller:5000/v3 | 04:19 |
| smaktub | ? | 04:19 |
| smaktub | Also, if there are multiple endpoints for the same service (API), which one would be used? | 04:21 |
| *** GB21 has joined #openstack-keystone | 04:21 | |
| *** edmondsw has joined #openstack-keystone | 04:24 | |
| *** mnaser has quit IRC | 04:25 | |
| *** mordred has quit IRC | 04:26 | |
| *** afazekas has quit IRC | 04:26 | |
| *** edmondsw has quit IRC | 04:29 | |
| *** spzala has quit IRC | 04:30 | |
| *** GB21 has quit IRC | 04:33 | |
| *** adrian_otto has joined #openstack-keystone | 04:42 | |
| *** diazjf has joined #openstack-keystone | 04:43 | |
| *** nicolasbock has quit IRC | 04:48 | |
| *** GB21 has joined #openstack-keystone | 04:49 | |
| *** alex_xu has joined #openstack-keystone | 04:49 | |
| *** alex_xu has quit IRC | 04:49 | |
| *** alex_xu has joined #openstack-keystone | 04:51 | |
| *** shuquan_1 has quit IRC | 04:53 | |
| *** afazekas has joined #openstack-keystone | 04:58 | |
| *** guoshan has joined #openstack-keystone | 05:03 | |
| *** mordred has joined #openstack-keystone | 05:04 | |
| *** nkinder has quit IRC | 05:07 | |
| *** guoshan has quit IRC | 05:08 | |
| *** mnaser has joined #openstack-keystone | 05:10 | |
| *** mfisch has quit IRC | 05:16 | |
| *** anteaya has quit IRC | 05:16 | |
| *** mordred has quit IRC | 05:18 | |
| *** mnaser has quit IRC | 05:18 | |
| *** nkinder has joined #openstack-keystone | 05:23 | |
| *** mfisch has joined #openstack-keystone | 05:23 | |
| *** mfisch is now known as Guest16197 | 05:23 | |
| *** code-R has quit IRC | 05:23 | |
| *** mordred has joined #openstack-keystone | 05:26 | |
| *** anteaya has joined #openstack-keystone | 05:29 | |
| *** code-R has joined #openstack-keystone | 05:29 | |
| *** mnaser has joined #openstack-keystone | 05:39 | |
| *** shuquan_ has joined #openstack-keystone | 05:40 | |
| openstackgerrit | Chetna proposed openstack/keystone: Corrects sample-data incorrect credential call https://review.openstack.org/407331 | 05:40 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Rename doctor symptom in security_compliance https://review.openstack.org/407206 | 05:41 |
| *** shuquan_ has quit IRC | 05:41 | |
| *** adriant has quit IRC | 05:53 | |
| *** gagehugo_ has joined #openstack-keystone | 05:56 | |
| *** adrian_otto has quit IRC | 05:56 | |
| *** gagehugo_ has left #openstack-keystone | 05:56 | |
| *** kiran-r has joined #openstack-keystone | 05:57 | |
| *** GB21 has quit IRC | 06:01 | |
| *** tqtran has joined #openstack-keystone | 06:03 | |
| *** guoshan has joined #openstack-keystone | 06:04 | |
| *** kiran-r has quit IRC | 06:05 | |
| *** tqtran has quit IRC | 06:07 | |
| *** adrian_otto has joined #openstack-keystone | 06:07 | |
| *** guoshan has quit IRC | 06:09 | |
| *** GB21 has joined #openstack-keystone | 06:14 | |
| *** guoshan has joined #openstack-keystone | 06:23 | |
| *** adrian_otto has quit IRC | 06:24 | |
| *** tovin07 has joined #openstack-keystone | 06:25 | |
| *** adrian_otto has joined #openstack-keystone | 06:25 | |
| *** adrian_otto has quit IRC | 06:27 | |
| *** spzala has joined #openstack-keystone | 06:30 | |
| *** rcernin has joined #openstack-keystone | 06:34 | |
| *** spzala has quit IRC | 06:34 | |
| *** code-R has quit IRC | 06:38 | |
| *** richm has quit IRC | 06:41 | |
| *** code-R has joined #openstack-keystone | 06:55 | |
| *** code-R has quit IRC | 07:00 | |
| *** smaktub has quit IRC | 07:01 | |
| *** rcernin has quit IRC | 07:12 | |
| *** code-R has joined #openstack-keystone | 07:14 | |
| *** voelzmo has joined #openstack-keystone | 07:22 | |
| *** voelzmo has quit IRC | 07:23 | |
| *** voelzmo has joined #openstack-keystone | 07:23 | |
| *** mordred has quit IRC | 07:25 | |
| *** Guest66666 has quit IRC | 07:27 | |
| *** Guest66666 has joined #openstack-keystone | 07:29 | |
| *** mnaser has quit IRC | 07:30 | |
| *** mrsoul has quit IRC | 07:32 | |
| *** mordred has joined #openstack-keystone | 07:34 | |
| *** rcernin has joined #openstack-keystone | 07:34 | |
| *** mrsoul has joined #openstack-keystone | 07:35 | |
| *** mnaser has joined #openstack-keystone | 07:39 | |
| *** GB21 has quit IRC | 07:39 | |
| *** pcaruana has joined #openstack-keystone | 07:42 | |
| *** code-R has quit IRC | 07:47 | |
| *** d0ugal has joined #openstack-keystone | 07:57 | |
| *** d0ugal has quit IRC | 07:57 | |
| *** d0ugal has joined #openstack-keystone | 07:57 | |
| *** mvk has quit IRC | 08:01 | |
| *** GB21 has joined #openstack-keystone | 08:02 | |
| *** pnavarro has joined #openstack-keystone | 08:05 | |
| *** mnaser has quit IRC | 08:15 | |
| *** code-R has joined #openstack-keystone | 08:18 | |
| *** code-R_ has joined #openstack-keystone | 08:21 | |
| *** edisonxiang has joined #openstack-keystone | 08:22 | |
| *** code-R has quit IRC | 08:24 | |
| *** ccard_ has quit IRC | 08:25 | |
| *** edisonxiang has left #openstack-keystone | 08:26 | |
| *** mnaser has joined #openstack-keystone | 08:33 | |
| *** mvk has joined #openstack-keystone | 08:33 | |
| *** pnavarro has quit IRC | 08:45 | |
| *** zzzeek has quit IRC | 09:00 | |
| *** zzzeek has joined #openstack-keystone | 09:00 | |
| *** GB21 has quit IRC | 09:05 | |
| *** asettle has joined #openstack-keystone | 09:09 | |
| *** GB21 has joined #openstack-keystone | 09:18 | |
| *** spzala has joined #openstack-keystone | 09:30 | |
| *** spzala has quit IRC | 09:35 | |
| *** daemontool has joined #openstack-keystone | 09:35 | |
| *** udesale has quit IRC | 09:43 | |
| *** udesale has joined #openstack-keystone | 09:49 | |
| *** huhaoran has joined #openstack-keystone | 10:01 | |
| *** voelzmo has quit IRC | 10:03 | |
| *** tqtran has joined #openstack-keystone | 10:06 | |
| *** tovin07 has quit IRC | 10:09 | |
| *** tqtran has quit IRC | 10:10 | |
| *** voelzmo has joined #openstack-keystone | 10:11 | |
| huhaoran | Hey, I am working on HA of keystone. I have seen the HA doc from the community. But the doc does not apply to the new keystone. Do anyone have some suggestion or docs to share? Thanks in advance. | 10:15 |
| *** eandersson has joined #openstack-keystone | 10:15 | |
| *** daemontool has quit IRC | 10:23 | |
| *** voelzmo has quit IRC | 10:30 | |
| *** voelzmo has joined #openstack-keystone | 10:32 | |
| *** guoshan has quit IRC | 10:34 | |
| *** voelzmo has quit IRC | 10:36 | |
| *** huhaoran has quit IRC | 10:46 | |
| *** huhaoran has joined #openstack-keystone | 10:47 | |
| *** Ephur has joined #openstack-keystone | 10:47 | |
| *** huhaoran has quit IRC | 10:51 | |
| *** huhaoran has joined #openstack-keystone | 10:51 | |
| *** Ephur has quit IRC | 10:52 | |
| *** narasimha_SV has joined #openstack-keystone | 10:54 | |
| narasimha_SV | http://paste.openstack.org/show/591515/ according to this log is this trying to create admin user or is this trying to modify the user details ??? | 10:54 |
| *** udesale has quit IRC | 11:03 | |
| *** chrisplo has joined #openstack-keystone | 11:10 | |
| *** zhangjl has quit IRC | 11:11 | |
| *** daemontool has joined #openstack-keystone | 11:11 | |
| *** richm has joined #openstack-keystone | 11:13 | |
| *** chrisplo has quit IRC | 11:15 | |
| *** faizy has joined #openstack-keystone | 11:35 | |
| *** voelzmo has joined #openstack-keystone | 11:36 | |
| *** nicolasbock has joined #openstack-keystone | 11:38 | |
| *** GB21 has quit IRC | 11:38 | |
| *** voelzmo has quit IRC | 11:40 | |
| *** jamielennox is now known as jamielennox|away | 11:44 | |
| *** faizy has quit IRC | 11:54 | |
| *** GB21 has joined #openstack-keystone | 11:55 | |
| *** voelzmo has joined #openstack-keystone | 11:56 | |
| *** GB21 has quit IRC | 12:07 | |
| *** GB21 has joined #openstack-keystone | 12:16 | |
| *** narasimha_SV has quit IRC | 12:16 | |
| *** code-R_ has quit IRC | 12:30 | |
| *** code-R has joined #openstack-keystone | 12:31 | |
| *** GB21 has quit IRC | 12:54 | |
| *** belmoreira has joined #openstack-keystone | 12:56 | |
| *** edmondsw has joined #openstack-keystone | 13:08 | |
| *** edmondsw_ has joined #openstack-keystone | 13:13 | |
| *** edmondsw_ has quit IRC | 13:17 | |
| *** dave-mccowan has joined #openstack-keystone | 13:19 | |
| *** lamt has joined #openstack-keystone | 13:19 | |
| samueldmq | good morning keystone | 13:20 |
| lbragstad | samueldmq morning | 13:21 |
| samueldmq | lbragstad: o/ | 13:21 |
| openstackgerrit | Merged openstack/keystone: Correct minor issues in test schema https://review.openstack.org/407234 | 13:24 |
| *** huhaoran has quit IRC | 13:25 | |
| *** adrian_otto has joined #openstack-keystone | 13:29 | |
| *** spzala has joined #openstack-keystone | 13:31 | |
| *** code-R_ has joined #openstack-keystone | 13:33 | |
| *** spzala has quit IRC | 13:36 | |
| *** code-R has quit IRC | 13:36 | |
| openstackgerrit | Merged openstack/keystone: Rename doctor symptom in security_compliance https://review.openstack.org/407206 | 13:37 |
| openstackgerrit | Merged openstack/keystone: Add unit tests for doctor federation file https://review.openstack.org/407188 | 13:37 |
| *** chrisplo has joined #openstack-keystone | 13:38 | |
| samueldmq | lbragstad: couple of questions on https://review.openstack.org/#/c/407036/ | 13:38 |
| lbragstad | samueldmq sure | 13:38 |
| samueldmq | lbragstad: overall it looks great and very well written :) | 13:39 |
| lbragstad | samueldmq thanks! | 13:39 |
| lbragstad | samueldmq i see henry commented on it, too... i'll get around to answering those shortly | 13:42 |
| samueldmq | lbragstad: awesome | 13:42 |
| *** chrisplo has quit IRC | 13:42 | |
| lbragstad | i want to have an updated version ready before the meeting today | 13:43 |
| *** catintheroof has joined #openstack-keystone | 13:43 | |
| samueldmq | lbragstad: that'd be nice | 13:43 |
| *** faizy has joined #openstack-keystone | 13:44 | |
| *** huhaoran has joined #openstack-keystone | 13:47 | |
| *** hrybacki|l4mG3 is now known as hrybacki | 13:53 | |
| *** Marcellin__ has joined #openstack-keystone | 13:58 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: api-ref update for roles assignments with names https://review.openstack.org/406366 | 14:01 |
| *** lamt has quit IRC | 14:01 | |
| *** lamt has joined #openstack-keystone | 14:02 | |
| *** Guest16197 is now known as mfisch | 14:03 | |
| *** mfisch is now known as Guest73037 | 14:04 | |
| *** daemontool has quit IRC | 14:04 | |
| *** adrian_otto has quit IRC | 14:11 | |
| *** faizy_ has joined #openstack-keystone | 14:11 | |
| *** faizy has quit IRC | 14:13 | |
| *** Guest73037 is now known as mfisch | 14:15 | |
| *** mfisch is now known as Guest13281 | 14:16 | |
| *** Guest13281 is now known as mfisch | 14:16 | |
| *** mfisch is now known as Guest40664 | 14:17 | |
| *** Guest40664 is now known as mfisch | 14:17 | |
| *** mfisch has quit IRC | 14:17 | |
| *** mfisch has joined #openstack-keystone | 14:17 | |
| *** faizy_ has quit IRC | 14:25 | |
| stevemar | o/ | 14:25 |
| lbragstad | stevemar o/ | 14:25 |
| *** thiagolib has joined #openstack-keystone | 14:31 | |
| openstackgerrit | Merged openstack/python-keystoneclient: Refactor test_credentials https://review.openstack.org/405044 | 14:35 |
| openstackgerrit | Merged openstack/python-keystoneclient: Refactor test_projects https://review.openstack.org/405359 | 14:35 |
| *** links has quit IRC | 14:40 | |
| *** Ephur has joined #openstack-keystone | 14:49 | |
| *** agrebennikov has joined #openstack-keystone | 14:50 | |
| *** Ephur has quit IRC | 14:53 | |
| *** udesale has joined #openstack-keystone | 14:59 | |
| *** narasimha_SV has joined #openstack-keystone | 15:08 | |
| *** udesale_ has joined #openstack-keystone | 15:08 | |
| *** phalmos has joined #openstack-keystone | 15:10 | |
| *** tqtran has joined #openstack-keystone | 15:10 | |
| *** udesale has quit IRC | 15:12 | |
| dstanek | agrebennikov: when you have some time can you document the usecase that's not solved with db replication? | 15:12 |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Get assignments with names honors inheritance flag https://review.openstack.org/380973 | 15:14 |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Add test to expose bug 1625230 https://review.openstack.org/407558 | 15:14 |
| openstack | bug 1625230 in OpenStack Identity (keystone) "Role Assignment Incorrectly Reports Inheritance when --name is Used" [Medium,In progress] https://launchpad.net/bugs/1625230 - Assigned to Kanika Singh (kanikasingh-1490) | 15:14 |
| agrebennikov | dstanek, I probably can, but most likely I'm just going to abandon it. Geo galera replication is ugly from any standpoint - deployment, maintenance, support, handling quorum etc. I mean specifically OpenStack db usecase | 15:15 |
| agrebennikov | and I see that the conversation goes nowhere | 15:15 |
| *** tqtran has quit IRC | 15:15 | |
| *** phalmos has quit IRC | 15:15 | |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Get assignments with names honors inheritance flag https://review.openstack.org/380973 | 15:15 |
| dstanek | agrebennikov: i think it's that you haven't actually show why this is needed. from what i can tell you just open up more holes and problems. | 15:16 |
| openstackgerrit | Colleen Murphy proposed openstack/keystone: Add anonymous bind to get_connection method https://review.openstack.org/407561 | 15:18 |
| dstanek | agrebennikov: i'd also be interested in alternatives. for example, has you looked at writing your own selective sync db->db? | 15:19 |
| agrebennikov | dstanek, I'm not sure if discussing proc and cons of db replication in "keystone" threads and the channel is a very good idea. It means we can end up with discussing the alternatives of the pacemaker, docker and aws benefits at the end of the day :D | 15:21 |
| *** phalmos has joined #openstack-keystone | 15:22 | |
| openstackgerrit | Colleen Murphy proposed openstack/keystone: Add anonymous bind to get_connection method https://review.openstack.org/407561 | 15:22 |
| dstanek | agrebennikov: to some extent you'll have to give specifics why this won't work and why we'd want to open up this new functionality | 15:22 |
| agrebennikov | in a few words it is this. From the day 1 when we started working with restful apis, we were always told: "you should Never Ever (if there is NOOO alternatives of course) touch the database. Ever" Use clients, use wrappers, add flexibility to the API | 15:24 |
| agrebennikov | since touching the DB is Always hacky | 15:24 |
| agrebennikov | in addition to that, you should Never expose your DB to the public network | 15:25 |
| agrebennikov | setting up geo replication means you are exposing your db engine into routable network | 15:25 |
| agrebennikov | this is literally similar to what are you guys explaining to me "allowing custom ID breaks everything". Where everything means the concept | 15:27 |
| dstanek | agrebennikov: there is nothing wrong with certain types of tools using the database directly. *you must only use REST* is a myth | 15:31 |
| *** diazjf has joined #openstack-keystone | 15:31 | |
| *** diazjf has quit IRC | 15:31 | |
| dstanek | agrebennikov: don't expose your DB to a customer routable network unless it's over a secure connection | 15:32 |
| *** knasim-wrs has joined #openstack-keystone | 15:35 | |
| *** agrebennikov has quit IRC | 15:39 | |
| *** faizy_ has joined #openstack-keystone | 15:41 | |
| *** kiran-r has joined #openstack-keystone | 15:43 | |
| *** faizy__ has joined #openstack-keystone | 15:43 | |
| *** faizy_ has quit IRC | 15:46 | |
| *** chris_hultin|AWA is now known as chris_hultin | 15:46 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms https://review.openstack.org/407062 | 15:47 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms https://review.openstack.org/407062 | 15:47 |
| *** ravelar has joined #openstack-keystone | 15:49 | |
| *** agrebennikov has joined #openstack-keystone | 15:50 | |
| *** adrian_otto has joined #openstack-keystone | 15:52 | |
| agrebennikov | dstanek, that's the whole point. I'm not a developer, I'm a deployment guy. And I have to choose between the frankenstein of multiple galera cluster with arbitrator and all that stuff, and maintain/backup it separately and so on | 15:55 |
| agrebennikov | and one 3-lines patch which will be local for the custom repo, very easy to port to the newer versions and which solves the problem. | 15:56 |
| agrebennikov | you see the point? | 15:56 |
| dstanek | agrebennikov: it's not just a 3-line patch because you open a bunch of problems | 15:59 |
| dstanek | we historically don't like features that we discourage people from using, which is what i think this would be | 16:00 |
| agrebennikov | dstanek, no, I mean - in the way I propose it. And it doesn't break anything in current customer's architecture | 16:00 |
| dstanek | agrebennikov: it could if it were to be used | 16:01 |
| *** nk2527 has joined #openstack-keystone | 16:03 | |
| *** nkinder has quit IRC | 16:05 | |
| agrebennikov | dstanek, maybe. And it will be Only clear when I started to use it. And because of this reason I have to put it into production now and watch. I bet with 99% probability it will be fine because I already tested it. Yes, there willbe some specific cases which I'll fix down the road. I also understand that using this new functionality users May get issues with tokens working in different clouds | 16:05 |
| *** HenryG has left #openstack-keystone | 16:05 | |
| *** ayoung-afk is now known as ayoung | 16:05 | |
| agrebennikov | but is is not more complicated than for example domain/project scoped tokens and policy | 16:05 |
| jgrassler | ayoung: do you have time to talk me out of https://review.openstack.org/#/c/396331/ properly? :-) | 16:06 |
| agrebennikov | dstanek, this is why I ask you guys Not to Change the functionality but just Extend it | 16:06 |
| ayoung | jgrassler, yes. BTW, I love that proposal, and the way you are thinking. You are just not quite going far enough | 16:06 |
| agrebennikov | so that I may use it If necessary | 16:06 |
| agrebennikov | well, it is pointless anyway | 16:07 |
| jgrassler | ayoung: not far enough? | 16:07 |
| agrebennikov | I'll go replicate my database | 16:07 |
| jgrassler | ayoung: because it's limited to trusts? | 16:07 |
| ayoung | jgrassler, I want it on every token | 16:07 |
| ayoung | yes | 16:07 |
| jgrassler | ayoung: ah...ambitious :-) | 16:07 |
| ayoung | jgrassler, so trust based tokens are no different from other tokens | 16:07 |
| ayoung | and the enforcement you need to make that happend would have to be done for tokens in general | 16:08 |
| *** jaugustine has joined #openstack-keystone | 16:08 | |
| ayoung | jgrassler, so...let's restate your goals... | 16:08 |
| ayoung | "Capabilities that impose additional limitations on the trust's access to oslo.policy targets" | 16:08 |
| ayoung | I.E I want a token that can only execute service:api | 16:08 |
| ayoung | compute:create_server | 16:08 |
| ayoung | that is the big one | 16:09 |
| ayoung | so...that is essentially what I am shooting for with RBAC | 16:09 |
| jgrassler | Yes, that would fit my goal | 16:09 |
| ayoung | but we need an inventory of the APIs first off | 16:09 |
| ayoung | jgrassler, lets hand wave that away for a moment | 16:09 |
| jgrassler | ayoung: agreed - that would go very far down the rabbit hole.. | 16:10 |
| ayoung | say we have that...how does a user know what policy rule they are trying to execute? | 16:10 |
| ayoung | jgrassler, heh...I've got a drone down that rabbit hole ATM | 16:10 |
| ayoung | the Rabbits are quivering with excitement | 16:10 |
| ayoung | but... | 16:10 |
| ayoung | to do delegation, a user needs to be able to answer the question: what role(or other attribute) do I need to delegate in order to make this happen | 16:11 |
| ayoung | and, with the oslo based approach, it is not clear that there is any way to answer it | 16:11 |
| ayoung | I want to make it clear, and enforce that based on the URL called. | 16:11 |
| dstanek | agrebennikov: from my perspective that preferable. it's not wise for us to make experimental change to APIs anyway | 16:11 |
| jgrassler | ayoung: I'm absolutely with you there | 16:11 |
| *** ravelar has quit IRC | 16:12 | |
| jgrassler | ayoung: full, keystone side RBAC is the way to go eventually | 16:12 |
| *** ravelar has joined #openstack-keystone | 16:12 | |
| ayoung | jgrassler, this is a shorter distance | 16:12 |
| jgrassler | ayoung: my spec is more of a stopgap measure to have similar functionality for trusts until all the infrastructure for proper RBAC is in place | 16:12 |
| ayoung | jgrassler, can't enforce on your spec, though | 16:13 |
| ayoung | need all the enforcement pieces in place, and that is where things will fall down | 16:13 |
| ayoung | so, forget about trusts for a moment...lets say that we need a mechanism to say "this token can only execute this API" | 16:13 |
| jgrassler | ayoung: you mean oslo.policy is handled too inhomogenously in individual services? | 16:13 |
| ayoung | and, if we have it working for norma; tokens, trust will inherit it | 16:13 |
| ayoung | jgrassler, not so much "inhomogenously" as monolithically | 16:14 |
| *** catinthe_ has joined #openstack-keystone | 16:14 | |
| ayoung | right now, there is no role check | 16:14 |
| ayoung | admin or "does tjhe project match" is it | 16:14 |
| ayoung | so...I want to add the role check as an additional pre-check | 16:15 |
| jgrassler | Yes, and I agree on that needing to be fixed | 16:15 |
| jgrassler | So do for the capability check | 16:15 |
| *** faizy__ has quit IRC | 16:15 | |
| ayoung | jgrassler, now, on the "per endpoint" thing, I don't know that I have a better answer for you. We've been over a few things along this line, and I would say that if you want to pursue that, go ahead | 16:15 |
| *** faizy has joined #openstack-keystone | 16:15 | |
| ayoung | it would have to be in the body of the token, and an explicit opt-in, not the service catalog | 16:16 |
| ayoung | remember, though, that endpoints don't know their own ID | 16:16 |
| jgrassler | ayoung: actually the per-endpoint thing is not too important to me | 16:16 |
| ayoung | and that was a killer issue in the past | 16:16 |
| *** daemontool has joined #openstack-keystone | 16:16 | |
| ayoung | OK...so lets get through RBAC first, and we can revisit per-endpoint later | 16:16 |
| jgrassler | ayoung: it is problematic, to say the least. Capabilities are way more important. | 16:16 |
| *** catintheroof has quit IRC | 16:16 | |
| ayoung | jgrassler, but to do the per endpoint, I do have a starting point... | 16:16 |
| *** chrisplo has joined #openstack-keystone | 16:17 | |
| *** code-R_ has quit IRC | 16:17 | |
| jgrassler | ayoung: You mean the service= setting in keystone_authtoken you suggest in your spec? | 16:17 |
| *** rcernin has quit IRC | 16:17 | |
| *** nkinder has joined #openstack-keystone | 16:17 | |
| *** catinthe_ has quit IRC | 16:18 | |
| ayoung | jgrassler, right | 16:18 |
| ayoung | jgrassler, that too | 16:18 |
| ayoung | but also this: | 16:18 |
| jgrassler | ayoung: (that together with the is_admin flag struck me as a good-enough (and far more robust) approach than full endpoint ID/URL matching) | 16:18 |
| ayoung | https://review.openstack.org/#/c/160909/ | 16:18 |
| *** pcaruana has quit IRC | 16:19 | |
| ayoung | jgrassler, we can't do just a single service in a token, as they are used for multi-service use cases. Well, we can, actually, but it involves some messing with the whole service token spec. | 16:19 |
| ayoung | the idea of a catalog subset, however, is that, once calculated, it could be used for the "limit the token to this subset" in a single value | 16:20 |
| ayoung | and that could be then tied to a trust, a token, enforced, etc | 16:20 |
| ayoung | but it still has the "what is my Identity" problem in the endpoints....so lets defer for now | 16:20 |
| jgrassler | Yeah. | 16:20 |
| jgrassler | As I said, endpoints are not that important to me. I'm more concerned with having a white list of API operations. | 16:21 |
| *** faizy has quit IRC | 16:21 | |
| jgrassler | For that would allow for clean handling of all these situations where people play with fire^Wtrusts in their current very permissive shape. | 16:23 |
| ayoung | jgrassler, ok...let me show you my trick... | 16:23 |
| openstackgerrit | Brant Knudson proposed openstack/keystone: Use consistent role schema in token response validation https://review.openstack.org/407587 | 16:24 |
| ayoung | find ./api-ref/source/ -name \*inc | xargs awk '/rest_method/ {print "{ verbs=[\"" $3"\"], url_pattern=\""$4"\" role=\"Member\" },"}' | 16:24 |
| bknudson | trying to figure out why role sometimes has domain_id in it. | 16:25 |
| bknudson | in the token response | 16:25 |
| ayoung | jgrassler, run that in the keystone repo, or nova, and you get a first take on the set of apis required for the RBAC approach | 16:25 |
| ayoung | bknudson, whoah | 16:25 |
| ayoung | really? | 16:25 |
| ayoung | in the role name? | 16:25 |
| ayoung | or as a separate field? | 16:25 |
| *** mvk has quit IRC | 16:26 | |
| openstackgerrit | Samuel Pilla proposed openstack/keystone: Domain included for role in list_role_assignment https://review.openstack.org/373516 | 16:26 |
| bknudson | ayoung: it's a separate field. domain_id | 16:26 |
| jgrassler | ayoung: yes...and if you add a `| wc -l` to that and sum the result up over all resources you see where my objection about the RBAC approach's daunting logistics comes from. | 16:26 |
| bknudson | it's always null in the tests... not sure if it can ever be something else. | 16:27 |
| ayoung | bknudson, could it be from a "v2 token validated via v3 API" or comparable code path? | 16:27 |
| ayoung | jgrassler, its roughly the same number of lines as on the policy.json files | 16:27 |
| bknudson | ayoung: I'll look into the tests some more. It's not mentioned in the API spec. | 16:27 |
| jgrassler | ayoung: Do you have a plan for ensuring all the roles required for finely grained RBAC are present in any cloud? | 16:27 |
| ayoung | jgrassler, I have a plan for a starting point | 16:28 |
| ayoung | jgrassler, I am not moving this mountain alone. But I do think we will end up with something like this: | 16:28 |
| jgrassler | ayoung: if that can be done I'm happy. For that's the main reason I still prefer the trusts based approach. | 16:28 |
| ayoung | jgrassler, they are complementary, but you still need this, or you need to go and change the policy enforcement in every.single.service | 16:29 |
| jgrassler | ayoung: well, that's why I suggested a pre check in oslo.policy (much like your pre check in keystonemiddleware) | 16:30 |
| jgrassler | ayoung: I definitely wouldn't want to go any deeper than that. That's truly insane, yes :-) | 16:30 |
| ayoung | jgrassler, I think that we will end up with some catch all roles like "Reader" for auditing. WOrkflow based roles like "create_server" that touch a few different services, and then a need to enforce on them based on the implied-roles | 16:32 |
| jgrassler | Because oslo.policy has a canonical name for each API operation/verb combination and that's enough information for a pre check | 16:32 |
| ayoung | we need a way to map from role to operation, and we don;'t have that yet | 16:32 |
| jgrassler | Hmm. | 16:32 |
| ayoung | jgrassler, it still doesn't gie a way to query, or even to generate in a generic way | 16:33 |
| jgrassler | How about getting the services to create these roles? | 16:33 |
| ayoung | jgrassler, do you really hate me that much? | 16:33 |
| *** chrisplo has quit IRC | 16:33 | |
| jgrassler | ayoung: no, querying won't work | 16:33 |
| bknudson | ayoung: turns out it is all trust scoped tokens that have null domain_id in the token roles. Here's the tests that failed: http://paste.openstack.org/show/591561/ | 16:34 |
| jgrassler | ayoung: well, the services would have to maintain basic rules anyway, wouldn't they? | 16:34 |
| jgrassler | ayoung: (at least you mentioned that in your spec) | 16:34 |
| *** peterstac has joined #openstack-keystone | 16:35 | |
| jgrassler | ayoung: so if we need to get them to provide these, we might as well get them to create and maintain a list of roles. | 16:35 |
| ayoung | jgrassler, and that is why .... find ./api-ref/source/ -name \*inc | xargs awk '/rest_method/ {print "{ verbs=[\"" $3"\"], url_pattern=\""$4"\" role=\"Member\" },"}' | 16:36 |
| ayoung | But we also can get the name of the URL called from the openstack CLI, or from any other tool | 16:36 |
| ayoung | its not buried in code, it can be deduced at run time... | 16:37 |
| jgrassler | Yes, the information is definitely there. | 16:37 |
| jgrassler | But a way to convert it into as set of hmm, let's call it "system roles", that can be expected to be there for each service running on any sufficiently up-to-date Openstack cloud would be nice to have. | 16:38 |
| jgrassler | s/as/a/ | 16:38 |
| *** kiran-r has quit IRC | 16:40 | |
| ayoung | jgrassler, start with everything using Member | 16:40 |
| ayoung | then, on a case by case basis, we will make the more specific roles | 16:40 |
| ayoung | we can do that this way: | 16:41 |
| *** knasim-wrs has quit IRC | 16:41 | |
| jgrassler | That will take very long... | 16:41 |
| ayoung | say we want to make a specific role for compute:do_thing | 16:41 |
| ayoung | jgrassler, everything in Openstack takes long | 16:41 |
| ayoung | I've been here since Keystone was incubated, and it still has this shortcoming | 16:41 |
| *** knasim-wrs has joined #openstack-keystone | 16:41 | |
| jgrassler | How about generating specific roles for everything and making Member imply all of the roles that previously specified role=Member? | 16:42 |
| jgrassler | Let me rephrase that: How about generating specific roles for everything and making Member imply all of the roles that resulted form verb/URL combinations with role="Member" | 16:43 |
| *** knasim-wrs has quit IRC | 16:44 | |
| jgrassler | Because one could put that through the "it takes long" process once | 16:45 |
| jgrassler | Incrementally adding roles would go through that process for _every_ new role | 16:46 |
| *** diazjf has joined #openstack-keystone | 16:46 | |
| *** belmoreira has quit IRC | 16:47 | |
| jgrassler | If one could (purely hypothetically) mandate that every project have a `$project-manage keystone-roles sync` and `$project-manage rbac-rules sync` command and get that through that slow, slow process once... | 16:48 |
| jgrassler | Also, on the Keystone side there would have to be some sort of mechanism to prevent role name collisions | 16:50 |
| *** diazjf has quit IRC | 16:50 | |
| jgrassler | I.e. to guard against scenarios where an operator manually creates a role compute_server_create, say and uses it for a very different purpose than the identically named upstream role | 16:51 |
| peterstac | Hi all, I'm trying to debug an authentication error in the gate | 16:53 |
| peterstac | http://logs.openstack.org/10/407210/4/check/gate-trove-scenario-dsvm-mysql-single-ubuntu-trusty/ab83ad7/console.html#_2016-12-06_14_37_10_294892 | 16:53 |
| peterstac | if I run the curl command locally (env set up with devstack) it works | 16:53 |
| peterstac | any glaring errors there that would typically only occur in the gate? | 16:54 |
| jgrassler | ayoung: but yeah, the "things take long" bit is why I opted for the trusts based approach, basically | 16:54 |
| ayoung | jgrassler, "Hear you nothing that I say?" Yoda | 16:54 |
| ayoung | THe issue is enforcement | 16:54 |
| ayoung | trusts do nothing for that | 16:54 |
| ayoung | Trust do a better job of defining delegation, period | 16:55 |
| *** LamT__ has joined #openstack-keystone | 16:55 | |
| ayoung | jgrassler, add a role per operation and you would be closer | 16:55 |
| ayoung | and that you could do automatically | 16:55 |
| ayoung | but...ugh | 16:55 |
| jgrassler | ayoung: yes...I'm looking for ways to do that in a standardized manner (that's why I indulged in that bit of speculation just now) | 16:56 |
| ayoung | jgrassler, so work with me on this | 16:56 |
| ayoung | If we work with the roles appraoch, and it does get too large, what we do is find a way to distinguish between classes of roles | 16:57 |
| ayoung | an operational role maps one to one with an operation | 16:57 |
| ayoung | a workflow role maps to a set of operational roles | 16:57 |
| ayoung | an organizational role maps to a set of workflows | 16:57 |
| jgrassler | ayoung: I do realize trusts are not the ideal vessel for this - I just went for them on a "I could get this to work" now approach | 16:57 |
| jgrassler | s/approach/basis/ | 16:58 |
| ayoung | when you list roles, you can specificy which class of roles you want to list | 16:58 |
| jgrassler | And I will join for the roles approach either way | 16:58 |
| jgrassler | In the mid to long term it's definitely more sensible | 16:59 |
| jgrassler | Also useful for things other than trusts, not least. | 17:00 |
| jgrassler | I used to operate an Openstack cloud in another life and the whole policy.json based RBAC thing messed with our lofty goals for clean role assignment something fierce... | 17:01 |
| *** Ephur has joined #openstack-keystone | 17:03 | |
| *** catintheroof has joined #openstack-keystone | 17:03 | |
| *** catintheroof has quit IRC | 17:03 | |
| *** catintheroof has joined #openstack-keystone | 17:04 | |
| jgrassler | Also, proper RBAC being in place will get me most of the way to my goal (nailed down trusts), too. | 17:05 |
| *** adrian_otto has quit IRC | 17:05 | |
| *** voelzmo has quit IRC | 17:07 | |
| jgrassler | Because if it's there I can use configuration management to create a designated "this role only gets to create Cinder volumes" role and make "Member" imply it, plus configure it as delegation role for whatever service creates a trust used for that operation. | 17:07 |
| jgrassler | ayoung: so in short, I'll work with you on the RBAC thing, yes :-) | 17:08 |
| jgrassler | ayoung: and I'm definitely up for any plot/scheme/conspiracy that aims to automatically create per-operation roles for every service... | 17:09 |
| *** pnavarro has joined #openstack-keystone | 17:11 | |
| *** diazjf has joined #openstack-keystone | 17:11 | |
| *** tqtran has joined #openstack-keystone | 17:12 | |
| ayoung | jgrassler, Excellent | 17:12 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 17:12 |
| *** rcernin has joined #openstack-keystone | 17:26 | |
| *** code-R has joined #openstack-keystone | 17:33 | |
| *** code-R_ has joined #openstack-keystone | 17:36 | |
| stevemar | lbragstad: oh nice bug | 17:38 |
| *** pnavarro has quit IRC | 17:38 | |
| stevemar | morgan: does your taskmanager interface for ksa need to be on the agenda? | 17:38 |
| *** code-R has quit IRC | 17:38 | |
| lbragstad | stevemar yeah | 17:39 |
| lbragstad | stevemar that was a fun one ;) | 17:39 |
| *** spilla has joined #openstack-keystone | 17:41 | |
| *** asettle has quit IRC | 17:42 | |
| stevemar | agrebennikov: did you want to still discuss the custom project id in the meeting also? | 17:43 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Expose password requirements through API https://review.openstack.org/407036 | 17:43 |
| stevemar | its on the agenda (whatever wasn't discussed from last week) | 17:43 |
| agrebennikov | yes sir | 17:43 |
| stevemar | but given the conversations here... okay. | 17:43 |
| *** chrisplo has joined #openstack-keystone | 17:44 | |
| *** udesale_ has quit IRC | 17:44 | |
| stevemar | agrebennikov: i'll try to motor though the first 2-3 topics so we have sufficient time for yours | 17:45 |
| agrebennikov | hopefully you'll not get stuck with the task manager ;) | 17:46 |
| agrebennikov | like last time with mfa | 17:46 |
| *** adrian_otto has joined #openstack-keystone | 17:47 | |
| *** Zer0Byte__ has joined #openstack-keystone | 17:52 | |
| edmondsw | stevemar if you get a chance, take a look at https://bugs.launchpad.net/python-cinderclient/+bug/1472295 . If you agree I think that bug can be rejected | 17:54 |
| openstack | Launchpad bug 1472295 in Glance Client "Cinder and glance client have endpoint selection issues" [Undecided,New] | 17:54 |
| stevemar | agrebennikov: shouldn't be, i asked morgan to remove that, the patch is being worked on, no reason to talk about it | 17:54 |
| stevemar | edmondsw: si? | 17:54 |
| edmondsw | if there is anything to fix there, it's probably in keystoneclient, not glanceclient/cinderclient | 17:54 |
| *** browne has joined #openstack-keystone | 17:55 | |
| lbragstad | stevemar if you want to bump my first topic you can - i just wanted it to be there to get focus on it/talk about options | 17:55 |
| stevemar | lbragstad: okay, i'll bump it | 17:57 |
| stevemar | edmondsw: thats a toughie | 17:57 |
| *** mvk has joined #openstack-keystone | 18:00 | |
| *** annakoppad_ has joined #openstack-keystone | 18:00 | |
| edmondsw | stevemar you thinking that keystoneclient shouldn't have used the links from the version check API response? | 18:02 |
| edmondsw | if you had keystone properly configured it wouldn't matter, because the link would have been correct | 18:02 |
| *** cbits has joined #openstack-keystone | 18:03 | |
| *** code-R_ has quit IRC | 18:06 | |
| *** huhaoran has quit IRC | 18:07 | |
| *** code-R has joined #openstack-keystone | 18:07 | |
| *** ravelar has quit IRC | 18:08 | |
| *** ravelar has joined #openstack-keystone | 18:08 | |
| *** diazjf has quit IRC | 18:09 | |
| *** eandersson has quit IRC | 18:10 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms https://review.openstack.org/407062 | 18:11 |
| *** faizy has joined #openstack-keystone | 18:25 | |
| *** faizy_ has joined #openstack-keystone | 18:31 | |
| *** faizy_ has quit IRC | 18:32 | |
| *** faizy has quit IRC | 18:33 | |
| *** faizy_ has joined #openstack-keystone | 18:33 | |
| *** asettle has joined #openstack-keystone | 18:35 | |
| *** spzala has joined #openstack-keystone | 18:50 | |
| *** ravelar has quit IRC | 18:50 | |
| *** asettle has quit IRC | 18:54 | |
| *** asettle has joined #openstack-keystone | 18:55 | |
| ayoung | OK here to answer stevemar and samueldmq ?s one RBAC | 18:59 |
| *** asettle has quit IRC | 18:59 | |
| ayoung | or anyone elses that cares to join in | 18:59 |
| stevemar | ayoung: can you give me 15 minutes, i need a caffeine injection | 19:00 |
| ayoung | stevemar, I'm not going anywhere. | 19:00 |
| lbragstad | same here - i have to get something to eat quick | 19:01 |
| ayoung | samueldmq, here is an autogenerated subset of what the Keystone RBAC rules would look like to start https://paste.fedoraproject.org/500624/10508921 | 19:01 |
| *** LamT__ has quit IRC | 19:02 | |
| *** pnavarro has joined #openstack-keystone | 19:02 | |
| *** narasimha_SV_ has joined #openstack-keystone | 19:04 | |
| samueldmq | ayoung: remember everything as Member may open security issues. e.g delete a domain | 19:04 |
| samueldmq | ayoung: that's just a nit | 19:04 |
| narasimha_SV_ | http://paste.openstack.org/show/591515/ keystone woth LDAP backend is giving this error | 19:05 |
| samueldmq | ayoung: my question in the meeting was if you are creating a new syntax to represent RBAC-only policy | 19:05 |
| narasimha_SV_ | password which I am am supplying for the admin user is the same password which I have in LDAP | 19:05 |
| samueldmq | which seems to be the case, right ? | 19:05 |
| *** narasimha_SV has quit IRC | 19:06 | |
| dstanek | narasimha_SV_: it appears that you are trying to create a user and you don't have the authorization to do that | 19:07 |
| *** huhaoran has joined #openstack-keystone | 19:07 | |
| *** jamielennox|away is now known as jamielennox | 19:07 | |
| samueldmq | narasimha_SV_: you must set the option user_allow_create to True in your config file | 19:08 |
| samueldmq | dstanek: ++ ^ | 19:08 |
| ayoung | samueldmq, it does not lessen existing policy | 19:09 |
| ayoung | this is just *in addition* to | 19:09 |
| ayoung | so if it is not a security issue now, it will not be with the additional RBAC] | 19:09 |
| narasimha_SV_ | +dstanek: http://paste.openstack.org/show/591587/ | 19:09 |
| narasimha_SV_ | these are my ldap configurations | 19:10 |
| ayoung | samueldmq, I have sample code that gives the idea of how I plan to enforce: | 19:10 |
| openstackgerrit | Merged openstack/keystone: api-ref update for roles assignments with names https://review.openstack.org/406366 | 19:10 |
| ayoung | https://paste.fedoraproject.org/500634/81051440 | 19:10 |
| samueldmq | ayoung: what about APIs that accept unscoped tokens ? | 19:10 |
| dstanek | narasimha_SV_: does the user you are using have the right assignments? | 19:10 |
| narasimha_SV_ | +samueldmq: as per specification keystone will not create the LDAP users right . we need to use those users created in LDAP | 19:11 |
| ayoung | samueldmq, we'll have to make sure those continue to pass | 19:11 |
| narasimha_SV_ | +dstanek: what do you mean by right permissions ? | 19:11 |
| dstanek | narasimha_SV_: what operation are you trying to do? it looks to me like you are trying to create a user | 19:11 |
| samueldmq | narasimha_SV_: in your first paste http://paste.openstack.org/show/591515/ you are trying to create a user | 19:11 |
| samueldmq | ayoung: looking | 19:12 |
| *** huhaoran has quit IRC | 19:12 | |
| narasimha_SV_ | no no I am runing keystone-manage bootstrap command I am getting above issue | 19:12 |
| ayoung | samueldmq, but I think those are only the ones for creating tokens in the first place, or rescoping, right>? | 19:12 |
| dstanek | narasimha_SV_: ah, that doesn't work with ldap yet | 19:12 |
| ayoung | narasimha_SV_, that will never work with LDAP... | 19:12 |
| ayoung | do this instead: | 19:12 |
| dstanek | narasimha_SV_: you can try the existing patch if you like. that's what i'm testing now | 19:12 |
| dstanek | ayoung: not true | 19:12 |
| ayoung | 1. set up your system with SQL for identity | 19:12 |
| ayoung | 2. asdd a domain specific backedn for LDAP in its own domain | 19:13 |
| samueldmq | ayoung: yes, like the federation ones for discovering what porjects and/or domains you can scope to | 19:13 |
| dstanek | https://review.openstack.org/#/c/395967/ | 19:13 |
| ayoung | samueldmq, we'll have to make a special exception for those. | 19:13 |
| dstanek | when that merges it won't do the user stuff, but will bootstrap everything else | 19:13 |
| *** catinthe_ has joined #openstack-keystone | 19:14 | |
| *** bapalm_ has quit IRC | 19:14 | |
| samueldmq | ayoung: honestly I am all for it. but I'd go with defining the roadmap. agreeing in the policy meeting | 19:15 |
| samueldmq | ayoung: and keeping track of all the bits and what implements each part | 19:16 |
| *** catintheroof has quit IRC | 19:16 | |
| samueldmq | ayoung: also Ocata is a shorter cycle :( | 19:16 |
| ayoung | samueldmq, the spec window is a bout to close. I need active support or its going to die via pocket veto | 19:16 |
| *** nk2527 has quit IRC | 19:17 | |
| samueldmq | ayoung: how do those policies get distributed to the endpoints ? | 19:18 |
| *** bapalm has joined #openstack-keystone | 19:18 | |
| samueldmq | ayoung: so that the middleware can enforce them ? | 19:18 |
| *** faizy_ has quit IRC | 19:19 | |
| *** code-R has quit IRC | 19:20 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 19:22 | |
| *** spzala has quit IRC | 19:23 | |
| *** AlexeyAbashkin has quit IRC | 19:23 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone-specs: Specification for MFA support https://review.openstack.org/405007 | 19:23 |
| morgan | dstanek: ^ addressed the two typos. other comments seemed to be addressed via the comments back and forth | 19:24 |
| *** pnavarro has quit IRC | 19:24 | |
| morgan | ayoung: ^ if you care to look (i know you're on your own spec) | 19:25 |
| ayoung | morgan, ok...so, what is the goal of MFA support? As I see it, it is to require MFA for certain operations, right? | 19:25 |
| morgan | ayoung: set MFA for a given user | 19:25 |
| morgan | required to authn | 19:26 |
| ayoung | morgan, for all operations? Not that we will look in the token later to see if MFA was used when, say, executing an operation against a more secure endpoint or something? | 19:26 |
| morgan | no for auth | 19:26 |
| morgan | just for auth. | 19:27 |
| morgan | you can add that feature later | 19:27 |
| samueldmq | morgan: you want that in this cycle ? | 19:27 |
| morgan | but this is just getting auth to require specific plugins/combinations | 19:27 |
| morgan | samueldmq: yes. talked with stevemar. | 19:27 |
| * samueldmq nods | 19:27 | |
| ayoung | morgan, that really needs external references | 19:29 |
| morgan | ayoung: i am open to requiring MFA for some ops (or everything we do as admin), but this is the github-like setup. as a user you can opt-in to mfa | 19:29 |
| ayoung | can go in later, but this should be built on a well established security principal | 19:29 |
| morgan | there really aren't any external references at this point | 19:29 |
| morgan | that are well defined in a place I can link | 19:29 |
| morgan | short of maybe... github? | 19:29 |
| ayoung | morgan, that can be an update, though | 19:29 |
| ayoung | I get it. "I want to set this on MY account" | 19:30 |
| ayoung | or "I want this for my people" | 19:30 |
| morgan | :) | 19:30 |
| ayoung | morgan, per user first, per domain later? | 19:30 |
| morgan | it's setting the framework for additional features as well | 19:30 |
| morgan | per-user first | 19:30 |
| morgan | if we want to expand to "all users in a domain" the mechanism is going to be the same | 19:30 |
| morgan | in the auth-processing code that is | 19:31 |
| ayoung | morgan, +2 from me | 19:31 |
| morgan | it wont ever be (as long as I have a say) "for scoping to this domain" or be "scope specific" (short of something in policy) | 19:31 |
| *** gyee has joined #openstack-keystone | 19:31 | |
| morgan | just because the UX on it starts looking terrible that someone needs to re-auth to re-scope | 19:32 |
| morgan | ayoung: cool | 19:32 |
| ayoung | morgan, got it. | 19:32 |
| morgan | ayoung: thx | 19:32 |
| ayoung | morgan, you cool with the RBAC spec as is? | 19:32 |
| morgan | ayoung: for the RBAC thing, maybe the "new rabc stuff" only applies to v3 and later tokens? | 19:32 |
| morgan | ayoung: re the earlier convo about v2 security holes | 19:32 |
| ayoung | morgan, I don;t see why, though | 19:32 |
| ayoung | I could see not appliying to V2 APIs | 19:33 |
| morgan | in general I need to re-review it, but it wasn't looking awful. | 19:33 |
| *** spzala has joined #openstack-keystone | 19:33 | |
| ayoung | but the V2 tokens still have the role data in it | 19:33 |
| morgan | yeah I think we should not apply it to v2 apis | 19:33 |
| morgan | v2 is on the short list to be removed in 2 cycles | 19:33 |
| ayoung | that is a keystone decision, but I think it can easily work with any of the APIs we have | 19:33 |
| openstackgerrit | Merged openstack/keystone-specs: Specification for MFA support https://review.openstack.org/405007 | 19:34 |
| morgan | enhancements should be 100% "is it a real security issue (aka CVE)" imo. but i'm also not PTL | 19:34 |
| *** pleia2 has quit IRC | 19:34 | |
| samueldmq | morgan: just to make sure, is the token request is backwards compatible? | 19:34 |
| ayoung | Ideally, this is done prior to any mapping, so we don't really know whether it is going to be a v2 or v3 api. We just need to skip it for unscoped apis | 19:34 |
| morgan | ayoung: uh. | 19:34 |
| *** pleia2 has joined #openstack-keystone | 19:34 | |
| ayoung | GAH!@ | 19:34 |
| morgan | ayoung: you shouldn't have single-core approved that man | 19:34 |
| morgan | :P | 19:34 |
| ayoung | I did not mean to +2A that | 19:34 |
| ayoung | so sorry | 19:34 |
| morgan | i figured it was a mistake | 19:34 |
| samueldmq | morgan: I was wondering if what we have today is identity/method or identity/methods (plural) | 19:34 |
| morgan | lets ask samueldmq, stevemar, and dstanek if they are ok with it | 19:34 |
| *** slunkad has quit IRC | 19:35 | |
| *** andreaf has quit IRC | 19:35 | |
| ayoung | morgan, ++ | 19:35 |
| morgan | we can revert it out or update it | 19:35 |
| ayoung | https://www.youtube.com/watch?v=rN6avab0fIY | 19:35 |
| morgan | ayoung: let me circle back on RBAC after i discuss with samueldmq so we can address the oops on approval :) | 19:35 |
| ayoung | ++ | 19:35 |
| samueldmq | infra was too fast to revert the W+1 | 19:35 |
| morgan | samueldmq: today you can supply multiple methods | 19:35 |
| *** nk2527 has joined #openstack-keystone | 19:36 | |
| morgan | samueldmq: and all must pass if you do | 19:36 |
| morgan | but there is no way to explicitly require multiuple methods to auth | 19:36 |
| *** slunkad has joined #openstack-keystone | 19:36 | |
| samueldmq | morgan: and that's your proposal | 19:36 |
| morgan | so if keystone.conf uses totp,password,external for example | 19:36 |
| morgan | you can use any of them | 19:36 |
| *** ravelar has joined #openstack-keystone | 19:36 | |
| morgan | individually or in a grouping | 19:36 |
| morgan | with this spec, we will have a way to say "you must use totp and password" | 19:37 |
| samueldmq | morgan: and that is on a per user basis | 19:37 |
| ayoung | I think we are good here. We can always accept updates to the spec if there are details we want to make different. dstanek 's message was "Overall I'm strongly for something like this." | 19:37 |
| morgan | and if you don't supply both auth plugins in the auth request, keystone would reject it | 19:37 |
| *** andreaf has joined #openstack-keystone | 19:37 | |
| morgan | ayoung: i think so too :) | 19:37 |
| morgan | samueldmq: correct, per user to start | 19:38 |
| morgan | samueldmq: with a self-service api (can also be set via admin "update user") | 19:38 |
| samueldmq | ayoung: how do users discover their required methods ? | 19:38 |
| ayoung | samueldmq, can be out of band to start | 19:38 |
| morgan | in the case of admin setup, it is out of band | 19:39 |
| samueldmq | perhaps providing useful error messages is a good approach | 19:39 |
| *** diazjf has joined #openstack-keystone | 19:39 | |
| morgan | in the case of user-initiated, you have set the values via self-service api | 19:39 |
| samueldmq | like specifying methods in the error message | 19:39 |
| morgan | i am inclined to leak what auth-types are required if we have rules for a given user | 19:40 |
| morgan | since today it is assumed you have "password" | 19:40 |
| morgan | it's not really a mystery | 19:40 |
| samueldmq | morgan: yes I agree with you | 19:40 |
| samueldmq | morgan: putting that in the error messages would be nice, as I just said | 19:40 |
| morgan | and by leak: i mean explicitly not obscure it in the 401 response. | 19:40 |
| samueldmq | morgan: x,y and z auth methods are required for the specified user | 19:41 |
| samueldmq | morgan: an API for it ? | 19:41 |
| dstanek | morgan: catching up... | 19:41 |
| morgan | "401, insufficient auth types, requires: JSON(x and y, or X and Z) | 19:41 |
| samueldmq | morgan: yes I like that | 19:41 |
| morgan | dstanek: the spec was oopse merged so doing the "what needs to change now or are we reverting it" with the interested cores | 19:41 |
| morgan | samueldmq: if there are no rules for a given user, it's just going to work like it does today with the 401. | 19:42 |
| samueldmq | morgan: tbh I'd like to see that in the spec because it describes how UX will be | 19:44 |
| samueldmq | morgan: I am also taking another look at it now | 19:44 |
| morgan | samueldmq: it is in the spec already | 19:45 |
| morgan | samueldmq: If insufficient auth plugins are supplied a ``HTTP 401`` with a JSON response | 19:45 |
| morgan | indicating insufficient auth parameters will be returned to the requestor. | 19:45 |
| dstanek | morgan: adrian had an interesting point about allowing certain plugins only in combination with others, but i'm not sure it's worth the complexity | 19:45 |
| morgan | dstanek: i am going to punt on that | 19:45 |
| morgan | for now | 19:45 |
| morgan | we can add complexity in | 19:46 |
| morgan | but we need basic functionality | 19:46 |
| morgan | if ocata wasn't a short cycle | 19:46 |
| morgan | i'd be more open for it | 19:46 |
| *** ravelar has quit IRC | 19:46 | |
| samueldmq | morgan: also, how does this behavior with federated users ? | 19:46 |
| dstanek | i'm fine with that is there assuming that we'll makes updates if we need to | 19:46 |
| morgan | samueldmq: since this is per-user base, federated user(s) are unaffected. | 19:47 |
| morgan | since either they don't exist in keystone (ephemeral) or are mapped to a real user | 19:47 |
| samueldmq | morgan: federated users are not ephemeral anymore | 19:47 |
| morgan | the federated plugin would be one-of-the auth methods | 19:47 |
| samueldmq | morgan: they exist in keystone tables after the first login, then we can do assignments, etc as any other user | 19:48 |
| morgan | for the most part, federated logins use an IDP | 19:48 |
| ayoung | samueldmq, if you are Ok with it, add the +2 even though it went through | 19:48 |
| morgan | it would be assumed the IDP does MFA | 19:48 |
| morgan | dstanek, samueldmq: can you add a comment you're +2 on it even though it merged | 19:48 |
| samueldmq | ayoung: I will leave a comment, can't +2 something that has merged | 19:49 |
| morgan | yeah | 19:49 |
| dstanek | morgan: already did | 19:49 |
| morgan | thnx! | 19:49 |
| ayoung | at least leave a comment | 19:49 |
| morgan | i'll create the BP now then. | 19:49 |
| samueldmq | morgan: rderose has a spec for exposing federated attributes via API | 19:50 |
| samueldmq | morgan: we might want to restrict federated plugin for federated users to avoid inconsistencies | 19:50 |
| morgan | sure. | 19:51 |
| morgan | ayoung: going to review a couple patches, then on to your spec. (need to look at something for shade right now) | 19:54 |
| ayoung | ++ | 19:54 |
| samueldmq | morgan: security impact section is TBD yet. do you have somthing in mind we could patch with another review ? | 19:55 |
| morgan | samueldmq: i'm thinking just add in that it is adding in optional security features | 19:56 |
| morgan | but doesn't really impact security overall. | 19:56 |
| morgan | i'll spin a patch up for that today or thursday (tomorrow I am booked solid trying to get a place locked down in Seattle to live) | 19:57 |
| samueldmq | morgan: yes, at least mentioning it is allowing to enforce different security levels for different users or somethign like that | 19:57 |
| samueldmq | morgan: I can do that now | 19:57 |
| stevemar | ayoung: sorry, around-ish now | 19:59 |
| *** ravelar has joined #openstack-keystone | 20:00 | |
| stevemar | ayoung: in https://review.openstack.org/#/c/391624/15/specs/keystone/ongoing/role-check-from-middleware.rst | 20:00 |
| stevemar | when you say "Create an entity in the resource backend" -- who creates that entity? | 20:00 |
| stevemar | is it for people who want to proactively add role-checking in middleware? they create some keystone db entry that maps URL + VERB to a role? | 20:01 |
| ayoung | stevemar, when a user (probably the admin setting up the remote sercvice) calls the API to upload the rules | 20:01 |
| ayoung | stevemar, yes | 20:01 |
| ayoung | it will be part of the cluster initialization | 20:01 |
| ayoung | we could probably trigger a default rule off the service catalog "Create service" api | 20:02 |
| *** catintheroof has joined #openstack-keystone | 20:02 | |
| ayoung | but this is the per VERB + URL_Pattern version | 20:02 |
| stevemar | ayoung: OK, maybe part of bootstrap we could do a bulk initiatilization one day | 20:02 |
| ayoung | stevemar, yes, at least for default, but we can figure out the overall ownership over time | 20:03 |
| *** catinthe_ has quit IRC | 20:04 | |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone-specs: Add security impact on per user auth plugin spec https://review.openstack.org/407688 | 20:04 |
| samueldmq | morgan: ayoung: dstanek: stevemar ^ | 20:05 |
| morgan | samueldmq: ah ty! | 20:05 |
| ayoung | see...we can approve specs and continue to improve them. Living docs | 20:06 |
| samueldmq | morgan: my pleasure | 20:06 |
| samueldmq | ayoung: ... | 20:06 |
| morgan | ayoung: OMG no way! :) ;) :P | 20:07 |
| *** asettle has joined #openstack-keystone | 20:11 | |
| *** asettle has quit IRC | 20:14 | |
| stevemar | ayoung: my concern is with getting the RBAC data back for validation | 20:16 |
| stevemar | but this is pretty isolated | 20:16 |
| stevemar | and opt-in | 20:16 |
| stevemar | this will take a while, i see now why you placed it in ongoing | 20:17 |
| morgan | ++ | 20:17 |
| stevemar | ayoung: http://i.imgur.com/ZQS0vpF.gif | 20:18 |
| ayoung | stevemar, what do you mean by "getting the RBAC data back for validation" | 20:19 |
| stevemar | ayoung: the calls from middleware to keystone server | 20:19 |
| stevemar | There would be a small, but non-zero impact in the remote service due | 20:20 |
| stevemar | to the need to fetch and cache the RBAC data. Since the API matching | 20:20 |
| stevemar | rules fetched from in the Keystone server will likely be cached in | 20:20 |
| stevemar | the remote server, there should be minimal impact on the Keystone side | 20:20 |
| ayoung | stevemar, so that will be "list all rules for service" | 20:20 |
| stevemar | due to database lookups. | 20:20 |
| ayoung | right | 20:20 |
| stevemar | ayoung: i'm interested to see what those numbers look like | 20:20 |
| openstackgerrit | Merged openstack/keystone-specs: Add security impact on per user auth plugin spec https://review.openstack.org/407688 | 20:21 |
| ayoung | stevemar, roughly an additional token verification would be my guess | 20:21 |
| ayoung | and, cahcing will mitigate, but delay the freshness...as in all things | 20:21 |
| stevemar | ayoung: +2 | 20:22 |
| *** narasimha_SV_ has quit IRC | 20:22 | |
| *** adriant has joined #openstack-keystone | 20:25 | |
| stevemar | morgan: gah, adriant isn't around, do you know if he still wants to go down the self management of TOTP creds spec? | 20:25 |
| morgan | stevemar: not sure | 20:26 |
| morgan | he should be around alter on | 20:26 |
| morgan | he tends to clock in mid afternoon my time | 20:26 |
| stevemar | morgan: yeah, he's in NZ i think | 20:26 |
| morgan | yup | 20:27 |
| stevemar | morgan: okie dokie | 20:28 |
| morgan | stevemar: i'd be ok with landing that spec / new plugin since we're getting the MFA one... but honestly I'd rather see that combined password+totp one be an auth plugin in KSA | 20:33 |
| morgan | that dfoes the split for us | 20:33 |
| morgan | make it a client logic thing | 20:34 |
| adriant | stevemar: am here now! | 20:34 |
| stevemar | adriant: heyo! | 20:34 |
| stevemar | morgan: so i like the idea of a new auth plugin that is smart enough to handle this | 20:35 |
| *** spzala has quit IRC | 20:35 | |
| stevemar | morgan: but user management of credentials is still a PITA i think? | 20:35 |
| morgan | stevemar: yes. | 20:36 |
| morgan | look it's adriant ! | 20:36 |
| adriant | morgan: hello :) | 20:36 |
| adriant | 9:37am here. I'm not much of a morning person :( | 20:37 |
| morgan | stevemar: i think the totp self management should be a client side thing in general. not server | 20:37 |
| morgan | stevemar: thats all | 20:37 |
| adriant | morgan: I don't mind where it is, just I do think we need to consider it as part of openstack, because setting up MFA with no way to use it natively is useless MFA. | 20:38 |
| adriant | "We have this feature!" "How can I use it?!" "Be admin, or ask your admin to set it up." | 20:39 |
| adriant | not exactly good UX | 20:39 |
| stevemar | adriant: i agree that is a sad | 20:39 |
| morgan | right. if the client can create the totp credential sanely and upload it | 20:39 |
| morgan | i'm all for it | 20:39 |
| morgan | and with the self-service mfa stuff | 20:40 |
| morgan | you still need to verify the cred is working before you make it mandatory | 20:40 |
| morgan | in the case of deployer setup, the external portal would handle both of those parts | 20:40 |
| morgan | 9 | 20:40 |
| morgan | (still client side, effectively) | 20:40 |
| stevemar | morgan: so i wouldn't be able to do it myself through APIs i have access to? | 20:41 |
| *** asettle has joined #openstack-keystone | 20:41 | |
| morgan | stevemar: you would be able to store a credential | 20:41 |
| morgan | you would not be able to generate a totp secret | 20:41 |
| morgan | and you wuold be able to use and change the auth-plugin rules | 20:42 |
| morgan | keystone wont have an api to generate a specific type of credential (excluding ec2) | 20:42 |
| samueldmq | morgan: so ec2 is kinda special ? | 20:43 |
| morgan | ec2 is "special" | 20:43 |
| *** nk2527 has quit IRC | 20:43 | |
| morgan | in.. a negative way | 20:43 |
| samueldmq | morgan: my concern there was that it's proposed to create new api entries for that | 20:43 |
| morgan | it also doesn't really work like normal auth workflows | 20:43 |
| *** daemontool_ has joined #openstack-keystone | 20:44 | |
| adriant | morgan: the problem is the ec2 stuff is useful. It might be an idea to look at rebuilding it better in future, and deprecate the old stuff. | 20:45 |
| morgan | adriant: we can't really remove it at this point | 20:45 |
| morgan | it's special | 20:45 |
| morgan | we'll leave it as special | 20:45 |
| *** knasim-wrs has joined #openstack-keystone | 20:46 | |
| morgan | but we don't need to add "more" special cases, especially when it works like normal auth-workflows | 20:47 |
| *** daemontool has quit IRC | 20:47 | |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone: Invalidate token cache after token delete https://review.openstack.org/316991 | 20:47 |
| *** diazjf has quit IRC | 20:54 | |
| *** david-lyle has quit IRC | 20:55 | |
| morgan | ayoung: +2 | 20:58 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 21:00 |
| ayoung | morgan, stevemar TYVM | 21:06 |
| *** catintheroof has quit IRC | 21:06 | |
| *** diazjf has joined #openstack-keystone | 21:08 | |
| *** huhaoran has joined #openstack-keystone | 21:09 | |
| *** dave-mccowan has quit IRC | 21:10 | |
| *** huhaoran has quit IRC | 21:14 | |
| *** chris_hultin is now known as chris_hultin|AWA | 21:20 | |
| *** spzala has joined #openstack-keystone | 21:26 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 21:34 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Print name with duplicate error on user creation https://review.openstack.org/405104 | 21:42 |
| *** chlong has joined #openstack-keystone | 21:43 | |
| ayoung | morgan, with bootstrap and a developer setup, how are we supposed to initialize the service catalog? | 21:51 |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Add unit tests for doctor's database symptoms https://review.openstack.org/407062 | 21:52 |
| stevemar | ayoung: why not use bootstrap? | 21:52 |
| ayoung | stevemar, I did. No catalog | 21:53 |
| ayoung | what did I miss? | 21:53 |
| stevemar | ayoung: oh, bootstrap with no opts doesn't set it up | 21:53 |
| stevemar | ayoung: http://docs.openstack.org/developer/keystone/configuration.html#bootstrapping-keystone-with-keystone-manage-bootstrap | 21:53 |
| ayoung | so I need --bootstrap-service-name | 21:53 |
| morgan | yeah | 21:53 |
| stevemar | $ keystone-manage bootstrap \ | 21:53 |
| stevemar | --bootstrap-password s3cr3t \ | 21:53 |
| stevemar | --bootstrap-username admin \ | 21:53 |
| stevemar | --bootstrap-project-name admin \ | 21:53 |
| stevemar | --bootstrap-role-name admin \ | 21:53 |
| stevemar | --bootstrap-service-name keystone \ | 21:53 |
| stevemar | --bootstrap-region-id RegionOne \ | 21:53 |
| stevemar | --bootstrap-admin-url http://localhost:35357 \ | 21:54 |
| stevemar | --bootstrap-public-url http://localhost:5000 \ | 21:54 |
| stevemar | --bootstrap-internal-url http://localhost:5000 | 21:54 |
| morgan | that will get you the basic catalog | 21:54 |
| bknudson | is this a joke? | 21:54 |
| morgan | then you can setup the rest | 21:54 |
| ayoung | stevemar, we need to make it clearer that without at l;east the identity ones we don't get a functioning keystone | 21:54 |
| stevemar | you can probably omit the username, project, role, and service name | 21:54 |
| morgan | you need a keystone entry | 21:54 |
| ayoung | you can't perform normal operations without identity | 21:54 |
| stevemar | bknudson: sorry for the spam | 21:54 |
| bknudson | all the arguments really start with --bootstrap? | 21:55 |
| *** daemontool_ has quit IRC | 21:55 | |
| annakoppad_ | hello all, I ran the stack script, then unstacked it, enabled ldap, and then ran stack, its throwing up this error, Volume group "stack-volumes-lvmdriver-1" not found devstack. I have configured ldap as per https://wiki.openstack.org/wiki/OpenLDAP#Ubuntu, and http://www.ibm.com/developerworks/cloud/library/cl-ldap-keystone/cl-ldap-keystone-pdf.pdf | 21:55 |
| *** daemontool_ has joined #openstack-keystone | 21:55 | |
| annakoppad_ | can someone help? | 21:55 |
| morgan | ayoung: you can technically do it w/o the catalog | 21:55 |
| morgan | ayoung: but you have to pass other args to osc | 21:55 |
| stevemar | ayoung: it functions, you have an admin user that can do admin-y stuff now | 21:55 |
| ayoung | morgan, can you? | 21:55 |
| morgan | ayoung: it is much easier to do with the args to keystone-manage | 21:55 |
| morgan | ayoung: yes. it'sd the same way you used to pass old-admin token | 21:55 |
| morgan | before the catalog was populated | 21:56 |
| ayoung | morgan, say I did it without bootstrap, and I wanted to add a service catalog later. | 21:56 |
| morgan | it is way more difficult to get right | 21:56 |
| stevemar | bknudson: yeah, all prefixed by --bootstrap- | 21:56 |
| morgan | and has more edge-cases | 21:56 |
| morgan | ayoung: it is much better to add it via bootstrap | 21:56 |
| stevemar | annakoppad_: whats your local.conf look like? | 21:57 |
| morgan | ok i need lunch | 21:57 |
| ayoung | annakoppad_, I saw that error, too. It looks like an error with Cinder | 21:58 |
| ayoung | I still got it once I unstacked and restacked, I tink...let me check | 21:59 |
| ayoung | No, mine worked...lets see... | 21:59 |
| ayoung | I wanted to work devstack with just ENABLED_SERVICES=key,g-api,g-reg,rabbit,mysql | 22:00 |
| bknudson | that's how I run devstack | 22:01 |
| *** Ephur has quit IRC | 22:01 | |
| annakoppad_ | I think I am going to sleep.its been a couple of times that I tried several workarounds for the same. Good night all. But I will be up tomorrow. | 22:03 |
| *** ravelar has quit IRC | 22:03 | |
| *** ravelar has joined #openstack-keystone | 22:03 | |
| *** chlong has quit IRC | 22:06 | |
| stevemar | annakoppad_: gn! | 22:06 |
| mfisch | lbragstad: I just noticed we have some new errors in our Newton deploy | 22:07 |
| stevemar | mfisch: ? | 22:07 |
| mfisch | its when ldappool binds to AD | 22:07 |
| *** chlong has joined #openstack-keystone | 22:07 | |
| mfisch | I never saw it in M and keystone appear functional | 22:07 |
| mfisch | its an LDAP invalid creds error which is odd | 22:08 |
| bknudson | we aim for appearing functional. | 22:08 |
| mfisch | I can't cause it with a bad auth request | 22:08 |
| mfisch | I was going to roll N into prod tomorrow but this is concerning | 22:08 |
| *** annakoppad_ has left #openstack-keystone | 22:10 | |
| stevemar | mfisch: we only had a few changes to ldappool after taking ownership of it | 22:10 |
| mfisch | this looks like a straight up fail to auth but odd that it just started showing up | 22:11 |
| mfisch | or maybe its been there but the error stack changed? | 22:12 |
| stevemar | mfisch: maybe, only a handful of commits: https://github.com/openstack/ldappool/compare/1.0...2.0.0 | 22:12 |
| *** chlong has quit IRC | 22:12 | |
| mfisch | I did go from 1->2 | 22:13 |
| mfisch | stevemar: https://github.com/openstack/ldappool/commit/91f5cbc36f7bd9d3c0516249bcb871b8841a4f96 | 22:14 |
| mfisch | hmm thats not it | 22:14 |
| mfisch | but something being logged that wasnt before could be | 22:14 |
| mfisch | stevemar: looks like python-ldap to pyldap? | 22:16 |
| mfisch | that could explain new behavior | 22:16 |
| lbragstad | mfisch hmmm - what's the error? | 22:19 |
| mfisch | its that commit | 22:20 |
| mfisch | "Failure attempting to create and bind connector" | 22:20 |
| mfisch | I do know for sure that we have packet loss between us and the LDAP server thats being worked on | 22:20 |
| mfisch | which explains why its failing probably just that the message is new | 22:20 |
| stevemar | mfisch: ah okay | 22:22 |
| stevemar | that makes sense | 22:22 |
| * mfisch is unworried now | 22:22 | |
| stevemar | mfisch: that one was merged before we took ownership of the project, it was just unreleased | 22:22 |
| lbragstad | mfisch move along citizen - nothing to see | 22:23 |
| mfisch | http://paste.openstack.org/show/591595/ | 22:23 |
| mfisch | if you are curious | 22:23 |
| mfisch | hopefuly my password isnt in there | 22:23 |
| mfisch | stevemar: you work at IBM you can probably decode those horrible AD codes | 22:23 |
| lbragstad | mfisch AD decoding is part of big blue orientation ;P | 22:24 |
| *** david-lyle has joined #openstack-keystone | 22:24 | |
| mfisch | I worked at little blue so all I know is Itanium interrupt handling | 22:25 |
| *** spilla has quit IRC | 22:32 | |
| *** dave-mccowan has joined #openstack-keystone | 22:32 | |
| *** daemontool_ has quit IRC | 22:33 | |
| *** dave-mcc_ has joined #openstack-keystone | 22:34 | |
| *** daemontool_ has joined #openstack-keystone | 22:34 | |
| *** dave-mccowan has quit IRC | 22:37 | |
| *** asettle has quit IRC | 22:40 | |
| stevemar | erhm... DSID-0C0903A8 | 22:40 |
| stevemar | yep, no idea | 22:40 |
| stevemar | mfisch: little blue? | 22:40 |
| stevemar | mfisch: http://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec1135548.html | 22:41 |
| *** david-lyle has quit IRC | 22:41 | |
| *** david-lyle has joined #openstack-keystone | 22:41 | |
| stevemar | "i'm helping" http://stream1.gifsoup.com/view6/4659509/i-m-ralph-o.gif | 22:42 |
| openstackgerrit | Ron De Rose proposed openstack/keystone: WIP - Require domain_id when registering Identity Providers https://review.openstack.org/399684 | 22:42 |
| *** harlowja has quit IRC | 22:43 | |
| *** harlowja has joined #openstack-keystone | 22:43 | |
| *** david-lyle has quit IRC | 22:46 | |
| *** knasim-wrs has quit IRC | 22:48 | |
| *** adrian_otto has quit IRC | 22:50 | |
| *** chris_hultin|AWA is now known as chris_hultin | 22:50 | |
| *** edmondsw has quit IRC | 22:51 | |
| *** edmondsw has joined #openstack-keystone | 22:59 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Print name with duplicate error on user creation https://review.openstack.org/405104 | 22:59 |
| *** chris_hultin is now known as chris_hultin|AWA | 23:00 | |
| *** asettle has joined #openstack-keystone | 23:00 | |
| *** asettle has quit IRC | 23:01 | |
| *** rcernin has quit IRC | 23:02 | |
| *** jamielennox is now known as jamielennox|away | 23:05 | |
| ayoung | mfisch, I'm going to go out on a limb here and say that you are trying to log in with invalid credentials | 23:05 |
| ayoung | were you doing anonymous bind for the the service user in the past? | 23:06 |
| *** edmondsw has quit IRC | 23:06 | |
| *** jamielennox|away is now known as jamielennox | 23:06 | |
| *** chris_hultin|AWA is now known as chris_hultin | 23:07 | |
| *** dave-mcc_ has quit IRC | 23:08 | |
| *** cbits has quit IRC | 23:11 | |
| mfisch | ayoung: those errors are not when users fail to sign in, its our service account failing | 23:11 |
| mfisch | which is why I suspect the packet loss, its caused similar issues | 23:11 |
| mfisch | anyway I'm no longer worried, I suspect we've had it for a long time but just see the errors with the new ldappool module | 23:12 |
| jamielennox | sorry i miseed the meeting earlier | 23:12 |
| lbragstad | jamielennox no worries | 23:13 |
| lbragstad | jamielennox everyone gets a mulligan from time to time | 23:13 |
| morgan | jamielennox: i also missed the meeting | 23:31 |
| morgan | jamielennox: sooooo | 23:31 |
| jamielennox | morgan: you had the topic i thought i should most listen to, so ok | 23:31 |
| morgan | which one? | 23:32 |
| morgan | MFA one? | 23:32 |
| jamielennox | taskmanager | 23:32 |
| morgan | oh | 23:32 |
| morgan | that | 23:32 |
| jamielennox | i figure i knew most of it | 23:32 |
| morgan | yeah. lets just discuss in IRC and get mordred to help doc it | 23:32 |
| morgan | and then land it | 23:32 |
| morgan | no meeting needed now | 23:32 |
| morgan | imo | 23:33 |
| morgan | since it';s just context manager | 23:33 |
| mordred | uhoh. what did I do? | 23:33 |
| mordred | hahahah. morgan said "get mordred to help doc it" | 23:33 |
| morgan | help document the contextmanager ksa session thing | 23:33 |
| morgan | since.. shade/nodepool uses it | 23:34 |
| morgan | just a concrete example or so | 23:34 |
| mordred | ++ | 23:34 |
| morgan | mostly the docstrings are enough beyond that | 23:34 |
| mordred | I was actually planning on making a quick local patch on the plane to show shade usage of it - just in case any gotchas arise | 23:35 |
| mordred | so yeah - that's totes legit | 23:35 |
| morgan | perfect | 23:35 |
| morgan | so lets use that as the example for docs :) | 23:35 |
| *** diazjf has quit IRC | 23:35 | |
| *** masber has quit IRC | 23:37 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone: Revert "Rename doctor symptom in security_compliance" https://review.openstack.org/407763 | 23:39 |
| *** agrebennikov has quit IRC | 23:42 | |
| *** jaugustine has quit IRC | 23:49 | |
| ayoung | morgan, I like what I saw of it last... | 23:54 |
| *** catintheroof has joined #openstack-keystone | 23:58 | |
| *** Marcellin__ has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
