| *** _sunil_ has joined #openstack-keystone | 00:01 | |
| dolphm | jamielennox: there's totally a brew for mysql | 00:01 |
|---|---|---|
| jamielennox | dolphm: oh yea, just not one that's devstacked - anyway, answers my question that we don't care about devstack on OSX because obviously stupid to run it on your desktop and there's no brew options in devstack | 00:02 |
| dolphm | jamielennox: ah yeah | 00:02 |
| dolphm | yeah no one should run devstack on os x | 00:02 |
| dolphm | even if you could | 00:02 |
| *** RichardRaseley has quit IRC | 00:02 | |
| *** gokrokve has joined #openstack-keystone | 00:04 | |
| *** tellesnobrega has joined #openstack-keystone | 00:07 | |
| *** marcoemorais has quit IRC | 00:07 | |
| *** marcoemorais has joined #openstack-keystone | 00:07 | |
| *** dims_ has quit IRC | 00:08 | |
| *** gordc has quit IRC | 00:09 | |
| *** thedodd has quit IRC | 00:11 | |
| *** david-lyle is now known as david-lyle_afk | 00:13 | |
| *** tellesnobrega has quit IRC | 00:17 | |
| *** tellesnobrega has joined #openstack-keystone | 00:30 | |
| *** NM has joined #openstack-keystone | 00:30 | |
| morganfainberg | dolphm, /me runs ./stack.sh in OS X and watches it explode | 00:48 |
| *** dims has joined #openstack-keystone | 00:49 | |
| *** stevemar has quit IRC | 00:52 | |
| *** marg7175 has quit IRC | 00:52 | |
| *** stevemar has joined #openstack-keystone | 00:52 | |
| *** ChanServ sets mode: +v stevemar | 00:52 | |
| *** gokrokve has quit IRC | 00:56 | |
| *** gokrokve has joined #openstack-keystone | 00:57 | |
| *** gokrokve has quit IRC | 00:57 | |
| *** marcoemorais has quit IRC | 01:02 | |
| *** marcoemorais has joined #openstack-keystone | 01:02 | |
| *** stevemar has quit IRC | 01:14 | |
| *** NM has quit IRC | 01:18 | |
| *** amcrn has quit IRC | 01:21 | |
| *** _cjones_ has quit IRC | 01:24 | |
| *** raildo_ has joined #openstack-keystone | 01:28 | |
| *** stevemar has joined #openstack-keystone | 01:28 | |
| *** ChanServ sets mode: +v stevemar | 01:28 | |
| *** lhcheng_ has quit IRC | 01:50 | |
| *** _sunil_ has quit IRC | 01:56 | |
| *** _sunil_ has joined #openstack-keystone | 01:56 | |
| *** dims has quit IRC | 01:58 | |
| *** _sunil_ has quit IRC | 02:01 | |
| *** zzzeek has quit IRC | 02:02 | |
| *** alex_xu has joined #openstack-keystone | 02:08 | |
| *** RichardRaseley has joined #openstack-keystone | 02:17 | |
| *** RichardRaseley has quit IRC | 02:19 | |
| *** marg7175 has joined #openstack-keystone | 02:20 | |
| *** tellesnobrega has quit IRC | 02:21 | |
| *** _sunil_ has joined #openstack-keystone | 02:27 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Remove local conf information from paste-ini https://review.openstack.org/134125 | 02:27 |
| *** gokrokve has joined #openstack-keystone | 02:29 | |
| *** sigmavirus24 has joined #openstack-keystone | 02:30 | |
| *** marcoemorais has quit IRC | 02:30 | |
| *** _sunil_ has quit IRC | 02:31 | |
| *** alex_xu has quit IRC | 02:33 | |
| *** erkules_ has joined #openstack-keystone | 02:38 | |
| *** Viswanath has joined #openstack-keystone | 02:38 | |
| *** oomichi has joined #openstack-keystone | 02:40 | |
| *** erkules has quit IRC | 02:40 | |
| *** Viswanath has quit IRC | 02:41 | |
| *** marg7175 has quit IRC | 02:45 | |
| *** marg7175 has joined #openstack-keystone | 02:45 | |
| *** marg7175 has quit IRC | 02:49 | |
| *** alex_xu has joined #openstack-keystone | 02:50 | |
| *** dims has joined #openstack-keystone | 02:51 | |
| *** raildo_ has quit IRC | 02:57 | |
| *** patrickeast has quit IRC | 02:58 | |
| *** erkules_ is now known as erkules | 02:58 | |
| *** dnalezyt has quit IRC | 02:58 | |
| *** alex_xu has quit IRC | 02:59 | |
| *** gokrokve has quit IRC | 03:00 | |
| *** gokrokve has joined #openstack-keystone | 03:00 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 03:02 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Authenticated Encryption Tokens https://review.openstack.org/130050 | 03:05 |
| *** alex_xu has joined #openstack-keystone | 03:12 | |
| *** dims has quit IRC | 03:13 | |
| *** dims has joined #openstack-keystone | 03:13 | |
| *** tellesnobrega has joined #openstack-keystone | 03:17 | |
| *** stevemar has quit IRC | 03:37 | |
| *** boris-42 has quit IRC | 03:47 | |
| *** alex_xu has quit IRC | 03:50 | |
| *** alex_xu has joined #openstack-keystone | 03:50 | |
| *** tellesnobrega has quit IRC | 03:52 | |
| *** gokrokve_ has joined #openstack-keystone | 03:52 | |
| *** tellesnobrega has joined #openstack-keystone | 03:53 | |
| *** richm1 has quit IRC | 03:53 | |
| *** gokrokve_ has quit IRC | 03:54 | |
| *** gokrokve_ has joined #openstack-keystone | 03:55 | |
| *** gokrokve has quit IRC | 03:55 | |
| *** stevemar has joined #openstack-keystone | 03:56 | |
| *** ChanServ sets mode: +v stevemar | 03:56 | |
| *** gokrokve_ has quit IRC | 03:59 | |
| *** _sunil_ has joined #openstack-keystone | 04:08 | |
| *** gokrokve has joined #openstack-keystone | 04:22 | |
| *** gokrokve has quit IRC | 04:24 | |
| *** gokrokve has joined #openstack-keystone | 04:24 | |
| *** gokrokve has quit IRC | 04:29 | |
| *** tellesnobrega has quit IRC | 04:34 | |
| *** marg7175 has joined #openstack-keystone | 04:46 | |
| *** marg7175 has quit IRC | 04:50 | |
| *** gokrokve has joined #openstack-keystone | 05:24 | |
| *** oomichi has quit IRC | 05:24 | |
| *** gokrokve has quit IRC | 05:28 | |
| *** oomichi has joined #openstack-keystone | 05:48 | |
| *** boris-42 has joined #openstack-keystone | 05:50 | |
| *** saipandi has quit IRC | 05:53 | |
| *** oomichi has quit IRC | 06:02 | |
| *** alex_xu has quit IRC | 06:05 | |
| *** oomichi has joined #openstack-keystone | 06:08 | |
| *** renlt has joined #openstack-keystone | 06:13 | |
| *** renlt has quit IRC | 06:14 | |
| *** renlt has joined #openstack-keystone | 06:14 | |
| *** renlt has quit IRC | 06:16 | |
| *** renlt has joined #openstack-keystone | 06:16 | |
| *** renlt has quit IRC | 06:16 | |
| *** renlt has joined #openstack-keystone | 06:17 | |
| *** renlt has quit IRC | 06:17 | |
| *** alex_xu has joined #openstack-keystone | 06:18 | |
| *** gokrokve has joined #openstack-keystone | 06:24 | |
| *** ajayaa has joined #openstack-keystone | 06:25 | |
| *** alex_xu has quit IRC | 06:27 | |
| *** gokrokve has quit IRC | 06:29 | |
| *** alex_xu has joined #openstack-keystone | 06:30 | |
| *** harlowja is now known as harlowja_away | 06:45 | |
| *** marg7175 has joined #openstack-keystone | 06:46 | |
| *** marg7175 has quit IRC | 06:50 | |
| *** _sunil_ has quit IRC | 06:57 | |
| *** k4n0 has joined #openstack-keystone | 06:57 | |
| *** gokrokve has joined #openstack-keystone | 07:24 | |
| *** gokrokve has quit IRC | 07:29 | |
| *** dtturner has quit IRC | 07:41 | |
| *** afazekas has joined #openstack-keystone | 07:45 | |
| *** ukalifon1 has joined #openstack-keystone | 07:50 | |
| *** _sunil_ has joined #openstack-keystone | 08:08 | |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Templated catalog backend not implemented https://review.openstack.org/120011 | 08:09 |
| *** _sunil_ has quit IRC | 08:12 | |
| *** links has joined #openstack-keystone | 08:21 | |
| *** gokrokve has joined #openstack-keystone | 08:24 | |
| *** gokrokve has quit IRC | 08:29 | |
| *** lhcheng has joined #openstack-keystone | 08:31 | |
| *** henrynash has joined #openstack-keystone | 09:05 | |
| *** ChanServ sets mode: +v henrynash | 09:05 | |
| *** alex_xu has quit IRC | 09:08 | |
| openstackgerrit | henry-nash proposed openstack/keystone: Split the assignments manager/driver. https://review.openstack.org/130954 | 09:18 |
| openstackgerrit | henry-nash proposed openstack/keystone: Split the assignments controller https://review.openstack.org/132634 | 09:19 |
| openstackgerrit | henry-nash proposed openstack/keystone: Ensure controllers and managers reference new resource manager. https://review.openstack.org/133525 | 09:19 |
| *** henrynash has quit IRC | 09:19 | |
| *** amakarov_away is now known as amakarov | 09:20 | |
| *** nirupma_ has joined #openstack-keystone | 09:22 | |
| nirupma_ | hi | 09:22 |
| *** gokrokve has joined #openstack-keystone | 09:24 | |
| *** nirupma_ has quit IRC | 09:27 | |
| *** gokrokve has quit IRC | 09:29 | |
| openstackgerrit | Endre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version https://review.openstack.org/130159 | 09:31 |
| openstackgerrit | Marcos Fermín Lobo proposed openstack/keystone: Templated catalog backend not implemented https://review.openstack.org/120011 | 09:32 |
| *** marekd|away is now known as marekd | 09:41 | |
| *** jamielennox is now known as jamielennox|away | 09:43 | |
| *** KanagarajM has joined #openstack-keystone | 09:47 | |
| *** aix has joined #openstack-keystone | 09:48 | |
| *** henrynash has joined #openstack-keystone | 09:50 | |
| *** ChanServ sets mode: +v henrynash | 09:50 | |
| *** henrynash has quit IRC | 10:02 | |
| *** tellesnobrega has joined #openstack-keystone | 10:05 | |
| *** henrynash has joined #openstack-keystone | 10:12 | |
| *** ChanServ sets mode: +v henrynash | 10:12 | |
| *** tellesnobrega has quit IRC | 10:16 | |
| *** gokrokve has joined #openstack-keystone | 10:24 | |
| *** nellysmitt has joined #openstack-keystone | 10:27 | |
| *** nirupma has joined #openstack-keystone | 10:28 | |
| nirupma | hi | 10:28 |
| *** gokrokve has quit IRC | 10:29 | |
| *** stevemar has quit IRC | 10:39 | |
| *** nirupma has quit IRC | 10:47 | |
| *** tellesnobrega has joined #openstack-keystone | 10:47 | |
| *** NM has joined #openstack-keystone | 10:51 | |
| *** tsufiev has quit IRC | 10:58 | |
| *** tellesnobrega has quit IRC | 11:10 | |
| *** raildo_ has joined #openstack-keystone | 11:22 | |
| *** aix has quit IRC | 11:23 | |
| *** gokrokve has joined #openstack-keystone | 11:24 | |
| *** gokrokve has quit IRC | 11:29 | |
| *** raildo_ has quit IRC | 11:29 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/134770 | 11:31 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/135237 | 11:31 |
| *** dims has quit IRC | 11:32 | |
| *** dims has joined #openstack-keystone | 11:32 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/pycadf: Updated from global requirements https://review.openstack.org/134789 | 11:36 |
| *** aix has joined #openstack-keystone | 11:36 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/134794 | 11:36 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-federation: Updated from global requirements https://review.openstack.org/133570 | 11:36 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient-kerberos: Updated from global requirements https://review.openstack.org/135244 | 11:36 |
| *** samuelms-away is now known as samuelms | 11:36 | |
| samuelms | henrynash, ping | 11:36 |
| henrynash | samuelms: hi | 11:42 |
| samuelms | henrynash, morning :) | 11:46 |
| henrynash | morning! | 11:46 |
| samuelms | henrynash, just saw your new patch set for ' Split the assignments manager/driver.' | 11:46 |
| samuelms | henrynash, how that deprecated_to_resource(f) wrapper works ? | 11:47 |
| henrynash | samuelms: :-) it took me a while to get it right | 11:47 |
| samuelms | henrynash, I mean, what happens when I call a method with that annotation? | 11:47 |
| henrynash | samuelms: do you understand teh concept of decorators? | 11:48 |
| samuelms | henrynash, haha and I still didnt do | 11:48 |
| samuelms | henrynash, let me remember .. 2 secs | 11:48 |
| henrynash | samuelms: don’t worry, I struggle…. | 11:48 |
| henrynash | samuelms: have a read up, then look at the wrapper itself (which is now at the top of assignment/core.py) | 11:49 |
| samuelms | henrynash, ok | 11:50 |
| henrynash | samuelms: what IS unusual about this case, is that I’m wrapping another wrapper - i.e the underlying versionutils.deprecated (which is fairly complciated, taking parms on its init and then the fucntion on the call) | 11:51 |
| samuelms | henrynash, hmm .. saw this | 11:53 |
| openstackgerrit | Dave Chen proposed openstack/keystone: Add new "RoleAssignment" exception https://review.openstack.org/133628 | 11:53 |
| samuelms | henrynash, what does versionutils.deprecated() do when called? | 11:53 |
| samuelms | henrynash, raises a warning and then execute f() ? | 11:54 |
| henrynash | samuelms: yes | 11:54 |
| samuelms | henrynash, nice ! :-) | 11:54 |
| henrynash | samuelms: ..although, as an aside, you can also cause it to throw an exception if you set CONF.fatal_depreactions to True | 11:54 |
| samuelms | henrynash, where can I set this? | 11:55 |
| henrynash | look at my test code in test_backend_sql.py - right at the end | 11:55 |
| samuelms | henrynash, self.config_fixture.config(fatal_deprecations=True) | 11:56 |
| samuelms | henrynash, cool | 11:56 |
| henrynash | samuelms: yes | 11:56 |
| samuelms | henrynash, glad to know this :-) thanks | 11:57 |
| henrynash | samulems: np | 11:57 |
| samuelms | henrynash, hmmm just looked at versionutils.deprecated | 11:59 |
| samuelms | henrynash, you wrapped the wrapper so that you don't have to repeat arguments .. | 12:00 |
| henrynash | samuelms: yep | 12:00 |
| samuelms | henrynash, nice :) | 12:00 |
| henrynash | samuelms: gotta go offline for a bit | 12:00 |
| *** henrynash has quit IRC | 12:00 | |
| *** KanagarajM has quit IRC | 12:13 | |
| *** gokrokve has joined #openstack-keystone | 12:24 | |
| *** diegows has joined #openstack-keystone | 12:25 | |
| *** gokrokve has quit IRC | 12:29 | |
| *** oomichi has quit IRC | 12:33 | |
| *** ayoung-dadmode has quit IRC | 12:42 | |
| *** alex_xu has joined #openstack-keystone | 12:44 | |
| *** k4n0 has quit IRC | 13:01 | |
| *** radez_g0n3 is now known as radez | 13:02 | |
| *** htruta has joined #openstack-keystone | 13:04 | |
| *** alex_xu has quit IRC | 13:08 | |
| *** dims has quit IRC | 13:16 | |
| *** radez is now known as radez_g0n3 | 13:16 | |
| *** dims has joined #openstack-keystone | 13:17 | |
| *** henrynash has joined #openstack-keystone | 13:17 | |
| *** ChanServ sets mode: +v henrynash | 13:17 | |
| *** alex_xu has joined #openstack-keystone | 13:22 | |
| *** gokrokve has joined #openstack-keystone | 13:23 | |
| *** topol has joined #openstack-keystone | 13:26 | |
| *** ChanServ sets mode: +v topol | 13:26 | |
| *** topol has quit IRC | 13:33 | |
| raildo | morganfainberg, https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy-improvements | 13:37 |
| *** stevemar has joined #openstack-keystone | 13:38 | |
| *** ChanServ sets mode: +v stevemar | 13:38 | |
| *** bknudson has joined #openstack-keystone | 13:41 | |
| *** ChanServ sets mode: +v bknudson | 13:41 | |
| *** gordc has joined #openstack-keystone | 13:43 | |
| *** soulxu_ has joined #openstack-keystone | 13:46 | |
| *** alex_xu has quit IRC | 13:49 | |
| *** vejdmn has joined #openstack-keystone | 13:50 | |
| *** soulxu__ has joined #openstack-keystone | 13:53 | |
| *** soulxu_ has quit IRC | 13:55 | |
| *** saipandi has joined #openstack-keystone | 13:59 | |
| openstackgerrit | Merged openstack/python-keystoneclient-kerberos: Updated from global requirements https://review.openstack.org/135244 | 14:05 |
| *** jistr has joined #openstack-keystone | 14:08 | |
| *** jistr is now known as jistr|mtgs | 14:08 | |
| *** saipandi has quit IRC | 14:11 | |
| *** soulxu_ has joined #openstack-keystone | 14:11 | |
| *** saipandi has joined #openstack-keystone | 14:11 | |
| *** soulxu__ has quit IRC | 14:15 | |
| *** soulxu__ has joined #openstack-keystone | 14:17 | |
| *** henrynash has quit IRC | 14:18 | |
| *** soulxu_ has quit IRC | 14:18 | |
| *** henrynash has joined #openstack-keystone | 14:18 | |
| *** ChanServ sets mode: +v henrynash | 14:18 | |
| *** soulxu_ has joined #openstack-keystone | 14:22 | |
| *** diegows has quit IRC | 14:23 | |
| *** diegows has joined #openstack-keystone | 14:23 | |
| *** soulxu__ has quit IRC | 14:26 | |
| *** ayoung has joined #openstack-keystone | 14:27 | |
| *** ChanServ sets mode: +v ayoung | 14:27 | |
| *** vsilva_ has joined #openstack-keystone | 14:28 | |
| *** soulxu__ has joined #openstack-keystone | 14:28 | |
| *** soulxu_ has quit IRC | 14:31 | |
| vsilva_ | ping dolphm morganfainberg marekd; I was browsing jdennis' "Alternative federation mapping" thread and wondering if anything was decided on the summit. Is there still an interest in improving our mapping capabilities? | 14:33 |
| *** soulxu_ has joined #openstack-keystone | 14:34 | |
| *** soulxu__ has quit IRC | 14:37 | |
| openstackgerrit | henry-nash proposed openstack/keystone-specs: Add support for groups of roles. https://review.openstack.org/133855 | 14:39 |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: Hierarchical Multitenancy Improvements https://review.openstack.org/135309 | 14:40 |
| raildo | henrynash, morganfainberg, ayoung ^ | 14:41 |
| *** david-lyle_afk is now known as david-lyle | 14:43 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:47 | |
| *** joesavak has joined #openstack-keystone | 14:48 | |
| samuelms | henrynash, ^ nice idea, just left a couple of comments up there | 14:49 |
| henrynash | samuelms: thx | 14:49 |
| samuelms | henrynash, when are you planning to start working on that? | 14:49 |
| marekd | vsilva_: nothing was decided. | 14:50 |
| marekd | vsilva_: that's why i am going to talk about it during todays meeting | 14:50 |
| marekd | vsilva_: what is missing from mapping engine now? | 14:50 |
| vsilva_ | yeah I saw it marekd, wanted to read up on everything that had been discussed | 14:50 |
| henrynash | samuelms: well- first we need to decide on this approach vs the a pure hieracrchical model, as mentionds by ayoung | 14:50 |
| samuelms | henrynash, would be glad if we could split some tasks | 14:50 |
| vsilva_ | I've got no complaints marekd, it's just an interesting discussion :p | 14:51 |
| henrynash | samulems: sure | 14:51 |
| ajayaa | Hi guys. When does keystonemiddleware set is_admin variable to true? | 14:51 |
| marekd | vsilva_: it is and since everybody has very own ideas i want to ask oday | 14:51 |
| marekd | today | 14:51 |
| ajayaa | I see a lot of components use this variable in their policy files. | 14:51 |
| ayoung | henrynash, so as to be clear: I only called it Hierarchical roles under duress | 14:52 |
| vsilva_ | all right marekd, I'll be there | 14:52 |
| ayoung | group roles, implies roles, dinner roles, hot cross buns | 14:52 |
| ayoung | Damnig I should have said profiteroles | 14:52 |
| henrynash | ayoung :-) | 14:52 |
| ayoung | henrynash, I think you and I were saying the same thing | 14:53 |
| henrynash | ayoung: group-profiteroles….now, we’re talking | 14:53 |
| ayoung | but it should be a DAG: one role cannot point higher up the tree | 14:53 |
| *** vsilva_ has quit IRC | 14:53 | |
| samuelms | ayoung, ++ | 14:53 |
| ayoung | henrynash, and my spec has more examples than yours | 14:53 |
| ayoung | :) | 14:53 |
| samuelms | ayoung, like .. a project admin cannot assign cloud_admin to someone,right? | 14:54 |
| henrynash | ayoung: that’s a fair point :-) | 14:54 |
| ayoung | samuelms, correct | 14:54 |
| samuelms | will take a look at adam's spec | 14:54 |
| ayoung | henrynash, I think the biggest problem with mine is the naming: we'd be fine if we were not using the term hierarchical roles for the project hierarchy | 14:55 |
| ayoung | How about I rename mine "organize roles in a DAG" | 14:55 |
| samuelms | ayoung, haha | 14:55 |
| ayoung | or Role Composition? | 14:56 |
| samuelms | ayoung, have a link for ur spec? can't find it at keystone-specs/tree/master/specs/kilo | 14:56 |
| samuelms | ayoung, role composition looks interesting, describes well what it means | 14:56 |
| ayoung | https://review.openstack.org/#/c/125704/ | 14:56 |
| samuelms | ayoung, thanks | 14:56 |
| ayoung | samuelms, I'm bascially saying the same thing as henrynash | 14:56 |
| ayoung | "For all our mutual experience, our separate conclusions are the same." | 14:57 |
| samuelms | ayoung, yes .. just saying this while reading your spec | 14:58 |
| ayoung | "Its either sadness or euphoria." --Billy Joel, from "Summer, Highland Falls" | 14:58 |
| *** nkinder has joined #openstack-keystone | 14:59 | |
| henrynash | ayoung:…. I’m not clear on is whether we really ARE saying the same thing :-) In The Henry Simple Model (THSM), there are global roles (liek today - except they are really capabilities)…and there are role-groups (or meta-roles or some other name) that, on a per domain basis, you can use to group togther and assign these global roles/capabilities | 14:59 |
| *** tsufiev has joined #openstack-keystone | 14:59 | |
| samuelms | ayoung, in order to have the same goal of henrynash's one, make 'hierarchical roles' name-spaced to domains ? | 14:59 |
| openstackgerrit | Merged openstack/pycadf: Updated from global requirements https://review.openstack.org/134789 | 14:59 |
| ayoung | henrynash, I think I took yours one step further: if you call the groups roles themselves, you can put just the group in the token, and have the policy expand them | 15:00 |
| *** ukalifon1 has quit IRC | 15:00 | |
| *** topol has joined #openstack-keystone | 15:00 | |
| *** ChanServ sets mode: +v topol | 15:00 | |
| ayoung | otherwise you need to expand on the server | 15:00 |
| henrynash | ayoung: right…I think that IS the difference | 15:00 |
| *** soulxu_ has quit IRC | 15:01 | |
| samuelms | henrynash, ayoung IMO the only difference is that group of role on THSM are a hierarchy on adam's proposal | 15:01 |
| henrynash | ayoung: and I quite liek that..we can do this within todays sandbox….no change to policy/tokens etc. | 15:01 |
| samuelms | and at THSM we have roles name-spaced to domains | 15:01 |
| *** NM has quit IRC | 15:02 | |
| henrynash | ayoung: and then expand to push the exapansion into teh policy engine... | 15:02 |
| samuelms | henrynash, ++ | 15:02 |
| henrynash | ayoung: ..althoug I admit to wantingto really understand better the aditional problems we fix by doing that | 15:02 |
| ayoung | henrynash, we can do the roles on the server side even with my proposal | 15:02 |
| dstanek | ayoung: what does step #2 mean in your blog post? | 15:02 |
| ayoung | dstanek, you mean the one labeled ??? | 15:02 |
| ayoung | ask the underpants gnomes | 15:03 |
| dstanek | ayoung: "Add to the policy library the essential code to enforce policy based on a keystone token." | 15:03 |
| ayoung | dstanek, ah | 15:03 |
| ayoung | so there is code in both Keystone and in Nova that binds the RBAC to the token | 15:03 |
| ayoung | its small | 15:03 |
| ayoung | but the big one is the "Flatten " call | 15:03 |
| henrynash | samuelms: in THSM , yes they are name-spaced by domain | 15:03 |
| ayoung | dstanek, all of the stuff inside the decorator | 15:03 |
| henrynash | samulems: they are in both proposals | 15:04 |
| *** openstackgerrit has quit IRC | 15:04 | |
| *** openstackgerrit has joined #openstack-keystone | 15:04 | |
| *** NM has joined #openstack-keystone | 15:04 | |
| samuelms | henrynash, we could use both approaches .. I mean .. using hierarchical roles inside a group of roles.. why not? | 15:04 |
| ayoung | dstanek, https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py as well as https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L52 | 15:05 |
| henrynash | samuelms: I think we need to careful of not causing our operators to jump from tall buildings to avoid their heads exploding | 15:05 |
| ayoung | henrynash, so if we distinguish between "private roles" that the policy should never see and "domain scoped roles" that just need to expand down to the basic operations, I think we will have it working | 15:06 |
| ayoung | Private roles were a one-operator request, and not something I desperately need to implement | 15:06 |
| henrynash | ayoung: ohh…I think the opposite! | 15:07 |
| henrynash | ayoung: domain scoped roles are never seen by policy | 15:07 |
| henrynash | ayoung: in my model | 15:07 |
| ayoung | henrynash, so long as they resolve down to the base operations, that will work | 15:07 |
| henrynash | ayoung: domain-scoped rolegroups are never seen by policy, to be accurate | 15:07 |
| henrynash | ayoung: agreed | 15:08 |
| *** radez_g0n3 is now known as radez | 15:08 | |
| ayoung | henrynash, I'd almost want to rename roles, then. Yours are truely the "roles" and what we have today are intermediate-reusabe-lists-of-capabilities | 15:09 |
| henrynash | ayoung: yeah, I agree | 15:09 |
| henrynash | ayoung: absolutely | 15:09 |
| samuelms | henrynash, once we have reseller, they'll need to have their own policies, right? so they'd be able to define and use their own domain-scoped rolegroups | 15:09 |
| dstanek | ayoung: have you seen this? http://engineering.utsa.edu/~krishnan/conferences/mmmacns2012.pdf | 15:09 |
| ayoung | samuelms, they don't get their own policy, they get their own roles | 15:09 |
| ayoung | dstanek, looking | 15:10 |
| samuelms | ayoung, in this case .. a human won't be able to understand the policy file itself, right? | 15:10 |
| ayoung | dstanek, here's how I explain it: ABAC is the mechanism. RBAC is an engineering effort to manage the attributes | 15:11 |
| samuelms | ayoung, we should have an api to define policy constraints, right? | 15:11 |
| samuelms | ayoung, without needing to edit the file by hand | 15:11 |
| ayoung | samuelms, I wrote up a unified vision | 15:11 |
| ayoung | on sec | 15:11 |
| samuelms | sure | 15:11 |
| dstanek | ayoung: i also notice a related post this morning on the openstack-dev mailing list | 15:12 |
| ayoung | samuelms, http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ | 15:12 |
| ayoung | samuelms, so In the last couple of steps: | 15:12 |
| ayoung | 7. Use the hierarchical role definitions to generate the rules for the file above. | 15:12 |
| samuelms | ayoung, looks interesting | 15:14 |
| ayoung | samuelms, so I had originally written it like henrynash 's approach, and several people pointed out it should be enforced on the policy side. I think we have to think about how much data we want to pass, and what should be in the token. I think it should be our goal that a token only ever holds a single role | 15:15 |
| ayoung | and, in fact, a user should only ever be assigned a single role | 15:15 |
| ayoung | but they can break that into finer grained roles for delegation | 15:16 |
| *** bknudson has quit IRC | 15:16 | |
| ayoung | dstanek, you mean Ioram's work with davidchadwick? Yes, my writeup grew out of some of those discussions | 15:17 |
| dstanek | ayoung: yes, sounds like they are already building something | 15:17 |
| henrynash | ayoung: my concern is that checking permission on an API becomes a pretty intensive opertion, since in theory it would have to exceute an aribratary complexe set of domain-scpecifc hirerarcical calulcations… | 15:18 |
| dstanek | ayoung: so if your vision to eventually read all policy from the database? | 15:18 |
| ayoung | dstanek, my goal is to get them directed up front, unlike the Federation approach that took years to merge in view-point | 15:18 |
| henrynash | ayoung: and token issuance happens several orders of magnitude less than toen checking | 15:18 |
| ayoung | henrynash, nah...its actually pretty easy | 15:18 |
| henrynash | token checking | 15:18 |
| ayoung | henrynash role expansion happens in the policy file like this: | 15:18 |
| ayoung | say the api is...compute:reboot_vm | 15:19 |
| ayoung | and to do that you need the "writer role" which is under "member" which is under admin | 15:19 |
| ayoung | the rule would be | 15:19 |
| ayoung | damnit, I didn't put the links in my article...need to update | 15:20 |
| dstanek | ayoung: does that mean stacked files or database rows for policy? | 15:20 |
| ayoung | dstanek, 1 sec | 15:20 |
| ayoung | "compute:v3:servers:start": "rule:ROLE_MEMBER", | 15:21 |
| henrynash | ayoung: I guess my argument is simpler…..I need to udnerstand teh real BIG problem we are solving by putting all the work in the palce that is executed many orders of magnitude more often | 15:21 |
| ayoung | and ROLE_MEMBER expands to | 15:21 |
| samuelms | ayoung, so that when generating the policy file from db schema .. you expand the hierarchical roles ? | 15:21 |
| ayoung | "(role:admin or role:member) and project_id:%(project_id)s" | 15:21 |
| samuelms | henrynash, ^ | 15:22 |
| samuelms | don't we expand the hierarchical roles when generating the policy files from db schema? | 15:23 |
| *** NM has quit IRC | 15:23 | |
| samuelms | if we shouldn't, I agree with you . | 15:23 |
| lhcheng | hi folks, I plan to work on a reported bug, but before I start it would be great if someone else can confirm that it is indeed a bug: https://bugs.launchpad.net/keystone/+bug/1393518 - just to be sure I am going to work on a valid bug :) | 15:24 |
| uvirtbot | Launchpad bug 1393518 in keystone "v3 service catalog returns services without names, but v2.0 api does not" [Undecided,New] | 15:24 |
| *** ajayaa has quit IRC | 15:25 | |
| *** NM has joined #openstack-keystone | 15:26 | |
| samuelms | henrynash, and if we expand the role hierarchy when checking permission (service side) .. we have a problem of consistence when we update the role hierarchy | 15:26 |
| samuelms | think I got your point | 15:26 |
| samuelms | have to go now .. back in few minutes .. | 15:29 |
| *** samuelms is now known as samuelms-away | 15:29 | |
| *** marg7175 has joined #openstack-keystone | 15:32 | |
| *** bknudson has joined #openstack-keystone | 15:35 | |
| *** ChanServ sets mode: +v bknudson | 15:35 | |
| *** saipandi has quit IRC | 15:36 | |
| ayoung | henrynash, well, token size was one consideration | 15:37 |
| ayoung | henrynash, but the ability to manage the policy files, and make things grow is probably the more important one | 15:38 |
| henrynash | ayoung: token size is of course and issue, but wouln’t think that a role name list would be the killer | 15:41 |
| henrynash | ayoung: so agreed that it is more the second issue.. | 15:41 |
| ayoung | henrynash, We're trying to get things down to 150 bytes | 15:41 |
| ayoung | and if we need to put every expanded role into the token, it will be an issue | 15:42 |
| ayoung | a token should have a single role in it...a token should not have any data that cannot be cached on the server side, excpet that which is specific to the user | 15:42 |
| henrynash | ayoung: that’s one view | 15:42 |
| henrynash | ayoung: not sure I agree | 15:42 |
| ayoung | it is the view I've had crammed down my throat.... | 15:43 |
| ayoung | its what is making it difficult to use PKI tokens today | 15:43 |
| ayoung | henrynash, OK, so I understand the goal of the private roles. | 15:43 |
| henrynash | ayoung: why doesn’t a small token ID that indexes a pre-calcualted set of roles give you teh same result…and keep the processing in the more appropriate place? | 15:44 |
| ayoung | henrynash, that is what hierarchical roles are... | 15:44 |
| henrynash | ayoung: I don’t see the conection between small token size and shift the calcualtion to the policy engine | 15:44 |
| ayoung | if I give your "role_groupid="1234abcd" | 15:44 |
| ayoung | that is the same as saying role with id 1234abcd expands to ccddeef12 and aaddaa112 | 15:45 |
| ayoung | so yes... | 15:45 |
| ayoung | a single ID which gets expanded on the server side based on cached data is exactly what I am shooting for | 15:45 |
| ayoung | "a pre-calcualted set of roles" | 15:46 |
| henrynash | ayoung: so why do we need to caneg the policy engine? | 15:46 |
| ayoung | caneg is just good fun | 15:47 |
| henrynash | ayoung: :-) | 15:47 |
| ayoung | the policy engine stays unchaged. What I am saying is change the policy generation | 15:47 |
| henrynash | ayoung: why chaneg that? | 15:47 |
| ayoung | to avoid having to have a magic step in between | 15:47 |
| ayoung | cuz if we cahce on the server side, sometihng would need to expand that | 15:47 |
| henrynash | ayoung: well, read it | 15:48 |
| henrynash | ayoung: so to play devils advocate..... | 15:48 |
| ayoung | I hope4 you got a hefty retainer | 15:48 |
| ayoung | he's a bastard of a client | 15:48 |
| henrynash | ayoung: you calucalate all your list or roles/capabilities at the point of token issuance, write it to the Keystone token table… and issue a shrt token ID | 15:49 |
| henrynash | ayoung: sounds familiar ! | 15:49 |
| *** afazekas has quit IRC | 15:49 | |
| ayoung | I thought we were doing away with the token table | 15:50 |
| *** dtturner has joined #openstack-keystone | 15:50 | |
| ayoung | that is the whole point of ae tokens | 15:50 |
| henrynash | ayoung: OK, call it teh token cache | 15:50 |
| *** NM has quit IRC | 15:50 | |
| henrynash | ayoung: no used fo revocations! | 15:50 |
| henrynash | ayoung: would taht be better than recalulating everying every time we have to check a token? | 15:51 |
| ayoung | no...the recalculation is cheap | 15:51 |
| openstackgerrit | werner mendizabal proposed openstack/keystone-specs: Multifactor Authentication https://review.openstack.org/130376 | 15:52 |
| *** NM has joined #openstack-keystone | 15:52 | |
| ayoung | henrynash, I want to avoid going back to keystone. You know that. Anything that ties to more calls back to Keystone is a step backwards | 15:53 |
| henrynash | ayoung: maybe, maybe not…it’s about getting teh right balance that meets the performance nad flexibility profile we are aiming the keystone at | 15:54 |
| ayoung | yep | 15:54 |
| ayoung | henrynash, I'm far less concerned about the "private roles" than I am about fixing "admin is everything" | 15:55 |
| ayoung | henrynash, if a token only had a role id, and that was expanded on the server side, would that be an acceptable solution to the groups/private roles? | 15:55 |
| *** jorge_munoz has quit IRC | 15:56 | |
| henrynash | ayoung: and what is the server in this? Keystone? some other server runnign policy…I’m really unsure how much you are tearing up here | 15:57 |
| ayoung | other server | 15:57 |
| ayoung | henrynash, say the token just had | 15:57 |
| ayoung | role_id="<uuid>" | 15:57 |
| ayoung | then the server expaneded that out with implied roles | 15:58 |
| ayoung | s!server!middleware.auth_token! | 15:58 |
| ayoung | if we are shooting for id only tokens anyway, and we want to minimize token size, then that is the right balance. | 15:59 |
| ayoung | the issue with private roles is there is no way today to say "this role that I just defined should be able to perform operations X,y, and z | 15:59 |
| ayoung | " | 15:59 |
| ayoung | without changing the policy files, your proposal has no path to implementation | 16:00 |
| dstanek | do we have a plan for removing the extra? i remember the discussion, just not the outcome /cc morganfainberg | 16:00 |
| henrynash | ayoung: i don’t udneratnd | 16:00 |
| morganfainberg | dstanek: well. No no plan :(. I do want it to go away. | 16:00 |
| henrynash | ayoung: you mean with my proposal AND just an id in the token, there is no path to implemnation | 16:00 |
| *** jorge_munoz has joined #openstack-keystone | 16:00 | |
| *** marg7175 has quit IRC | 16:01 | |
| dstanek | morganfainberg: can we break API compatibility for it or do we have to allow the extra data in? i don't think it's actually documented in most cases, but it behaves that way | 16:01 |
| dstanek | morganfainberg: this made me think of it: https://review.openstack.org/#/c/129830/ | 16:02 |
| *** marg7175 has joined #openstack-keystone | 16:02 | |
| morganfainberg | I think we need to have a "no extras" option for strict api enforcement. | 16:02 |
| morganfainberg | But I know deployers use it. So we can't outright break it. | 16:03 |
| henrynash | ayoung: what I am proposing is totally implemenatble without changing policy (assuming any one of our existing token formats can be used)….and that’s why I like it…incremental implementaion, while delivering a feature in Kilo | 16:03 |
| *** KanagarajM has joined #openstack-keystone | 16:05 | |
| openstackgerrit | Merged openstack/keystonemiddleware: Updated from global requirements https://review.openstack.org/135237 | 16:08 |
| *** agireud has joined #openstack-keystone | 16:10 | |
| *** KanagarajM has quit IRC | 16:12 | |
| ayoung | henrynash, no, you need my stuff to make yours viable | 16:12 |
| ayoung | henrynash, yes, you could make a private role to a domain with yours | 16:12 |
| ayoung | buyt it would default to be "member" | 16:12 |
| ayoung | henrynash, ok...lets take it from the bottom | 16:13 |
| ayoung | here is the nova policy file.... | 16:13 |
| ayoung | http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json | 16:13 |
| *** lhcheng_ has joined #openstack-keystone | 16:13 | |
| ayoung | there are three classes of API: ones that are admin, ones that have "admin_or_owner" and ones that are "" or no enforcment | 16:14 |
| ayoung | now, "admin_or_owner" actually is defined differently in Keystone | 16:14 |
| *** esmute has quit IRC | 16:14 | |
| henrynash | ayoung: ok | 16:15 |
| ayoung | http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.json#n6 | 16:15 |
| ayoung | so keystone "owner" means "I own it" | 16:15 |
| ayoung | in nova "owner" means "user has any role on the project" | 16:15 |
| ayoung | http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json#n3 | 16:15 |
| ayoung | so...lets say that "any role" is kindof useless, right? Replace it with "Member" | 16:16 |
| ayoung | the lowest level role we have, and make admin encapsulate member | 16:16 |
| *** lhcheng has quit IRC | 16:16 | |
| ayoung | You want to create a project specific role, you still need to enforce what that role can do | 16:16 |
| ayoung | now, lets go to extremes for am moment | 16:17 |
| ayoung | lets say that every API is its own role | 16:17 |
| ayoung | so that we can separately assign them | 16:17 |
| *** NM has quit IRC | 16:17 | |
| henrynash | ayoung: so noting I’ve seen yet makes we want to change anything we’re doing | 16:17 |
| *** esmute has joined #openstack-keystone | 16:17 | |
| henrynash | ayoung: I’m clearly not seeing the problem | 16:17 |
| ayoung | now a domain private role could be defined as a collection like "compute_extension:admin_actions:pause" "compute_extension:admin_actions:unpause" .... | 16:17 |
| *** samuelms-away is now known as samuelms | 16:17 | |
| ayoung | henrynash, why do you want domain private roles | 16:18 |
| ayoung | ? | 16:18 |
| henrynash | ayoung: so I a domain can name some collection of capabilities that are meaningful to them | 16:18 |
| ayoung | henrynash, that is my point. You cannot do that without changing the policy file. | 16:19 |
| samuelms | when centralizing the policies .. when do policies become invalid? | 16:19 |
| *** zzzeek has joined #openstack-keystone | 16:19 | |
| samuelms | ayoung, ^ | 16:19 |
| henrynash | ayoung: I don’t see that leap | 16:19 |
| ayoung | henrynash, give me an example of what you want to do | 16:19 |
| ayoung | henrynash, put another way "role groups are meaningless if roles are meaningless" | 16:20 |
| ayoung | today, at least in nova, roles themselves are meaningless | 16:20 |
| *** NM has joined #openstack-keystone | 16:20 | |
| ayoung | admin is not scoped, and member is ignored. all that matters is that the user has some role | 16:20 |
| ayoung | what roles would be in your group? | 16:21 |
| henrynash | ayoung: OK, In my company, the job of vm administrator on a poject means they can create/delete/stop/start a vm | 16:21 |
| ayoung | henrynash, so you need a policy file change to make that happen | 16:21 |
| ayoung | henrynash, those APIs are here: http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json#n32 | 16:22 |
| ayoung | and the policy to enforce them is | 16:22 |
| rodrigods | is it to ugly to copy the get_auth_context method from auth.controllers to assignment.controller? (want to get the user_id making the call, so I can filter the subtree/parents to be returned) | 16:22 |
| ayoung | "rule:admin_or_owner", | 16:22 |
| ayoung | there is no way to say "a user can only create/delete/stop/start a vm" | 16:22 |
| henrynash | ayoung: OK, so let me be a bit more specific. For a GIVEN set of capabilities I want, in an orgainzation, I woudl expect the policy file to have exactly the same form as it does today, but to have more roles atatched to individual APIs (the capabilities_ | 16:22 |
| henrynash | ayoung: sure…I’m not saying don;t change the roles in apolicy file…I’m saying don’t chaneg the fucntionality we have today in policy | 16:23 |
| ayoung | henrynash, to what granularity? With out one role per capability, you can't do that "on the fly" | 16:23 |
| henrynash | ayoung: I;m not saying you should | 16:23 |
| ayoung | henrynash, if you are saying "domain specific roles" then you are | 16:24 |
| samuelms | henrynash, ayoung I think a possible solution would be: 1) expand role hierarchy when generating the policy to deliver it to a service | 16:24 |
| *** lihkin has joined #openstack-keystone | 16:24 | |
| ayoung | samuelms, YES! | 16:24 |
| samuelms | henrynash, ayoung 2) if the role hierarchy has changed .. invalidate the policy | 16:24 |
| samuelms | and make the service get it again | 16:24 |
| henrynash | ayoung: they ARE created on-the-fly, but can only refernce teh capabilities (nee roles) that are defined in policy fules | 16:24 |
| ayoung | henrynash, and we don't have a way to know what those are today | 16:25 |
| samuelms | what about this ^? | 16:25 |
| ayoung | hence the centralization of management | 16:25 |
| henrynash | ayoung: there the roles! | 16:25 |
| ayoung | so we start by getting an inventory of the capabilites | 16:25 |
| henrynash | ayoung: they’re the roles! | 16:25 |
| henrynash | ayoung: list_roles() | 16:25 |
| samuelms | I think this solution above match requirements from you both | 16:25 |
| ayoung | henrynash, tongiht, at a bout 3 AM, you are going to wake from a deep sleep and realize...Oh, that is what he meant...of course. | 16:26 |
| ayoung | Then you will roll over with a smile on your face, and tomorrow we'll file off the rought edges | 16:26 |
| samuelms | no increase of load at service side when evaluating permissions ^ | 16:26 |
| ayoung | samuelms, ok, so that is in my spec | 16:26 |
| henrynash | ayoung: so I do actually udnerstand what you are proposing…I’m jsut not convinced we need it and think we can get 80% of what we need by taking a simpler, caompatible with what we have today, approach | 16:26 |
| ayoung | samuelms, https://review.openstack.org/#/c/125704/7/specs/kilo/hierarchical-roles.rst line 146 | 16:27 |
| ayoung | henrynash, what I laid out was a step by step. Each of the earlier step needs to be done before the later steps. We get that as far as we can | 16:28 |
| ayoung | I don't think we can really affect policy without central management] | 16:28 |
| ayoung | expanding the data in the token is, of course, possible today | 16:28 |
| henrynash | ayoung: ahh, what you laid out was a set of thinsg to do…my big issue is that we ahve not started with the problmes we are trying to solve and described why alternative solutions are not better | 16:28 |
| openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: Hierarchical Multitenancy Improvements https://review.openstack.org/135309 | 16:29 |
| ayoung | henrynash, I'm trying to fix one of the oldest bugs in the bug tracker: https://bugs.launchpad.net/keystone/+bug/968696 without the steps I laid out, there is no hope for that | 16:29 |
| uvirtbot | Launchpad bug 968696 in keystone ""admin"-ness not properly scoped" [High,Confirmed] | 16:29 |
| henrynash | ayoung: which customers are askingh for this, and waht exactly are they asking for, and why are other incremental approaches insufficient | 16:30 |
| ayoung | henrynash, I'm sorry, I'm not authorized to share my customer list with you. :) | 16:30 |
| henrynash | ayoung: the bug you refence can simply be solved by not naming the super user ‘admin’ in every policy file. whynot just change that? | 16:31 |
| ayoung | henrynash, that question is Rhetorical, right? Like "Why haven't we replaced the policy.json file with Henry's cloud sample?" | 16:32 |
| ayoung | We can't just change policy because it then gets out of sync with the policy as shipped by each project, and we have no way of merging | 16:33 |
| henrynash | ayoung: (i know I am being facetious now)..but my big concern and twitchyness is that I don;t beleiev we have described why the simple solutions aren;t sufficent | 16:33 |
| henrynash | ayoung: ..because I haven’t spent teh time doing that…someone has patch out that is close o do that | 16:33 |
| ayoung | henrynash, OK. Problem one: if we change the default policy we break everyone out there that is built on default policy | 16:33 |
| *** gokrokve_ has joined #openstack-keystone | 16:34 | |
| ayoung | problem2: Admin is definied as having the admin role on any project, and that antipattern has been copied-and-pasted to each of the projects | 16:34 |
| ayoung | problem 3: We have 3 different delegation mechanism, and the primary one (role assignements) loses the chain of who-assigned-what | 16:34 |
| ayoung | and, in addition, there is no limitation on who-can-assign-what | 16:34 |
| henrynash | ayoung: …but who says we solve thee problems with code….why don;t we jsut work to change those policy files? | 16:35 |
| samuelms | ayoung, henrynash problem2 : we're working on a policy.v3cloudsample like for each service :) | 16:35 |
| *** KanagarajM has joined #openstack-keystone | 16:35 | |
| henrynash | samuelms: sounds good | 16:35 |
| ayoung | henrynash, "cut and paste" is not a good strategy. It was bad for Oslo and it is bad for policy | 16:36 |
| ayoung | And each of the policy files have a stanza at the top that define their rules | 16:36 |
| ayoung | but those definitions are different for each service | 16:36 |
| samuelms | henrynash, for keystone : https://review.openstack.org/#/c/123509/ | 16:36 |
| samuelms | henrynash, as an example .. | 16:36 |
| henrynash | ayoung: I don’t see it as conceptually cut and paste….I see it as we want each service to defince their own plicy as they see fit] | 16:36 |
| ayoung | henrynash, have you actually looked at the other policy files? | 16:37 |
| samuelms | henrynash, we have proposed that for all services .. spliting admin global role into cloud_admin, domain_admin and project_admin | 16:37 |
| ayoung | its cut and paste | 16:37 |
| *** gokrokve has quit IRC | 16:37 | |
| *** gsilvis has quit IRC | 16:37 | |
| ayoung | http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json | 16:37 |
| henrynash | ayoung: that’s how they did it…but don’t we WANT them to have theor own policy, however they chose to get ity? | 16:37 |
| *** agireud has quit IRC | 16:38 | |
| ayoung | henrynash, who should control policy? The Neutron devs upstream, or the people deploying things in their own datacenters? | 16:38 |
| *** thedodd has joined #openstack-keystone | 16:38 | |
| *** gokrokve_ has quit IRC | 16:38 | |
| ayoung | http://git.openstack.org/cgit/openstack/glance/tree/etc/policy.json actually got me to laugh | 16:39 |
| ayoung | http://git.openstack.org/cgit/openstack/cinder/tree/etc/cinder/policy.json | 16:40 |
| henrynash | ayoung: just becasue we give out bad policy samples, doesn’t mean the approach we have won’t work for customers | 16:40 |
| bknudson | ayoung: check the ceilometer one. | 16:40 |
| ayoung | henrynash, looking | 16:40 |
| bknudson | http://git.openstack.org/cgit/openstack/ceilometer/tree/etc/ceilometer/policy.json | 16:40 |
| ayoung | Nice! | 16:41 |
| bknudson | it's short | 16:41 |
| ayoung | bknudson with the zinger | 16:41 |
| samuelms | ayoung, we're proposing this to glance (https://review.openstack.org/#/c/123216/7/etc/policy.cloudsample.json) | 16:41 |
| samuelms | ayoung, stop laughing .. :P | 16:41 |
| ayoung | http://git.openstack.org/cgit/openstack/sahara/tree/etc/sahara/policy.json | 16:42 |
| ayoung | samuelms, nah | 16:42 |
| ayoung | samuelms, first off, create a short rule for each | 16:43 |
| ayoung | avoid all the duplication | 16:43 |
| ayoung | rule:is_cloud_admin or rule:is_project_admin or rule:is_project_member could be | 16:43 |
| ayoung | RULE:MEMBER = rule:is_cloud_admin or rule:is_project_admin or rule:is_project_member | 16:43 |
| *** _cjones_ has joined #openstack-keystone | 16:44 | |
| samuelms | ayoung, but we may have different types of members .. | 16:44 |
| samuelms | ayoung, RULE:MEMBER_1, RULE:MEMBER_2 ... | 16:44 |
| ayoung | samuelms, all of those rules have the same code in them | 16:44 |
| samuelms | ayoung, will think about .. looks like policy would become clearer | 16:44 |
| ayoung | instead o MEMBER_! etc | 16:44 |
| samuelms | hmm .. | 16:45 |
| ayoung | OPK..so this is exactly what I was trying to solve | 16:45 |
| ayoung | first we get an inventory of the places where we enforce policy (call them the PEPs for policy enforcement points) | 16:45 |
| ayoung | so | 16:45 |
| ayoung | add_member is one | 16:46 |
| samuelms | the services .. | 16:46 |
| samuelms | = PEPs right | 16:46 |
| samuelms | ? | 16:46 |
| ayoung | the enpoints have multiple PEPs...really I am talking the APIs | 16:46 |
| ayoung | but the point in the code that calls "enforce_policy" | 16:46 |
| samuelms | ok | 16:46 |
| ayoung | samuelms, if Keystone knows about them, you can do soemthing like this: | 16:47 |
| ayoung | change "add_image": "rule:is_cloud_admin or rule:is_project_admin or rule:is_project_member", | 16:47 |
| ayoung | to | 16:47 |
| ayoung | change "add_image": "project_id= {%project_id} and role:member", | 16:48 |
| ayoung | samuelms, right now, your policy does not enforce that the user has the role *ON THE PROJECT* | 16:48 |
| samuelms | ayoung, right | 16:49 |
| samuelms | ayoung, that's what the 'project_id= {%project_id}' thing does .. | 16:49 |
| ayoung | samuelms, so, in the future, if we want to split member into reader and writer, we say member inherits reader and member inherits writer | 16:49 |
| ayoung | or we say writer inherits reader and member inherits writer | 16:50 |
| samuelms | ayoung, makes sense | 16:50 |
| ayoung | then we update the rules for the APIs to the more specific roles | 16:50 |
| ayoung | so, yes, henrynash we can do all of this outside of Keystone, with a management tool to generate the policy files | 16:50 |
| *** agireud has joined #openstack-keystone | 16:51 | |
| samuelms | ayoung, cloud_admin inherits from domain_admin which in turn inherits from project_admin | 16:52 |
| samuelms | ayoung, in our case | 16:52 |
| samuelms | ayoung, I'll review your spec more carefully .. looks an interesting idea :) | 16:54 |
| ayoung | samuelms, "Big fleas have little fleas, | 16:54 |
| ayoung | Upon their backs to bite 'em, | 16:54 |
| ayoung | And little fleas have lesser fleas, | 16:54 |
| ayoung | and so, ad infinitum." | 16:54 |
| samuelms | ayoung, haha nice comparison | 16:54 |
| ayoung | http://en.wikipedia.org/wiki/The_Siphonaptera | 16:55 |
| samuelms | ayoung, henrynash, bknudson as I said, we're proposing policies for some services (links can be found at http://paste.openstack.org/show/134439/) | 16:56 |
| samuelms | I'd be glad to have your review up there :D | 16:56 |
| ayoung | henrynash, OK...so...all that argument aside, I don't think our proposals are in conflict | 16:56 |
| bknudson | give them the same topic or changeid and you don't need a paste for it. | 16:56 |
| ayoung | Groups would stay server side, and would be private | 16:56 |
| samuelms | bknudson, didn't know we could have the same change-id for different patches .. :p | 16:57 |
| bknudson | they're in different projects | 16:57 |
| samuelms | bknudson, yes | 16:57 |
| bknudson | so they can have the same change-id | 16:57 |
| samuelms | bknudson, cool ... using the same topic is also a good human-readable idea :) | 16:58 |
| ayoung | bknudson, how/where do you set topic | 16:58 |
| samuelms | bknudson, will ask my workmate to do this | 16:58 |
| bknudson | you can set the --topic on git-review | 16:58 |
| bknudson | the topic defaults to the branch name | 16:58 |
| bknudson | also, I think you can change the topic right in the gerrit interface | 16:59 |
| samuelms | bknudson, yes .. we can using the ui | 16:59 |
| *** r-daneel has joined #openstack-keystone | 17:03 | |
| *** r-daneel has quit IRC | 17:04 | |
| *** thedodd has quit IRC | 17:05 | |
| *** r-daneel has joined #openstack-keystone | 17:05 | |
| *** r-daneel has quit IRC | 17:07 | |
| ayoung | samuelms, Also, make sure you run from Horizon using the policy files. | 17:07 |
| *** r-daneel has joined #openstack-keystone | 17:07 | |
| ayoung | We had some issues with the cloud_sample...namely that Horizon then could not do domain scoped operations | 17:07 |
| henrynash | ayoung: so agreed…they are not in conflict…yours is a super set, which includes changing where the expansion of domain-specifc-roley-thingies happens | 17:09 |
| samuelms | ayoung, yes .. we have that in mind | 17:10 |
| samuelms | ayoung, as for now, we solved that putting the cloud admin on the project admin of the default domain .. | 17:10 |
| samuelms | ayoung, using devstack .. | 17:11 |
| *** gokrokve has joined #openstack-keystone | 17:11 | |
| henrynash | morganfainberg, stevemar: I think we may be ready again to consider approving: https://review.openstack.org/#/c/130954 | 17:11 |
| *** r-daneel has quit IRC | 17:11 | |
| samuelms | ayoung, all those feedbacks are important .. will forward them to the team working on that .. | 17:11 |
| samuelms | afaranha ^ | 17:12 |
| morganfainberg | henrynash: great | 17:14 |
| * morganfainberg drinks morning coffee | 17:14 | |
| morganfainberg | Ahhhhhh French press is the best way to enjoy coffee. | 17:14 |
| *** marcoemorais has joined #openstack-keystone | 17:15 | |
| dolphm | thems be fightin words, son | 17:15 |
| stevemar | mcdonalds mccafe beats everything | 17:16 |
| stevemar | henrynash, reviewing now | 17:16 |
| stevemar | marekd, alive? | 17:16 |
| marekd | stevemar: yep | 17:16 |
| marekd | stevemar: what's up, sir? | 17:16 |
| samuelms | bknudson, https://review.openstack.org/#/q/status:open+branch:master+topic:bp/policy-sample,n,z | 17:17 |
| marekd | BTW: the meeting starts in ~45 minutes, right? | 17:17 |
| bknudson | samuelms: nice! | 17:17 |
| stevemar | marekd, in the cernops patches, how do y'all get a project scoped token to return to the client in the websso flow | 17:17 |
| stevemar | marekd, yes, 45 mins | 17:17 |
| *** m7m88 has joined #openstack-keystone | 17:18 | |
| marekd | stevemar: afair this was pretty standard horizon procedure | 17:18 |
| marekd | stevemar: the problem was with transporting the *unscoped* token to horizon | 17:18 |
| ayoung | dolphm, did you get a chance to read the policy overview? Is this roughly what you were thinking? | 17:18 |
| dolphm | ayoung: only read partially so far, hoping to finish before the meeting | 17:19 |
| ayoung | dolphm, cool | 17:19 |
| *** m7m88 has quit IRC | 17:19 | |
| *** marg7175 has quit IRC | 17:22 | |
| marekd | stevemar: did it answer your question? | 17:23 |
| morganfainberg | ayoung: read the post. Still digesting it some. | 17:24 |
| ayoung | morganfainberg, thanks. Should I add it to the agenda? | 17:24 |
| *** lihkin has quit IRC | 17:25 | |
| *** marg7175 has joined #openstack-keystone | 17:25 | |
| morganfainberg | I think that was the longer term direction we were aiming for. Fairly well lined up with the summit discussions with minor differences (eg henrynash 's grouping was the first pass to get us headed the right way) | 17:25 |
| *** lihkin has joined #openstack-keystone | 17:25 | |
| morganfainberg | It bought us base functionality that was needed without hindering progression to the end goal. | 17:26 |
| henrynash | morganfainberg: agreed | 17:26 |
| ayoung | morganfainberg, I think groups (server side) and hierarchical (policy side) can co-exist. The server side ones could be done client side in the future if we decide to optimize that way | 17:27 |
| morganfainberg | You can add it to the agenda of you want more discussion on it. | 17:27 |
| ayoung | cool | 17:27 |
| morganfainberg | ayoung: absolutely. | 17:27 |
| morganfainberg | ayoung: the grouping was a low cost that addressed a major complaint today without needing a ton of extra work. Basically gets us pointed in the right direction. And if we miss the hierarchical roles in kilo we have some basic stuff satisfied this cycle. They should def coexist as you described long term. | 17:28 |
| ayoung | OK, added it to the end. | 17:29 |
| *** _sunil_ has joined #openstack-keystone | 17:32 | |
| *** _sunil_ has quit IRC | 17:32 | |
| morganfainberg | dolphm: ok so French press is out for you? What is your preferred mode off caffienation w/ coffee? | 17:32 |
| dolphm | morganfainberg: not out for me at all, but if i have really good beans, i stick with a chemex | 17:32 |
| morganfainberg | Ah chemex is good. My #1 choice is café in Europe. But uh. I'm in SoCal :P | 17:33 |
| marekd | what's chemex? | 17:34 |
| morganfainberg | Also ayoung 's disappointment at the "un café" at the summit still amuses me ;) (sorry Adam) | 17:34 |
| marekd | a coffee brand? | 17:34 |
| ayoung | a volume | 17:34 |
| ayoung | roughly comparable to a thimble | 17:35 |
| morganfainberg | marekd: a device for doing coffee as a pour-over | 17:35 |
| dolphm | marekd: http://www.chemexcoffeemaker.com/ | 17:35 |
| morganfainberg | dolphm: beat me to it | 17:35 |
| marekd | ++ | 17:35 |
| morganfainberg | Pour over is great. | 17:36 |
| marekd | morganfainberg: i like mokkas | 17:37 |
| dolphm | and cheap compared to a lot of other systems | 17:38 |
| *** links has quit IRC | 17:38 | |
| morganfainberg | marekd aha! I was trying to figure out what that was called! Those are awesome too. | 17:39 |
| dolphm | ooh this is something i've seen, but never heard the name of until now http://en.wikipedia.org/wiki/Moka_pot | 17:39 |
| marekd | morganfainberg: there is nothing like a cup of italian coffee from moka | 17:40 |
| morganfainberg | marekd: yeah those are on my short list of "I need one". | 17:40 |
| ayoung | I thought that was called a Percolator? I have one for camping | 17:40 |
| dolphm | morganfainberg: if your "i need one" list is short, then you clearly don't spend enough time on the internet | 17:41 |
| marekd | :D :D :D | 17:41 |
| morganfainberg | ayoung: mokka is espresso not percolator | 17:41 |
| ayoung | what is the difference between Moka and http://en.wikipedia.org/wiki/Coffee_percolator | 17:41 |
| morganfainberg | ayoung: pressure forcing water through the beans like an espresso machine does. | 17:42 |
| morganfainberg | Vs drip through the filter | 17:42 |
| ayoung | Ah...from the bottom up...I see | 17:42 |
| dolphm | ayoung: percolator http://en.wikipedia.org/wiki/Coffee_percolator#mediaviewer/File:Coffee_Percolator_Cutaway_Diagram.svg | 17:42 |
| dolphm | ayoung: moka http://en.wikipedia.org/wiki/Moka_pot#mediaviewer/File:Moka_Animation.gif | 17:42 |
| morganfainberg | dolphm: my "must have" list is short. Or I'd be broke. | 17:42 |
| dolphm | the moka has a super elegant design | 17:43 |
| ayoung | I know they make a camping version of that | 17:43 |
| ayoung | http://farm8.staticflickr.com/7162/6626256185_cbf55955e3_b.jpg | 17:43 |
| *** marcoemorais has quit IRC | 17:44 | |
| dolphm | what is that | 17:44 |
| *** marcoemorais has joined #openstack-keystone | 17:44 | |
| ayoung | Same idea as the Moka, but for camping | 17:44 |
| lhcheng_ | morganfainberg: I am planning to work on a keystone bug, but before I start would be great if someone can confirm if it is indeed a bug. :) Here's the link: https://bugs.launchpad.net/keystone/+bug/1393518 | 17:44 |
| uvirtbot | Launchpad bug 1393518 in keystone "v3 service catalog returns services without names, but v2.0 api does not" [Undecided,New] | 17:44 |
| *** marcoemorais has quit IRC | 17:44 | |
| ayoung | lhcheng_, looking | 17:44 |
| dolphm | ayoung: makes espresso? | 17:44 |
| *** marcoemorais has joined #openstack-keystone | 17:44 | |
| morganfainberg | lhcheng_: will look when I'm back at my desk. Enjoying my coffee atm. | 17:45 |
| ayoung | dolphm, yeah...friend had it on a camping trip long time ago...made a very good ccup as I recall | 17:45 |
| lhcheng_ | morganfainberg: heh sure, take your time :) | 17:45 |
| *** harlowja_away is now known as harlowja | 17:45 | |
| ayoung | lhcheng_, start by replicating the bug and confirming it | 17:46 |
| morganfainberg | ayoung: ++ | 17:46 |
| ayoung | lhcheng_, once you do, set it to confirmed | 17:46 |
| dolphm | http://www.amazon.com/dp/B000CNY6UK/ | 17:46 |
| *** marg7175 has quit IRC | 17:46 | |
| lhcheng_ | I can replicate it, but not sure if it is by design or bug. | 17:46 |
| morganfainberg | ayoung: hey tonight I am setting up a multi federated cloud test env. Might bug you on some stuff. | 17:46 |
| ayoung | cool | 17:46 |
| ayoung | gonna run and grab food before the meeint (in 15 minutes, right?) | 17:47 |
| morganfainberg | 13 | 17:47 |
| morganfainberg | But yes. | 17:47 |
| *** KanagarajM has quit IRC | 17:47 | |
| lhcheng_ | ayoung: okay. I guess for v2, it should also return service catalogs even if the service has no name. | 17:47 |
| morganfainberg | lhcheng_: I'll take a close look in a few. | 17:48 |
| lhcheng_ | morganfainberg: thanks! | 17:48 |
| morganfainberg | I'm guessing it shouldn't care about name if v3 doesn't. But it might be an issue with the v2 catalog parsers (read in client and elsewhere) | 17:48 |
| dolphm | ayoung: i was going to finish your article, but reading about mokkas is much more interesting. #thanksmarek | 17:50 |
| lhcheng_ | morganfainberg: that's what I thought, the response should be the same for v2 and v3. Thanks for the starting point for debugging. | 17:51 |
| *** thedodd has joined #openstack-keystone | 17:51 | |
| *** ukalifon has joined #openstack-keystone | 17:52 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: API doc for Inherited Role Assignments to Projects https://review.openstack.org/130277 | 17:53 |
| *** aix has quit IRC | 17:53 | |
| *** vsilva_ has joined #openstack-keystone | 17:56 | |
| *** ukalifon has quit IRC | 17:59 | |
| *** marcoemorais has quit IRC | 18:00 | |
| morganfainberg | meeting time | 18:00 |
| *** marcoemorais has joined #openstack-keystone | 18:00 | |
| morganfainberg | DST shift and all that (for the NA residents) | 18:00 |
| *** marcoemorais has quit IRC | 18:00 | |
| *** joesavak has quit IRC | 18:01 | |
| *** marcoemorais has joined #openstack-keystone | 18:02 | |
| *** esp has quit IRC | 18:02 | |
| *** joesavak has joined #openstack-keystone | 18:02 | |
| *** Guest32278 is now known as mgagne | 18:03 | |
| *** mgagne has quit IRC | 18:03 | |
| *** mgagne has joined #openstack-keystone | 18:03 | |
| *** gokrokve has quit IRC | 18:03 | |
| *** gokrokve has joined #openstack-keystone | 18:03 | |
| *** jamielennox|away is now known as jamielennox | 18:04 | |
| *** esp has joined #openstack-keystone | 18:04 | |
| *** jamielennox is now known as jamielennox|away | 18:04 | |
| *** jamielennox|away is now known as jamielennox | 18:05 | |
| *** marg7175 has joined #openstack-keystone | 18:10 | |
| *** thedodd has quit IRC | 18:11 | |
| *** marg7175_ has joined #openstack-keystone | 18:12 | |
| *** marg7175 has quit IRC | 18:14 | |
| *** marg7175_ has quit IRC | 18:14 | |
| *** marg7175 has joined #openstack-keystone | 18:14 | |
| *** diegows has quit IRC | 18:17 | |
| *** diegows has joined #openstack-keystone | 18:18 | |
| *** designated has joined #openstack-keystone | 18:18 | |
| *** marg7175 has quit IRC | 18:19 | |
| *** packet has joined #openstack-keystone | 18:19 | |
| designated | I have 4 HA controllers running a galera cluster, all 4 servers can connect to each of the others but for some reason when one of the servers gets hit with a keystone request, I get an error about it losing mysql connection. anyone seen this before? | 18:20 |
| designated | ERROR keystone.common.wsgi [-] (OperationalError) (2006, 'MySQL server has gone away') | 18:20 |
| *** patrickeast has joined #openstack-keystone | 18:21 | |
| designated | it's just the one server, none of the others are having problems. all are running keystone 0.10.1 and the only differences in the configs are the IP address the server binds to. | 18:21 |
| dolphm | designated: https://bugs.launchpad.net/keystone/+bug/1361378 | 18:22 |
| uvirtbot | Launchpad bug 1361378 in oslo.db ""MySQL server has gone away" again" [Undecided,Incomplete] | 18:22 |
| *** gyee has joined #openstack-keystone | 18:22 | |
| *** amcrn has joined #openstack-keystone | 18:24 | |
| *** marg7175 has joined #openstack-keystone | 18:29 | |
| designated | dolphm: thank you but why is the issue not presenting itself on the other, identically configured servers? How do I fix it? | 18:29 |
| *** marg7175 has quit IRC | 18:29 | |
| *** marg7175 has joined #openstack-keystone | 18:30 | |
| dolphm | designated: i haven't followed the issue too closely myself; do ping mike beyer (zzzeek) in #openstack-dev | 18:30 |
| dolphm | or here :) didn't realize you were in this channel, zzzeek | 18:31 |
| zzzeek | there’s been some issues when failover occurs and a node switches back to the previously unavailable one | 18:31 |
| zzzeek | that was in nova | 18:32 |
| zzzeek | when HA clusters switch, its to be expected that a node with connections is now no longer good; the API call will get this error and then will have to retry the whole operation | 18:32 |
| zzzeek | in nova theres a @_retry_on_failure decorator that does this | 18:32 |
| zzzeek | after one retry, should be good | 18:33 |
| zzzeek | designated: ^^ tahts about all i know about this. though my employer wants me to know more about galera :( | 18:33 |
| designated | I'm using haproxy to balance the load amongst my galera mysql cluster, there is no failover happening. | 18:33 |
| designated | all keystone requests succeed except when they hit this one particular server out of the 4 in the cluster | 18:34 |
| *** marg7175 has quit IRC | 18:34 | |
| zzzeek | designated: what happens if you just try to ping / log in to that server manually | 18:34 |
| *** links has joined #openstack-keystone | 18:34 | |
| zzzeek | designated: is it up? | 18:34 |
| *** marg7175 has joined #openstack-keystone | 18:34 | |
| designated | yes it's up, that's how I'm getting the log from /var/log/keystone/keystone-all.log | 18:34 |
| designated | all 4 servers have a consistent keystone configuration, with the only difference being the ipv4 address the serverice is binding to locally. | 18:35 |
| zzzeek | designated: i meant, the MySQL service itself | 18:35 |
| zzzeek | designated: can you make a MySQL connection to the node in question | 18:35 |
| designated | zzzeek: correct | 18:36 |
| zzzeek | designated: the issue referred to here has to do with an intermittent failure, after one of those errors the connecvtion pool would dump and it would be working again | 18:37 |
| zzzeek | designated: are you saying the system is permanently unable to use the node ? | 18:37 |
| dstanek | designated: so you have 4 keystone instances talking through an haproxy instance to a set of galera instances? | 18:37 |
| designated | zzzeek: From what I can tell as the request gets round robined through all 4 servers in the cluster via haproxy, it succeeds on all but one of the servers. | 18:37 |
| designated | dstanek: yes | 18:38 |
| zzzeek | designated: might that mean HAPRoxy is not connecting to that node | 18:38 |
| dstanek | designated: and the error is 100% on one of the keystone nodes? or when any keystone talks to a particular database? | 18:39 |
| designated | zzzeek: no because the connection gets passed through haproxy correctly, which is how I get the log when the failure occurs | 18:39 |
| designated | I have 4 servers all running a galera mysql cluster, the same 4 servers are also running haproxy as an HA frontend for keystone. | 18:40 |
| designated | as I make a keystone request to the VIP, the request gets sent to one of the 4 servers. when it hits one server in particular the request fails, if it hits any of the other 3 servers, it succeeds. | 18:41 |
| zzzeek | designated: unfortunately I dont have direct experience with HAProxy to know with authority what would be seen and not; the error you describe is raised by the driver and indicates it isn’t connecting, so by itself i dont know how that illustrates that HAProxy connected successfully | 18:42 |
| dstanek | designated: from the broken keystone can you hit the database? | 18:42 |
| designated | dstanek: yes | 18:42 |
| zzzeek | designated: but if the error is permanent then that suggests it is not the issue seen in https://bugs.launchpad.net/keystone/+bug/1361378 | 18:43 |
| uvirtbot | Launchpad bug 1361378 in oslo.db ""MySQL server has gone away" again" [Undecided,Incomplete] | 18:43 |
| dstanek | designated: so it's just when running through the app that you have the problem... does that keystone node fail 100% of the time? | 18:43 |
| designated | i make a request example: "keystone --os-tenant-name admin --os-username admin --os-password password --os-auth-url http://10.100.30.1:35357/v2.0 tenant-list" if it hits the server in question, I get the "mysql server has gone away", if it hits any of the other 3 servers, it succeeds. | 18:46 |
| designated | 10.100.30.1 is the VIP that haproxy uses to balance amongst all 4 servers | 18:47 |
| dstanek | designated: so no requests to the bad server ever successfully hit the database? | 18:47 |
| designated | dstanek: not that I can tell | 18:47 |
| designated | but if I create a sql connection from the server in question, it works. "mysql -h 10.100.30.1 -u keystone -ppassword" | 18:48 |
| designated | every time | 18:48 |
| dstanek | designated: i know next to nothing about galera, but it sounds like that node is connecting to the database in a different way | 18:48 |
| designated | dstanek: I've diffed all of the configs and they are all consistent. Thanks for the help, I'll keep troubleshooting. | 18:49 |
| designated | zzzeek: thank you as well. | 18:49 |
| zzzeek | designated: restarting the keystone sever doesnt resolve either right | 18:49 |
| dstanek | designated: look beyond the config; maybe the network path, etc. | 18:49 |
| designated | zzzeek: that was the second thing I tried, after verifying the configurations were correct. | 18:50 |
| dstanek | designated: this was also an interesting read: http://www.gossamer-threads.com/lists/openstack/operators/41332 | 18:50 |
| designated | dstanek: very simple network path, all L2 with multiple 10GBe bonded connections on each server. | 18:51 |
| designated | dstanek: that is intersting, I'll read through it. thank you | 18:53 |
| dstanek | designated: good luck; if you figure it out please report it back here :-) and if not come back to discuss some more | 18:54 |
| marekd | ayoung: so if you were to compare and support different Kent proposals for the federation and current one which is landed in Icehouse (and following) - do out think we were mistaken and Kent was right? | 18:56 |
| *** harlowja is now known as harlowja_away | 18:56 | |
| *** edmondsw has joined #openstack-keystone | 18:58 | |
| *** pballand has joined #openstack-keystone | 18:58 | |
| jamielennox | so how does this relate to the role aliasing we were talking about in paris? i thought the intention was that 'domain scoped roles' and such were going to be handled by creating a name in the alias table, but what the service received was going to be the global role names | 19:02 |
| morganfainberg | jamielennox, the first pass was that | 19:02 |
| henrynash | jamielennox: yes, that is the base proposal: https://review.openstack.org/#/c/133855/ | 19:02 |
| jamielennox | it's evolved? | 19:02 |
| morganfainberg | the second pass was to move towards being able to break things up to more-fine-grained controll and redelegate a permission (e.g. what ayoung wants with constraints) | 19:02 |
| morganfainberg | the reason being that we want to move towards being to give very fine-grained control, but the domain-owned roles is *very* important to our deployers now. | 19:03 |
| morganfainberg | so we make it iterative | 19:03 |
| jamielennox | my understanding was that what went in the 'roles' in the token were going to be top level as well | 19:03 |
| henrynash | jamielennox: what do you mean “top level” | 19:04 |
| gyee | jamelennox, only the "effective" roles are going to be in the tokens | 19:04 |
| jamielennox | that way the whole concept of groups and what the service fetched as policy was static | 19:04 |
| gyee | the lowest level | 19:04 |
| jamielennox | henrynash: global, pretty much what we have now | 19:04 |
| gyee | role group works like user groups | 19:04 |
| henrynash | jamieloeenox, gyee: agreed | 19:04 |
| jamielennox | so if you have a domain scoped role that aliases to some global role the token would contain the global role | 19:05 |
| morganfainberg | jamielennox, that is the correct first pass. following that (because it's a much bigger deal) figure out how to move towards fine-grained permission delegation based upon your underlying roles | 19:05 |
| henrynash | jamielennox, gyee: which makes it totally indpendant from the longer term work | 19:05 |
| gyee | right | 19:05 |
| morganfainberg | jamielennox, so long term we want to be able to allow someone the ability to delegate "boot instance" even though the role they were delegated gives "boot instance, view instance, terminate instance". | 19:05 |
| morganfainberg | but that is a much larger hurdle and can almost be orthoganal to the "grouping" of roles we are proposing now | 19:06 |
| gyee | we gotta be careful with this delegate thingy | 19:06 |
| morganfainberg | correct. | 19:06 |
| gyee | we need to think UX | 19:06 |
| morganfainberg | which is why we start with basic. | 19:06 |
| morganfainberg | simple grouping. | 19:06 |
| gyee | don't place too much responsibility on the users | 19:06 |
| gyee | make it mindnumbingly simple | 19:06 |
| *** jacorob has joined #openstack-keystone | 19:07 | |
| morganfainberg | easy to work with, and then expand to make it more flexible. | 19:07 |
| dstanek | morganfainberg: do we have the uses cases documented or have an existing model for the fine-grained permissions? | 19:07 |
| henrynash | morganfainberg; agreed | 19:07 |
| morganfainberg | dstanek, i have limited use-cases / models for this. hence why i want to start basic | 19:07 |
| morganfainberg | dstanek, and expand as we have time to evaluate it. and the usecases that surface | 19:08 |
| dstanek | is there an end vision or are we winging it and seeing where it goes? | 19:08 |
| jamielennox | morganfainberg: ok, but we are talking resolving the groups on the server side right | 19:08 |
| jamielennox | morganfainberg: as in these group names don't go into the token or policy files | 19:08 |
| jamielennox | henrynash: ^ | 19:08 |
| morganfainberg | jamielennox, yes. that *may* change down the line if warranted | 19:08 |
| samuelms | could we have any case where a domain-specific role doesnt match with a global role? | 19:08 |
| morganfainberg | but initially it is all server side resolved | 19:08 |
| *** breton has quit IRC | 19:08 | |
| henrynash | jamielennox: correct, tokens contents are unchanged | 19:08 |
| samuelms | if I'd like to create cloud, domain and project admin.. how to map them to the admin global ? | 19:08 |
| dolphm | i'm trying to grasp whether hierarchical roles will make role expolosion disease better or worse, but i'm leaning on worse ... with a bunch of extra complexity as a bonus | 19:09 |
| *** _cjones_ has quit IRC | 19:09 | |
| morganfainberg | dolphm, which form the per-permission expansion or the grouping bit? | 19:09 |
| *** breton has joined #openstack-keystone | 19:09 | |
| *** toddnni has quit IRC | 19:09 | |
| samuelms | so it only works if granularity(domain-specific roles) >= granularity(global roles), right? | 19:09 |
| dstanek | henrynash: does that mean that there will always be a hit (or two) back to keystone to get role groups and resolve that to a list of roles? | 19:10 |
| morganfainberg | samuelms, correct. | 19:10 |
| dolphm | morganfainberg: both? | 19:10 |
| morganfainberg | dstanek, the token issued will contain the global cloud-admin roles | 19:10 |
| morganfainberg | dolphm, not the "domain specifc" roles | 19:10 |
| morganfainberg | s/dolphm/dstanek^ | 19:10 |
| henrynash | dstanek: no…the rolegroups and expanded into roles at token issuance time... | 19:10 |
| dolphm | henrynash: domain specific roles are meaningless without domain-specific policy, correct? | 19:11 |
| morganfainberg | dolphm, the domain specific roles allows the cloud provider to provide a rich set of permissions and group them into logical groupings and/or the domain admin to respin as well. | 19:11 |
| henrynash | dtsanek: so token/policy checking is oblivious to all this | 19:11 |
| henrynash | dolphm: untrue | 19:11 |
| dstanek | henrynash: ah, ok. so the roles are really just a management concern and not a runtime concern | 19:11 |
| morganfainberg | dolphm, the point being that a domain admin may only group all the read-only roles into the "audit" role they create | 19:11 |
| morganfainberg | dolphm, and another domain admin might spin that differently into anyone who can read instance data can boot instances. | 19:12 |
| *** Haneef has joined #openstack-keystone | 19:12 | |
| morganfainberg | dolphm, it's defined by the top level cloud-admin roles, but allows logical groupings as needed at *any* level. | 19:12 |
| henrynash | dolphm: the main use case is that the cloud provider owns the servcies (and hence the policy files), role-groups let a domain owner create named groups of roles that are meaninful to them…but the refer to underlyingglobal roles | 19:12 |
| morganfainberg | henrynash, ++ | 19:12 |
| morganfainberg | "storage admin" for one domain might be swift and cinder, another might be cinder only. | 19:13 |
| dolphm | henrynash: ah, okay | 19:13 |
| morganfainberg | vs. needing to know what swift_admin_read_only really does.. etc | 19:13 |
| henrynash | dolphm: which is why it has limited impact on the rest of the systems….since it is purely a “short-hand” within a domain adminstritive boundary for how to assign useful “grousp of roles” | 19:14 |
| samuelms | morganfainberg, and then we should use 'admin' on swift .. and then map 'storage admin' -> admin when issuing the token, right? | 19:14 |
| gyee | its like funny money, at the end, it always ends up with the same amount :) | 19:14 |
| samuelms | morganfainberg, on swift/on swift policy | 19:14 |
| *** _cjones_ has joined #openstack-keystone | 19:14 | |
| morganfainberg | samuelms, so keystone would expand the roles in the group to the top-level-cloud-admin-provided-roles when issuign the token | 19:15 |
| dolphm | henrynash: so, the logical conclusion would be that the deployer creates one role for every permission in the policy blob, and then domain owners create role groups as appropriate for them? | 19:15 |
| morganfainberg | dolphm, that is the extreme case | 19:15 |
| henrynash | dolphm, morganfainberg: what we woudl like to encourage is that cloud operators ad more fine grained (global roles)…that are more like capabilities…to control access to their APIs….then we can have real RBAC! | 19:15 |
| *** thedodd has joined #openstack-keystone | 19:15 | |
| samuelms | morganfainberg, exactly .. initially I was thinking this would give us more granularity at policy level .. but in fact it gives us more flexibility (once granularity(domain-specific roles) >= granularity(global roles)) | 19:15 |
| henrynash | dolphm: snap | 19:15 |
| morganfainberg | dolphm, but it allows us to hit any level of fine-grained control | 19:16 |
| dolphm | so why not just expose capabilities in a better fashion? | 19:16 |
| dolphm | morganfainberg: it does, but so does role explosion disease | 19:16 |
| morganfainberg | dolphm, we will need this grouping functionality in either case. | 19:16 |
| morganfainberg | and namespaced roles (per domain) | 19:16 |
| henrynash | dolphm: go on | 19:16 |
| morganfainberg | there are big big hurdles to solve for capability/permission expansion | 19:16 |
| morganfainberg | how do we know what all the services provide? | 19:17 |
| morganfainberg | a central registry? when they connect they register? | 19:17 |
| dolphm | henrynash: i don't have a solution; i'm just thinking there should be a simpler model, if you're willing to let keystone interpret the policy blobs of other services, which i think ayoung is leaning on? | 19:17 |
| morganfainberg | how do we resolve that in a sane way in the million different combinations. | 19:17 |
| morganfainberg | dolphm, the point being that we spin this up 1st pass and we build the capability/permissioning under it as we jump through the hoops of solving the issues around maintaining that permission list | 19:18 |
| openstackgerrit | Merged openstack/python-keystoneclient: Cleanup docs - raises class https://review.openstack.org/127858 | 19:18 |
| dolphm | morganfainberg: we did have a proposal long ago of a GET /capabilities being exposed by every service, and keystone retrieving those for every endpoint it's aware of. idea never got any traction because it required participation of every service | 19:18 |
| morganfainberg | dolphm, the grouping still matters / still is useful to give logical groups of roles - though the underlying token result might change | 19:18 |
| morganfainberg | dolphm, having to delegate boot_instance, terminate, allocatE_storage, read_image, update_instance, get_instance_data every time would be awful | 19:19 |
| morganfainberg | so you *still* need a way of grouping the permissions in a sane way if we make very fine-grained capability delegation possible | 19:19 |
| stevemar | thanks for the review jamielennox | 19:20 |
| dolphm | morganfainberg: my complaint is that roles are already defined by their "groups" of capabilities, and the solution here is to essentially create groups of groups :-/ | 19:20 |
| *** r-daneel has joined #openstack-keystone | 19:20 | |
| *** nellysmitt has quit IRC | 19:21 | |
| gyee | what's the problem with groups or groups? | 19:22 |
| dolphm | i feel like you should be able to solve the same use case without introducing additional layers of complexity | 19:22 |
| dolphm | for example, by making the policy language more powerful | 19:23 |
| morganfainberg | dolphm, well the other option is policy-side resolution | 19:23 |
| morganfainberg | where we can control the data in the policy file. | 19:23 |
| morganfainberg | i'm just not seeing a clear path that way right now - especially getting all the capabilities grouped up in a sane way. | 19:24 |
| morganfainberg | i am also *very* concerned the currently policy engine isn't efficient enough to handle a full bore explosion of and/or/and/or for every capability | 19:25 |
| morganfainberg | and asking keystone everytime for a resolution of group-> capabilities is a short step from centralized enforcement (with all the pitfalls) | 19:25 |
| dolphm | yeah, distributed enforcement needs to stick around | 19:25 |
| henrynash | dolphm, morganfainberg: the other thing is that essentially part of our job is to allow customers (who may be working with a multi-customer cloud) to model the raw capabilities available in ways that make sense for them, not us | 19:26 |
| amakarov | Good day, is there any document describing required policy capabilities? | 19:26 |
| henrynash | dolphm, morganfainberg: to me, that implies levels of abstraction (although I agree there are other ways of doing it) | 19:26 |
| morganfainberg | amakarov, in the context of this conversation "capability" is the specific API call for say nova to boot an instance | 19:27 |
| rodrigods | marekd, would be nice a etherpad for k2k as well | 19:27 |
| morganfainberg | amakarov, the current rules engine is smart enough to handle most simple logic for the rules - it's a question of scaling that logic up | 19:27 |
| morganfainberg | amakarov, and the right way to scale it up | 19:28 |
| openstackgerrit | Merged openstack/python-keystoneclient: Reorder index links https://review.openstack.org/127688 | 19:28 |
| amakarov | morganfainberg, I understand that, I'm asking about starting point to think about it :) | 19:29 |
| dstanek | morganfainberg: that's why i was asking about vision here because i don't know how to think about this to help | 19:30 |
| morganfainberg | dstanek, maybe the answer is as simple as caching the graph of roles -> permissions | 19:31 |
| ayoung | marekd, I think K2K and Kent are somewhat complementary. Back when when we were first discussing things, we thought maybe the IdPs should go into the service catalog. | 19:31 |
| jamielennox | hey everyone, i need some client reviews to get v3 in auth_token moving again: https://review.openstack.org/#/c/130532/ is next in line | 19:32 |
| morganfainberg | make it so middleware collects the full graph for services it cares about (configured) and has a TTL. if it sees a role it doesn't know it asks keystone for the graph of that role | 19:32 |
| amakarov | morganfainberg, we can build a simple yet powerful graph framework to implement some sort of semantic web or remain with simple if-then logic | 19:32 |
| morganfainberg | and it passes the *raw* capabilities down to the service | 19:32 |
| amakarov | it depends on our goals | 19:32 |
| morganfainberg | which the policy language is sufficient to handle | 19:32 |
| morganfainberg | the issue still lies in "what are the capabilities that can be assigned to a given role" | 19:33 |
| morganfainberg | dstanek, and on fixed intervals update the graph. [with some magic timeshift to avoid overloading keystone] | 19:34 |
| morganfainberg | and the data is something that while expensive to calculate should be stupidly cachable | 19:34 |
| *** links has quit IRC | 19:34 | |
| amakarov | morganfainberg, do we have a vision what are these capabilities? | 19:34 |
| dstanek | morganfainberg: that's still implementaton...what are the problems being solved? | 19:34 |
| samuelms | morganfainberg, I don't understand yet how to map domain-specific-roles on global-roles and still use a single policy | 19:34 |
| morganfainberg | dstanek, user-story | 19:35 |
| morganfainberg | dstanek, I, a keystone domain admin .. or project admin, want to delegate very limited roles to someone/service to perform an action on my behalf | 19:35 |
| dstanek | from what i read earlier from henrynash, we have the need to split up the roles a cloud providers defines from the usage by a customer | 19:35 |
| samuelms | morganfainberg, if we have different specific roles (by domain) used to grant different permissions .. it would be clear to me that we should have one policy per domain | 19:35 |
| morganfainberg | dstanek, so i don't need to give *everything* to a service if all that service needs to do is boot an instance every-now-and-again | 19:35 |
| *** harlowja_away is now known as harlowja | 19:36 | |
| *** marcoemorais has quit IRC | 19:36 | |
| morganfainberg | dstanek, second case: read-only access for auditing but at an admin level. "what services / resources can this read-only access get" it may not include swift ever, but all nova instances | 19:36 |
| *** marcoemorais has joined #openstack-keystone | 19:36 | |
| dstanek | morganfainberg: for that i still like my idea of just scoping a token to an action/resource | 19:36 |
| *** marcoemorais has quit IRC | 19:36 | |
| morganfainberg | dstanek, the issue is tokens need more than 1 capability | 19:37 |
| *** marcoemorais has joined #openstack-keystone | 19:37 | |
| morganfainberg | dstanek, and my "determination" of what admin-read-only is might be different than yours | 19:37 |
| dstanek | your second case is a little more interesting | 19:37 |
| dstanek | morganfainberg: i think i need to read up on our policy impl, but i sounds like we don't really have a good permission model | 19:38 |
| morganfainberg | dstanek, heck i might have someone in my org that *is* an admin and can muck with all instances. | 19:38 |
| morganfainberg | dstanek, that's their job, so give them all the permissions needed to do so | 19:39 |
| morganfainberg | dstanek, but they don't need anything ins wift | 19:39 |
| openstackgerrit | Merged openstack/keystonemiddleware: I18n https://review.openstack.org/131287 | 19:39 |
| morganfainberg | our permission model is limited by the RBAC system we define and that services can add/remove API actions at a whim | 19:39 |
| morganfainberg | effectively | 19:39 |
| morganfainberg | the policy language is generally smart enough to handle these cases. | 19:39 |
| *** marcoemorais has quit IRC | 19:40 | |
| ayoung | OK...so I was trying to figure out the clearest "root problem" that this policy approach addresses. How's this for a starting point: "How do you determine who can assign which roles?" | 19:40 |
| *** marcoemorais has joined #openstack-keystone | 19:40 | |
| bknudson | I18N for keystonemiddleware... interesting | 19:40 |
| morganfainberg | ayoung, i think that 1 one of the two problems | 19:40 |
| bknudson | I wonder if the translators will provide translations | 19:41 |
| morganfainberg | ayoung, the second question is still "what do i need to perform action X" | 19:41 |
| ayoung | and, I think it comes down to a general rule of "a user should not be able to delegate something that they themselves cannot do." | 19:41 |
| morganfainberg | ayoung, agreed. | 19:41 |
| ayoung | morganfainberg, I think the horizon guys would reverse what you said? | 19:41 |
| ayoung | What do I show to a user based on their roles that indicates what they can do | 19:41 |
| morganfainberg | ayoung, well we have the 3rd question as well: i have auth x, what can i do | 19:42 |
| ayoung | right | 19:42 |
| morganfainberg | ayoung, so we're back to the two questions from the summit plus "what can i delegate to whom" | 19:42 |
| dstanek | morganfainberg: yeah, i have to look for the gaps; NIST talks about a bunch of RBAC stuff like role hierarchies, etc. and i don't think we implement it yet (role hierarchies obviously since we've been discussing similar concepts at length) | 19:42 |
| ayoung | morganfainberg, and I think phrasing it both ways is actually valuable: capabilites from roles and roles from capabilites are both needed | 19:42 |
| ayoung | dstanek, yep | 19:43 |
| ayoung | nist RBAC is not namespaced like ours is | 19:43 |
| ayoung | so is I was admin for a project named X, the role would be X_admin in the nist approach | 19:43 |
| ayoung | I like ours better, but it means that we have two hierarchies; the naming or roles, and the project hierarchy | 19:44 |
| dstanek | ayoung: i'm also interested in ARBAC after the Atlanta summit | 19:44 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient: Updated from global requirements https://review.openstack.org/134794 | 19:45 |
| ayoung | dstanek, OK, so ABAC is the mechanism | 19:45 |
| ayoung | RBAC is built on ABAC | 19:45 |
| ayoung | ARBAC is just a name that acknowledges that | 19:45 |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Make keystoneclient use an adapter https://review.openstack.org/97681 | 19:45 |
| dstanek | not ABAC; ARBAC - using RBAC on top of RBAC to controls delegating management of permissions | 19:45 |
| ayoung | oh, the admin side | 19:46 |
| jamielennox | dstanek: did you try and read the papers he had on that though | 19:46 |
| ayoung | we have that by having the RBAC on Keystone | 19:46 |
| *** amakarov is now known as amakarov_away | 19:46 | |
| jamielennox | the concept isn't that hard, the academic papers are mind bending | 19:46 |
| ayoung | I see it like this: | 19:46 |
| dstanek | jamielennox: kinda, sorta; i skimmed, but never read in depth | 19:46 |
| ayoung | a user can only potentially delegate arole that they have, or some subordinate role implied by that. But they need specific role to make that delegation sticky | 19:47 |
| ayoung | sticky means role-assignemnt | 19:47 |
| dstanek | ayoung: it's actually different because it's a second layer or RBAC (i believe separated for security/auditing reasons) | 19:47 |
| ayoung | dstanek, We get that by concentrating the RBAC administration inside of Keystone | 19:48 |
| openstackgerrit | Steve Martinelli proposed openstack/python-keystoneclient: OAuth headers are missing https://review.openstack.org/134364 | 19:48 |
| ayoung | It probably means that we should have a separate set of roles for operations on Keystone than for operations in Nova, but with hiearchiacl, they will all get rolled up into "super godlike admin of all" | 19:48 |
| morganfainberg | ayoung, we should absolutly use the policy namespace construct "e.g. enforce for <keystone> or <glance>" | 19:49 |
| stevemar | jamielennox, fixed it up, thanks a lot for showing me that code, it always bugged me the way we mangled urls | 19:49 |
| morganfainberg | which *should* be separate roles | 19:49 |
| ayoung | morganfainberg, no question there | 19:49 |
| dstanek | ayoung: i'll have to read up on the paper for why they think it should be separated | 19:49 |
| morganfainberg | regardless of how it rolls up or doesn't later | 19:49 |
| jamielennox | stevemar: ok, i can only speak for that side of it - i've no idea how to test the header values you're changing | 19:50 |
| stevemar | jamielennox, the only one i'm changing the is requested-project-id one | 19:50 |
| ayoung | morganfainberg, it may mean that there are roles that should not be assigned down or something like that...in order to affect cahnge on Keyston, you need a token with exactly the role, and not one that expands out into it, so that a user needs to explicitly select the role for the operations to be performed | 19:50 |
| ayoung | kindof like logging in as a normal user, and then doing sudo for admin tasks | 19:51 |
| morganfainberg | ayoung, that *may* be the right answer | 19:51 |
| morganfainberg | i don't discount it as one of the potentials for sure | 19:51 |
| ayoung | morganfainberg, it also may be that when you get a proejct scoped token, you never get the roles that couldn't be scoped to that project | 19:52 |
| ayoung | so if I am "cloud_admin" and that gets inheritaed as "project_admin" on project P, If I ask for a token on P, it will have the project_admin role, not cloud_admin | 19:52 |
| openstackgerrit | Endre Karlson proposed openstack/python-keystoneclient: Allow to allow for other then STABLE api version https://review.openstack.org/130159 | 19:54 |
| *** vsilva_ has quit IRC | 19:54 | |
| ayoung | dstanek, dangit, now you got me thinking again | 19:55 |
| ayoung | never a good idea | 19:56 |
| dstanek | ^H^H^H - any way to erase my previous comments? | 19:56 |
| ayoung | heh | 19:58 |
| morganfainberg | dstanek, ^w^w^w | 19:59 |
| morganfainberg | dstanek, didn't work either darn | 19:59 |
| ekarlso- | anyone wanna sign off again on ^? | 20:00 |
| ekarlso- | it's rebased | 20:00 |
| ayoung | dstanek, OK, I don't feel so bad at confusing ARBAC with RABAC. | 20:02 |
| samuelms | henrynash, ping | 20:02 |
| ayoung | samuelms, no naked pings! | 20:02 |
| morganfainberg | ayoung, ping | 20:02 |
| morganfainberg | >.> | 20:03 |
| ayoung | HA! | 20:03 |
| morganfainberg | <.< | 20:03 |
| samuelms | haha | 20:03 |
| samuelms | morganfainberg, ++ | 20:03 |
| ayoung | 64 bytes from ayoung (127.0.0.1): icmp_seq=1 ttl=64 time=0.071 ms | 20:03 |
| rodrigods | ping was how I learned to chat in IRC =( | 20:03 |
| morganfainberg | well crap. | 20:03 |
| ayoung | rodrigods, I know, we all did | 20:03 |
| morganfainberg | i forgot to say stuff about mid-cycle | 20:03 |
| morganfainberg | anyway i'll send the email | 20:04 |
| ayoung | http://blogs.gnome.org/markmc/2014/02/20/naked-pings/ | 20:04 |
| rodrigods | ayoung, but I saw your tweet, it makes sense | 20:04 |
| htruta | https://twitter.com/admiyoung/status/533256426597396481 | 20:04 |
| htruta | ops... slower than ayoung | 20:04 |
| ayoung | rodrigods, Adam Jackson is awesome. | 20:04 |
| morganfainberg | dolphm, have firm dates for SAT | 20:04 |
| morganfainberg | dolphm, Jan 19, 20, 21 | 20:04 |
| dolphm | morganfainberg: woot | 20:04 |
| morganfainberg | dolphm, just need to confirm geekdom or RAX space | 20:04 |
| stevemar | yay | 20:05 |
| morganfainberg | dolphm, i had to go with the earlier days for the mid-cycle since i *cant* make the the second half of the week. | 20:05 |
| morganfainberg | :P | 20:05 |
| dolphm | morganfainberg: i'll aim for geekdom first and get back to you | 20:05 |
| * morganfainberg feels bad bug has another meeting end fo that week in the bay | 20:05 | |
| morganfainberg | s/bug/but | 20:05 |
| rodrigods | quick question: is the HEAD return for the OS-INHERIT extension wrong for domains as well? https://review.openstack.org/#/c/130277/9/api/v3/identity-api-v3-os-inherit-ext.rst | 20:05 |
| morganfainberg | dolphm, ++ i'll update everything - post a blog that i can keep updated etc. | 20:06 |
| morganfainberg | dolphm, and update wiki saying the space in SAT is TBD | 20:06 |
| morganfainberg | until we're confirmed | 20:06 |
| morganfainberg | dolphm, also hotel discount would be *awesome* if we can swing it again. | 20:06 |
| morganfainberg | dolphm, tyvm btw :) | 20:06 |
| ayoung | dolphm, so...the big thing I would like it if you confirm: Is it acceptable to move toward managing the individual rules for each API in the database? | 20:07 |
| ayoung | The policy rules, that is | 20:07 |
| bknudson | rodrigods: the HEAD status has to match what the GET status would be... apache will turn a HEAD into a GET anyways. | 20:08 |
| dolphm | morganfainberg: ++ | 20:08 |
| ayoung | you had suggested at the midcycle that the managing of the policy files could be done off line. Without the hierarchical roles, I agree. Its just the hierarchical portion and expanding in the generation that would make sense to be done inside of Keystone itself | 20:08 |
| rodrigods | bknudson, hmm thanks... will check if we have a doc bug there and update our review | 20:08 |
| raildo | Haneef, I respond your questions here: https://review.openstack.org/#/c/130277/ :) | 20:09 |
| dolphm | morganfainberg: expecting a similar turnout to summer, i assume? | 20:12 |
| morganfainberg | dolphm, sec. | 20:12 |
| bknudson | the weather should be nicer (there) in winter. | 20:12 |
| morganfainberg | dolphm, just added you to the poll | 20:13 |
| morganfainberg | dolphm, so you can see the responses | 20:13 |
| dolphm | bknudson: it'll probably be 60's & 70's | 20:13 |
| morganfainberg | dolphm, we'll send out a second real "RSVP" form with my email since we have dates / city pinned down | 20:14 |
| dolphm | morganfainberg: i thought barbican was for sure doing it in SF? | 20:14 |
| morganfainberg | but i would expect similar-ish turnout | 20:14 |
| morganfainberg | they aren't sure they are | 20:15 |
| morganfainberg | it's up in the air. and i don't want to make people scramble to get to our | 20:15 |
| morganfainberg | s | 20:15 |
| morganfainberg | so, if barbican *really* wants overlap.. they can get it, but at this point it was pretty non-committed on anything specific | 20:15 |
| * morganfainberg asked a bunch | 20:15 | |
| *** marcoemorais has quit IRC | 20:15 | |
| morganfainberg | and the majority of people are keystone with a "if we get a barbican day overalp it's good" | 20:16 |
| *** marcoemorais has joined #openstack-keystone | 20:17 | |
| *** _cjones_ has quit IRC | 20:20 | |
| openstackgerrit | Andre Aranha proposed openstack/keystone-specs: Modify the policy file https://review.openstack.org/135408 | 20:20 |
| ayoung | I need to write a new spec for role assignments based on the Hierarchical spec. | 20:22 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Allow loading other auth methods in auth_token https://review.openstack.org/129552 | 20:27 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Split identity server into v2 and v3 https://review.openstack.org/130534 | 20:27 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Additional discovery changes https://review.openstack.org/130533 | 20:27 |
| openstackgerrit | Jamie Lennox proposed openstack/keystonemiddleware: Use real discovery object in auth_token middleware. https://review.openstack.org/130532 | 20:27 |
| *** dtturner has quit IRC | 20:28 | |
| *** NM has quit IRC | 20:31 | |
| samuelms | jamielennox, just replied your comment at role-groups spec | 20:33 |
| jamielennox | samuelms: i guess its a matter of terminology | 20:35 |
| jamielennox | currently when you add a role you add a global role | 20:35 |
| jamielennox | when we start talking about domain roles and such we are still calling them roles | 20:35 |
| samuelms | jamielennox, right | 20:35 |
| jamielennox | i'm not sure how we are going to express that relationship when you create a domain role how do you link it to the global role | 20:36 |
| jamielennox | but is it a similar process to define a role which is a group of global roles | 20:36 |
| jamielennox | don't really mind - was just a though | 20:37 |
| samuelms | jamielennox, in fact I think role are still global | 20:37 |
| samuelms | jamielennox, group-roles are for domains | 20:37 |
| marekd | rodrigods: right. | 20:37 |
| samuelms | jamielennox, I took a bit to understand that relationship .. I mean the mapping that will be applied when issuing a token .. | 20:38 |
| marekd | rodrigods: https://etherpad.openstack.org/p/keystone2keystone | 20:38 |
| telemonster | Quick question. Openstack Havana. User in db has a default project assigned to it, LDAP is in place, but this always comes back when trying to log in: | 20:38 |
| telemonster | You are not authorized for any projects. | 20:38 |
| samuelms | jamielennox, suppose we have a global role per API operation .. then a domain_admin create his own set of role-groups, mapping to the global roles | 20:38 |
| samuelms | jamielennox, he has fine grained choices when making his groups :) | 20:38 |
| samuelms | jamielennox, the domain_admin defines the mapping when creating the role-group (with the role: field inside it, as you said) | 20:39 |
| samuelms | jamielennox, and the reverse-mapping is applied when we the token is issued, so that we have only global roles inside the token | 20:40 |
| stevemar | nkinder dtroyer, so whats the stance we want to take on defaulting user and project domains to default in OSC - bknudson brings up a good point here: https://review.openstack.org/#/c/135152/ | 20:41 |
| jamielennox | yep, get that, but i was thinking if we get down to a role per API operation then i'd call that a capability, and a role is a group of capabiliies anyway, so given a role is already a group, do we need the concept of role-groups or are we just trying to mess with the existing terminology in a compatible way | 20:42 |
| stevemar | bknudson, we could just doc that those env. variables are needed (which we do in the keystone docs), and maybe have devstack default to those values (for now) | 20:43 |
| marekd | jamielennox: how far do you think we are with keystoneclient being able to hande multiple tokens at the same time? | 20:43 |
| marekd | or rather s/are/from/ ? | 20:44 |
| *** pballand has quit IRC | 20:44 | |
| *** bknudson has quit IRC | 20:44 | |
| jamielennox | marekd: eek, what was the case again? | 20:44 |
| jamielennox | i mean, you can write a plugin to do what you like, what was the reason to have the client manage multiple plugins? | 20:45 |
| ayoung | ENCRYPT ALL THE WEBS! https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web | 20:45 |
| marekd | jamielennox: for instance keystoneclient being able to burst into multiple clouds with k2k | 20:45 |
| marekd | we cannot use one token across multiple clouds, so at least we can hide that fact at the lib layer. | 20:45 |
| jamielennox | yea, i'm not sure - what do we think the UX for that is going to be? | 20:46 |
| samuelms | jamielennox, got your point on the terminology .. so role-groups means groups of groups of capabilities :B | 20:47 |
| *** raildo is now known as raildo_away | 20:48 | |
| jamielennox | samuelms: i'm ok with a new route was just wondering, because technically a role-group will just be a role right? it'll be delegated and such in exactly the same way a role is now | 20:50 |
| jamielennox | marekd: do you think bursting like that should be transparent to the user? | 20:50 |
| *** _cjones_ has joined #openstack-keystone | 20:52 | |
| nkinder | stevemar: I agree with bknudson | 20:53 |
| marekd | jamielennox: i think so. | 20:53 |
| nkinder | stevemar: Implicitly using 'Default' doesn't seem like a good idea, as that domain may not even exist. | 20:53 |
| marekd | jamielennox: at least, again i think it should not repeat whole workflow with every call... | 20:54 |
| stevemar | nkinder, okay, i'm bugging you, since it's your bug :) | 20:54 |
| nkinder | stevemar: I just think that we should assume that the project domain is the same as the user domain | 20:54 |
| marekd | jamielennox: ok, this gets back to a token caching somewhat. | 20:54 |
| nkinder | stevemar: it's annoying to have to specify 3 domain options for a single command when they are all the same domain | 20:54 |
| stevemar | nkinder, what's the 3rd domain option? | 20:55 |
| nkinder | stevemar: 3 if I'm getting a domain scoped token. Let me get you an example command... | 20:55 |
| stevemar | ah | 20:55 |
| marekd | jamielennox: https://review.openstack.org/#/c/134606/2/keystoneclient/contrib/auth/v3/saml2.py by the way. | 20:55 |
| marekd | jamielennox: i'd like to have your opinion to see if there is reason to carry on | 20:56 |
| stevemar | nkinder, nah, i know what you mean | 20:56 |
| nkinder | stevemar: yeah, it's like this command - https://github.com/nkinder/rdo-vm-factory/blob/master/rdo-kerberos-setup/vm-post-cloud-init-rdo.sh#L269 | 20:56 |
| *** marg7175 has quit IRC | 20:58 | |
| jamielennox | marekd: we can't have the library creating files like that | 20:58 |
| jamielennox | i think we need to look at serializing the plugins then letting OSC handle caching | 20:58 |
| marekd | jamielennox: why? | 20:59 |
| marekd | jamielennox: do you have a review to a serialization patch ? | 21:00 |
| jamielennox | marekd: well mostly you just never know how someone wants to use it, it's generally not a good idea to have a library maintaining it's own state | 21:00 |
| jamielennox | marekd: this is the most recent one i've done | 21:01 |
| jamielennox | https://review.openstack.org/#/c/113163/ | 21:01 |
| marekd | jamielennox: i remember user/pass was not serialized, but in the end every separate call ended with a new token? | 21:01 |
| marekd | jamielennox: ok, maybe you are right. | 21:01 |
| jamielennox | i'd like some input on it from the OSC perspective, dtroyer, stevemar ^ do you know how you'd use something like that | 21:01 |
| jamielennox | it comes into what we were talking about at summit and serializing of sensitive data 'm not sure what to do there so i just haven't finished it | 21:02 |
| *** marg7175 has joined #openstack-keystone | 21:02 | |
| *** bknudson has joined #openstack-keystone | 21:04 | |
| *** ChanServ sets mode: +v bknudson | 21:04 | |
| *** marg7175 has quit IRC | 21:05 | |
| stevemar | jamielennox, something like that == token / saml caching? | 21:05 |
| *** marg7175 has joined #openstack-keystone | 21:05 | |
| jamielennox | generally plugin caching - not just saml | 21:06 |
| designated | why can't the openstack documentation be more comprehensive? why must I scour the internet for tidbits of information to make openstack work? If the documentation isn't correct or will not get you to a working state then don't just throw shit out there to irritate people /rage | 21:06 |
| marekd | stevemar: yes, general token caching | 21:08 |
| marekd | stevemar: but i wanted to start at my playground :-) | 21:08 |
| marekd | stevemar: generally i think tokens should be reused as much as possible | 21:08 |
| jamielennox | marekd: so within a process you should be fine because you can hang on to the auth plugin as long as you want, it's the CLI case which is the problem | 21:10 |
| * jamielennox offloads that problem :) | 21:11 | |
| marekd | :-) | 21:11 |
| telemonster | 2014-11-18 21:12:26.327 13560 WARNING keystone.token.controllers [-] User Neutron Service is unauthorized for tenant f88b07200f33441fa8a40354b63b4385 | 21:12 |
| stevemar | jamielennox, marekd yeah i recall a design session where we were talking about caching and CLI, and how the process ends, and you are kinda screwed for caching. | 21:13 |
| *** jacorob has quit IRC | 21:14 | |
| *** bknudson has quit IRC | 21:15 | |
| stevemar | nkinder, why are we not using your script in our CI | 21:15 |
| designated | zzzeek: How do I implement the fix for juno from this link? https://bugs.launchpad.net/oslo.db/+bug/1374497 | 21:16 |
| uvirtbot | Launchpad bug 1374497 in oslo.db/juno "change in oslo.db "ping" handling is causing issues in projects that are not using transactions" [High,Fix released] | 21:16 |
| designated | zzzeek: or at the very least, verify the version I have is updated so I'm not chasing my tail. | 21:16 |
| samuelms | jamielennox, yes .. makes sense .. thanks :) | 21:16 |
| *** thiagop has quit IRC | 21:17 | |
| zzzeek | designated: i think you’d want to look and see if https://review.openstack.org/#/c/125079/ is present | 21:17 |
| dstanek | designated: now what's the issue? | 21:20 |
| designated | zzzeek: I don't follow | 21:20 |
| designated | dstanek: the same issue I was having. I'm not familiar enough with patching to determine whether the version I have is affected or not. | 21:20 |
| zzzeek | open up the file “oslo/db/sqlalchemy/session.py” within the code you are testing and ensure it has the patches that you see in https://review.openstack.org/#/c/125079/1/oslo/db/sqlalchemy/session.py. taht’s the most brute force way to check. there are probably better ways but I don’t know openstack release mechanics that intimately | 21:21 |
| designated | I'm getting 2006, 'MySQL server has gone away' from keystone intermittently | 21:21 |
| *** bknudson has joined #openstack-keystone | 21:22 | |
| *** ChanServ sets mode: +v bknudson | 21:22 | |
| *** bknudson1 has joined #openstack-keystone | 21:22 | |
| dstanek | designated: what release are you using? | 21:22 |
| designated | dstanek: juno | 21:23 |
| designated | on ubuntu 14.04 | 21:23 |
| dstanek | designated: is that the package provides in the standard repos | 21:24 |
| dstanek | ? | 21:24 |
| designated | yes | 21:24 |
| zzzeek | designated: this is a persistent connectiviy issue you’re having so if i were you id be verifying that MySQLdb can connect as its supposed to, that is, test script, “import MySQLdb; conn = MySQLdb.connect(<args>)” | 21:24 |
| zzzeek | designated: then see that connect() succeeds. also in the stack trace, “mysql gone away” occurs at what operation, is it on connect(), or wihtin cursor.execute(), and if the latter, what is the statement being invoked, do other statements prior to that one succeed, etc. | 21:25 |
| dstanek | zzzeek: i had designated that earlier | 21:25 |
| zzzeek | “mysql gone away” error means a lot of things with MySQL-python | 21:25 |
| zzzeek | and all of that works fine | 21:25 |
| nkinder | stevemar: that's a good question... :) I am setting up various infrastructure that the CI wouldn't have in place, but we could make some tests that use the same commands to exercise the use of domains. | 21:25 |
| zzzeek | ? | 21:25 |
| dstanek | designated: can you pastebin some of the logs? | 21:25 |
| marekd | stevemar: why screwed for caching ? | 21:26 |
| *** bknudson has quit IRC | 21:26 | |
| *** stevemar has quit IRC | 21:26 | |
| dstanek | designated: have you gone through normal debugging steps like find the smallest configuration that exhibits the failure? (e.g. direct traffic directly at the node you think is broken, have it talking to a single mysql instance, etc) | 21:27 |
| designated | dstanek: http://pastebin.com/gMjQiuGX | 21:27 |
| dstanek | designated: is there any error earlier in the log about connectivity or error while connecting? | 21:28 |
| designated | dstanek: no, it works sometimes, sometimes it fails. | 21:28 |
| designated | dstanek: let me change haproxy to only talk to 1 node | 21:29 |
| designated | dstanek: If I take the server in question out of the haproxy config for keystone admin (TCP 35357), it balances the load amongst the other 3 servers just fine and I no longer receive the error. there must be an issue with that one server. | 21:36 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone-specs: Authenticated Encryption Tokens https://review.openstack.org/130050 | 21:36 |
| dstanek | designated: what happens when you go directly against that one server? | 21:36 |
| designated | dstanek: testing that now | 21:37 |
| dstanek | morganfainberg: are you trying to get the Rax discount at the hotels? | 21:38 |
| designated | dstanek: if I hit that single server, it works intermittently. I get either "An unexpected error prevented the server from fulfilling your request. (HTTP 500)", "Authorization Failed: An unexpected error prevented the server from fulfilling your request. (HTTP 500)" or it succeeds. | 21:38 |
| morganfainberg | dstanek, yes | 21:39 |
| morganfainberg | dstanek, or *a* discount. | 21:39 |
| morganfainberg | dstanek, just bugging dolphm to help out on that front again. | 21:39 |
| dstanek | designated: is it only happening for certain operations then? | 21:40 |
| designated | dstanek: I'm running the same query over and over "keystone --os-tenant-name admin --os-username admin --os-password password --os-auth-url http://10.100.30.1:35357/v2.0 tenant-list" | 21:41 |
| designated | dstanek: I have to go pick my kids up from school. I'll be back in about 30 minutes. | 21:43 |
| *** gokrokve_ has joined #openstack-keystone | 21:46 | |
| *** gokrokve has quit IRC | 21:50 | |
| henrynash | morganfainberg, stevemar: gentle prod on https://review.openstack.org/#/c/130954/21, if you get a chance | 21:56 |
| morganfainberg | henrynash, tuesday = meeting craziness | 21:58 |
| morganfainberg | but yes | 21:58 |
| * morganfainberg is still in meetings. | 21:58 | |
| henrynash | morganfainberg: understand! | 21:58 |
| *** marcoemorais has quit IRC | 22:00 | |
| morganfainberg | henrynash, ok i need some lunch and then i've got one more meeting today | 22:00 |
| *** marcoemorais has joined #openstack-keystone | 22:00 | |
| *** bknudson1 has quit IRC | 22:03 | |
| *** bknudson has joined #openstack-keystone | 22:05 | |
| *** ChanServ sets mode: +v bknudson | 22:05 | |
| *** _cjones_ has quit IRC | 22:09 | |
| *** _cjones_ has joined #openstack-keystone | 22:10 | |
| *** RichardRaseley has joined #openstack-keystone | 22:14 | |
| telemonster | Does anyone have any knowledge of openstack/LDAP? Havana? | 22:17 |
| telemonster | My coworkers that were sent to the Openstack redhat training have no idea, and I'm trying to help them | 22:17 |
| telemonster | We're migrating to EC2 and scrapping Openstack as of tomorrow if it isn't fixed | 22:17 |
| telemonster | We rolled back to Havana hoping the LDAP (AD) part would work as it did, but no go | 22:18 |
| telemonster | It's passing the LDAP part AFAIK, but failing the project authroization | 22:19 |
| telemonster | I checked the mysql tables (no way to auth with it on ldap) and the cloudadmin user is in the admin project | 22:19 |
| telemonster | and admin project in the metadata table has cloudadmin uid | 22:19 |
| telemonster | as well as admin | 22:19 |
| telemonster | this config worked prior on a havana install, but not sure what other things were done to make it work | 22:20 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Refactor extract class for signing directory https://review.openstack.org/122281 | 22:20 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Auth token tests create temp cert directory https://review.openstack.org/122280 | 22:20 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Refactor auth_token revocation list members to new class https://review.openstack.org/102403 | 22:20 |
| *** marekd is now known as marekd|away | 22:25 | |
| *** agireud has quit IRC | 22:26 | |
| gyee | we have a metadata table? | 22:28 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Change tenant to project https://review.openstack.org/127066 | 22:30 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Correct tests to use strings in conf https://review.openstack.org/128655 | 22:30 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Fix paste config option conversion for auth options https://review.openstack.org/131914 | 22:30 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Auth token supports deprecated names for paste conf options https://review.openstack.org/128656 | 22:30 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Change admin user to service user. https://review.openstack.org/127075 | 22:30 |
| openstackgerrit | Brant Knudson proposed openstack/keystonemiddleware: Change occurrences of keystone to identity server https://review.openstack.org/127062 | 22:30 |
| *** gokrokve_ has quit IRC | 22:31 | |
| *** topol has quit IRC | 22:31 | |
| *** tellesnobrega has joined #openstack-keystone | 22:33 | |
| *** diegows has quit IRC | 22:35 | |
| *** radez is now known as radez_g0n3 | 22:36 | |
| jamielennox | bknudson: can i bug you to have a look at those patches for plugins in middleware again | 22:36 |
| jamielennox | (when you have a moment) | 22:36 |
| bknudson | jamielennox: which? | 22:36 |
| jamielennox | bknudson: starting https://review.openstack.org/#/c/130532/ | 22:37 |
| *** vejdmn has quit IRC | 22:42 | |
| gyee | jamielennox, you have time to finish this one up? https://review.openstack.org/#/c/113735/ | 22:42 |
| gyee | its similar to your nova, cinder patch | 22:43 |
| marekd|away | gyee: I cannot recall, did ADFS worked with Keystoneclient? | 22:43 |
| bknudson | I might also have some time to look at the nova work again sometime ( gyee , jamielennox ) | 22:43 |
| gyee | marekd|away, yes, sam did test it | 22:43 |
| marekd|away | gyee: and what ADFS version do you use? | 22:43 |
| bknudson | marekd|away: btw - I spent a day in Geneva last week... the water jet was under repair. | 22:44 |
| bknudson | you should have warned us. | 22:44 |
| marekd|away | bknudson: you should have told me. | 22:44 |
| gyee | marekd, let me check | 22:44 |
| gyee | one sec | 22:44 |
| marekd|away | bknudson: really, was it? for how long? | 22:45 |
| marekd|away | bknudson: i don't even notice such things. sometimes they turn it off due to wind. | 22:45 |
| *** packet has quit IRC | 22:45 | |
| bknudson | marekd|away: I think it was off for repairs for several days. It might be back on now. | 22:46 |
| marekd|away | it is | 22:46 |
| marekd|away | bknudson: this simply means you need to come back :-) | 22:46 |
| gyee | marekd|away, Windows Server 2012 R2 | 22:47 |
| marekd|away | bknudson: where else did you go for your post summit voyage? | 22:47 |
| marekd|away | gyee: ack | 22:47 |
| marekd|away | gyee: thanks | 22:47 |
| bknudson | marekd|away: yes... I didn't get the full experience... also, I should have gotten on a boat that takes me around to the castle | 22:47 |
| bknudson | marekd|away: we planned it poorly since it was spur of the moment | 22:47 |
| gyee | marekd|away, though I haven't read the code, but according to Sam, we are not validating the assertion for K2K | 22:48 |
| gyee | because of the ecb wrap? | 22:48 |
| bknudson | marekd|away: otherwise we hung around paris... louvre, cluny, orly, notre dame... took a day tour of chateaus in the loire valley. | 22:48 |
| bknudson | marekd|away: I was there with my mom. | 22:48 |
| gyee | you could easily spend a week in louvre | 22:50 |
| bknudson | gyee: it is ridiculously amazing. | 22:50 |
| bknudson | makes other museums look like a joke | 22:50 |
| marekd|away | bknudson: oh, you could have told me, we could try organizing some CERN trips :( | 22:50 |
| gyee | I know | 22:50 |
| jamielennox | gyee, bknudson: did that nova patch work without the neutronclient changes? i had one that was dependant on stuff in client and that was just taking forever | 22:50 |
| gyee | jamielennox, I am review your patch right now | 22:51 |
| gyee | reviewing | 22:51 |
| marekd|away | bknudson: hope you liked Paris/Geneva/Europe in general :-) | 22:51 |
| marekd|away | gyee: hm, this means we can confirm ksc saml2 plugins work with ADFS3 | 22:52 |
| marekd|away | gyee: as I think ADFS3 is shipped by default with w2012 R2 | 22:52 |
| marekd|away | gyee: i *dont* think this is due to ECP wrap, as we only sign one part of the whole assertion. | 22:53 |
| bknudson | marekd|away: y, it was great. Was worried about the language but turned out not to be a problem. Hopefully we'll be back there for a summit ... in a couple years (?) | 22:53 |
| openstackgerrit | werner mendizabal proposed openstack/keystone: Test gerrit https://review.openstack.org/135446 | 22:53 |
| gyee | marekd|away, yes ADFS3 | 22:53 |
| marekd|away | or a mid cycle meetup. | 22:53 |
| gyee | mid cycle in Paris? | 22:54 |
| marekd|away | gyee: Geneva :-) | 22:54 |
| gyee | shit I would have to write an essay in the expense report | 22:54 |
| marekd|away | gyee: David Chadwick was proposing meetup in Geneva, so we could stay over the weekend and go skiing | 22:54 |
| marekd|away | i think henrynash would approve this idea | 22:55 |
| gyee | ++++++ | 22:55 |
| gyee | can we get a glimpse of the dark matter? :D | 22:55 |
| jamielennox | gyee: you can't see it, it's dark | 22:56 |
| gyee | ah | 22:56 |
| marekd|away | no, but you can get some Higgs Bosons (i have them too much in my belly) | 22:57 |
| gyee | heh | 22:57 |
| gyee | they did mention about that one in Ancient Alien TV series | 22:58 |
| marekd|away | ? | 22:58 |
| *** harlowja is now known as harlowja_away | 22:58 | |
| gyee | http://www.history.com/shows/ancient-aliens | 22:59 |
| marekd|away | ah | 22:59 |
| *** jistr|mtgs has quit IRC | 22:59 | |
| gyee | I think they mention Higgs Bosons in one of them | 23:00 |
| *** lihkin has quit IRC | 23:00 | |
| ayoung | telemonster, sorry, was in meetings | 23:03 |
| ayoung | telemonster, I think you lie: user probably does not have a role in a project...my guess is the userid that you think has the role in the project is not the userid from LDAP | 23:03 |
| gyee | jamielennox, https://review.openstack.org/#/c/131098/9/nova/api/auth.py line 144 | 23:06 |
| marekd|away | ok, going to bed | 23:06 |
| gyee | where's keystone.token_auth being set? | 23:06 |
| gyee | marekd|away, ttyl | 23:06 |
| *** edmondsw has quit IRC | 23:06 | |
| jamielennox | gyee: https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token.py#L755 | 23:08 |
| jamielennox | so auth_token provides a plugin for the current user session | 23:08 |
| jamielennox | user auth | 23:08 |
| *** nkinder has quit IRC | 23:08 | |
| jamielennox | which makes 90% of nova's context object redundant - if only i could make serialize work | 23:09 |
| gyee | jamielennox, got it, thanks | 23:09 |
| gyee | yep, good stuff | 23:09 |
| jamielennox | i talked to jogo at summit, and he suggested making the patch smaller - i don't know if it's worth seperating that context stuff out from the cinder stuff | 23:10 |
| jamielennox | also i need to figure out some way of dealing with the exceptions mess we currently have but i don't see how it's doable without breaking everything | 23:11 |
| gyee | ~300 loc is small | 23:11 |
| gyee | personal preference I suppose | 23:11 |
| *** ChanServ has quit IRC | 23:12 | |
| jamielennox | there are two logical changes, they just only make sense when used together | 23:12 |
| gyee | half of them are test code | 23:12 |
| gyee | I suppose you can separate out the register_conf_options part | 23:13 |
| *** ChanServ has joined #openstack-keystone | 23:15 | |
| *** sendak.freenode.net sets mode: +o ChanServ | 23:15 | |
| *** gordc has quit IRC | 23:17 | |
| ayoung | gyee, are you guys still pursuing tokenless operations in keystone? | 23:17 |
| *** henrynash has quit IRC | 23:17 | |
| gyee | ayoung, sure, for service users which uses SSL client cert auth, there's no need to use tokens | 23:18 |
| *** chrisshattuck has joined #openstack-keystone | 23:19 | |
| ayoung | gyee, so I have a similar use case right now: I need to create a service user that makes a call without a token, but that needs to do a policy check. How are you building the context to send to policy? | 23:20 |
| gyee | ayoung, just parse the cert attributes and feed them straight to policy check | 23:21 |
| ayoung | gyee, what about roles? | 23:21 |
| *** harlowja_away is now known as harlowja | 23:21 | |
| telemonster | ayoung - hmmm | 23:21 |
| telemonster | ayoung - how can I verify? | 23:21 |
| telemonster | userid = cloudadmin | 23:22 |
| telemonster | AD sAMAccountName = cloudadmin | 23:22 |
| gyee | ayoung, why even bother with roles, service user account is highly static | 23:22 |
| ayoung | gyee, need an RBAC check for the operation that the service user is performing. | 23:23 |
| ayoung | OK, if you guys aren't doing it, I'll figure out the right way to make it happen. | 23:23 |
| gyee | ayoung, policy is just attribute matching | 23:23 |
| telemonster | ayoung - also, I do notice that it takes the sAMAccountName (cloudadmin) and picks up the cn (OpenStack Admin) | 23:23 |
| telemonster | I'd hope it's not trying to use OpenStack Admin as the user? | 23:23 |
| telemonster | verifying against the SQL database | 23:23 |
| ayoung | telemonster, what does your ldap config have for the userid field | 23:24 |
| telemonster | user_id_attribute = cn | 23:24 |
| telemonster | user_name_attribute = sAMAccountName | 23:24 |
| telemonster | (keystone.conf) | 23:24 |
| telemonster | server is AD, not OpenLDAP so ... | 23:24 |
| telemonster | I swapped out user_id_attribute to sAMAccountName also and of course it failed | 23:25 |
| ayoung | telemonster, ok...there might be one thing...are you doing nested queries or onelevel | 23:26 |
| ayoung | the config option is... | 23:26 |
| ayoung | query_scope' | 23:26 |
| ayoung | defaults to 'one' | 23:26 |
| telemonster | currently set to sub | 23:27 |
| ayoung | this is...ugly | 23:27 |
| ayoung | OK, so wuith sub, you should be OK | 23:27 |
| ayoung | so what is your cn value? | 23:27 |
| ayoung | cn is "OpenStack Admin" | 23:28 |
| telemonster | Yea, the history was havana install was running but other issues, went icehouse, went back havana, havana doesnt work (But old install might of had other mods) | 23:28 |
| *** henrynash has joined #openstack-keystone | 23:28 | |
| *** ChanServ sets mode: +v henrynash | 23:28 | |
| ayoung | that is what it is expecting for the userid | 23:28 |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Update requests-mock syntax https://review.openstack.org/131380 | 23:28 |
| ayoung | telemonster, it looks like you want user_id_attribute = sAMAccountName | 23:28 |
| telemonster | Is that a new option? | 23:28 |
| telemonster | oh hmp | 23:29 |
| telemonster | With that set I think it fails user/pass but let me try | 23:29 |
| ayoung | telemonster, when I do ldap, I usually set userid and username to the uid field. | 23:29 |
| telemonster | yea AD is a bit different | 23:29 |
| telemonster | we have 20 or so other services authing off of it, although future we might move to linux or Apple Opendirectory | 23:30 |
| ayoung | telemonster, but in your assignment table, you would look for something where the "target" value matches user_id_attribute | 23:30 |
| ayoung | so if cn = "OpenStack Admin" that is what you would need in that table | 23:30 |
| *** dims_ has joined #openstack-keystone | 23:31 | |
| ayoung | and it sounds like you have cloudadmin there | 23:31 |
| telemonster | okay with user_id_attribute sAMAaccountname and name = cn, it wont allow login | 23:32 |
| telemonster | and I tried the long name | 23:32 |
| telemonster | Ill revert keystone coofnig back, and steal the CN value from the debug output on keystone console and see if I can stuff it in the database | 23:32 |
| *** henrynash has quit IRC | 23:33 | |
| *** dims has quit IRC | 23:34 | |
| telemonster | put_filter: "(&(cn=OpenStack Admin)(objectclass=person))" | 23:34 |
| telemonster | I just swapped the field in the user table for name ... and it still gives me the "you are not authorized for any projects" on the web ui. Pretty strange | 23:38 |
| *** marcoemorais has quit IRC | 23:39 | |
| *** marcoemorais has joined #openstack-keystone | 23:39 | |
| *** thedodd has quit IRC | 23:40 | |
| *** marcoemorais has quit IRC | 23:40 | |
| *** marcoemorais has joined #openstack-keystone | 23:40 | |
| ayoung | telemonster, can you get a token from Keystone? | 23:41 |
| *** marcoemorais has quit IRC | 23:42 | |
| telemonster | token-get fails with a http auth | 23:42 |
| *** marcoemorais has joined #openstack-keystone | 23:42 | |
| ayoung | telemonster, what the UI does is 1. gets an unscoped token (cuz it is LDAP and there is no default project) then list projects, then selects the first one | 23:42 |
| ayoung | Start by getting an unscoped token using keystone token-get | 23:42 |
| ayoung | if you don't set OS_TENANT_NAME or OS_PROJECT_NAME or anything comparable, it should get a token with no project data | 23:43 |
| telemonster | yea the tenantname is set to admin | 23:43 |
| telemonster | but let me see if I unset that if it works? | 23:43 |
| ayoung | you can also do this via CURL if you really want to lock down to the specifics, but lets not go there yet | 23:43 |
| telemonster | yea it worked | 23:45 |
| *** marcoemorais has quit IRC | 23:45 | |
| ayoung | OK, and it shows you your user id? | 23:45 |
| telemonster | yea OpenStack Admin, but I modded it in the db | 23:45 |
| ayoung | that makes no sense | 23:46 |
| ayoung | it did not do any DB calls for that | 23:46 |
| ayoung | only LDAP | 23:46 |
| telemonster | oh okay | 23:46 |
| *** marcoemorais has joined #openstack-keystone | 23:46 | |
| ayoung | so your userid is "OpenStack Admin" | 23:46 |
| ayoung | telemonster, now, in your DB, do the following: | 23:46 |
| ayoung | 1. select * from roles; | 23:47 |
| *** gokrokve has joined #openstack-keystone | 23:47 | |
| ayoung | make sure you actually have the right role_id for your assignment table | 23:47 |
| ayoung | 2. select * from assignment where actor_id = "OpenStack Admin"; | 23:47 |
| telemonster | there is no entry in the role table for the cloudadmin user | 23:47 |
| telemonster | no assignment table | 23:48 |
| ayoung | what are you running? | 23:48 |
| telemonster | under keystone db | 23:48 |
| telemonster | havana | 23:48 |
| ayoung | what version of openstack | 23:48 |
| telemonster | ... :-) 1 sec | 23:48 |
| telemonster | keystone is version 0.7.1 | 23:49 |
| ayoung | Dude, you guys need to stop panicking and running back to old versions. Seriously.... | 23:49 |
| telemonster | We were on an old version | 23:49 |
| ayoung | telemonster, didn't you roll forward to Juno at one point? Or at least Icehouse? | 23:50 |
| telemonster | yes we were on icehouse, but hit a wall with the ldap and the (hope) was rolling back to where we were-- it would work again | 23:50 |
| telemonster | the boss calls this, and this is a long outage with impacts and upset people | 23:51 |
| ayoung | OK...lets get you running again.... | 23:52 |
| telemonster | the guy that set this stuff up quit and went to work for a consulting company | 23:52 |
| telemonster | :-) | 23:52 |
| ayoung | actually, I think he works here | 23:52 |
| telemonster | So I should swap out the cloudadmin with 'OpenStack Admin' (sAMAccountName to cn conversion) | 23:52 |
| ayoung | telemonster, not necessarily | 23:53 |
| ayoung | right now you know that you can get an unscoped token with what you have working. | 23:53 |
| telemonster | correct | 23:53 |
| telemonster | (He works for Mirantis, looked it up) | 23:53 |
| ayoung | I don't think you want to change what is being used for the userid across the cloud. It probably would only affect Keystone and swift | 23:53 |
| ayoung | but the userid is not used in Nova AFAICT | 23:54 |
| ayoung | ah...so not our guy...ok | 23:54 |
| telemonster | we like to use what is in the sAMAccountName field of LDAP | 23:54 |
| telemonster | That's how it has been | 23:54 |
| ayoung | telemonster, ok, then that should be the userid field in the LDAP config | 23:54 |
| ayoung | and it makes sense | 23:54 |
| ayoung | lets at least get things working with that. | 23:55 |
| ayoung | make that change, and make sure that once again you can get an unscoped token | 23:55 |
| telemonster | Changed to this: | 23:56 |
| telemonster | user_id_attribute = sAMAccountName | 23:56 |
| telemonster | user_name_attribute = cn | 23:56 |
| telemonster | and now token get fails | 23:56 |
| ayoung | you need to reset the env vars | 23:57 |
| ayoung | set OS_USER_ID=to the sAMAccountName | 23:57 |
| *** boris-42 has quit IRC | 23:57 | |
| ayoung | Not sure what happens if username has a space in it, but you should be able to do OS_USERNAME="..." too | 23:57 |
| ayoung | or just set them both to sAMAccountName | 23:58 |
| telemonster | OS_USERNAME or OD_USER_ID ? | 23:58 |
| ayoung | telemonster, lets start with user_ID... | 23:58 |
| ayoung | set that to the sAMAccountName | 23:58 |
| telemonster | do those represent the two fields use by the auth? | 23:58 |
| ayoung | Yeah, horizon uses the username to login | 23:58 |
| ayoung | you can get a token using either one | 23:58 |
| telemonster | okay OS_USERNAME is set to cloudadmin | 23:59 |
| telemonster | pass and url are set | 23:59 |
| telemonster | failed | 23:59 |
| *** gokrokve has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
