Friday, 2016-12-09

*** ayoung has quit IRC00:05
*** jamielennox|away is now known as jamielennox00:08
*** spzala has joined #openstack-keystone00:15
*** tobberydberg has joined #openstack-keystone00:19
*** adrian_otto has joined #openstack-keystone00:29
*** tobberydberg has quit IRC00:32
*** harlowja_ has quit IRC00:32
*** chrisplo has joined #openstack-keystone00:34
*** chrisplo_ has quit IRC00:36
*** adrian_otto has quit IRC00:37
*** spzala has quit IRC00:38
*** adrian_otto has joined #openstack-keystone00:41
*** diazjf has quit IRC00:41
*** harlowja has joined #openstack-keystone00:51
*** diazjf has joined #openstack-keystone00:52
*** hoangcx has joined #openstack-keystone00:57
*** tobberydberg has joined #openstack-keystone00:58
*** ayoung has joined #openstack-keystone00:58
*** ChanServ sets mode: +v ayoung00:58
*** tobberydberg has quit IRC01:04
*** jamielennox is now known as jamielennox|away01:04
*** spzala has joined #openstack-keystone01:07
openstackgerritMerged openstack/keystone: Expose idempotency issue with bootstrap
*** chris_hultin|AWA is now known as chris_hultin01:12
*** adrian_otto has quit IRC01:15
*** chris_hultin is now known as chris_hultin|AWA01:18
*** jamielennox|away is now known as jamielennox01:20
*** guoshan has joined #openstack-keystone01:21
*** jrist has quit IRC01:21
*** liujiong has joined #openstack-keystone01:21
*** markvoelker has quit IRC01:22
*** markvoelker has joined #openstack-keystone01:27
*** tqtran has quit IRC01:33
*** jrist has joined #openstack-keystone01:34
*** Marcellin__ has quit IRC01:39
*** browne1 has quit IRC01:51
*** tobberydberg has joined #openstack-keystone02:01
*** diazjf has quit IRC02:14
*** tobberydberg has quit IRC02:14
*** zhangjl has joined #openstack-keystone02:28
openstackgerritgengchc2 proposed openstack/keystoneauth: Replace six.iteritems() with .items()
*** tobberydberg has joined #openstack-keystone02:41
*** tobberyd_ has joined #openstack-keystone02:49
*** tobberydberg has quit IRC02:52
*** tobberyd_ has quit IRC02:54
*** harlowja has quit IRC02:55
*** tobberydberg has joined #openstack-keystone03:20
*** dave-mccowan has quit IRC03:25
*** links has joined #openstack-keystone03:29
openstackgerritSteve Martinelli proposed openstack/keystone-specs: clean up approved specs for ocata
*** jrist has quit IRC03:30
stevemarlbragstad: when you eventually see this, take a look at
*** rdo has quit IRC03:30
*** tobberydberg has quit IRC03:31
*** diazjf has joined #openstack-keystone03:31
*** jrist has joined #openstack-keystone03:33
*** rdo has joined #openstack-keystone03:33
*** diazjf has quit IRC03:39
*** guoshan has quit IRC03:55
*** tovin07 has quit IRC03:55
*** tovin07 has joined #openstack-keystone03:56
*** adriant has quit IRC03:56
*** tobberydberg has joined #openstack-keystone03:57
*** agrebennikov_ has joined #openstack-keystone03:58
*** tobberydberg has quit IRC04:02
*** udesale has joined #openstack-keystone04:06
*** nicolasbock has quit IRC04:08
*** spzala has quit IRC04:23
*** tovin07 has quit IRC04:31
*** tovin07 has joined #openstack-keystone04:32
openstackgerritMerged openstack/keystone: Make bootstrap idempotent when it needs to be
*** links has quit IRC04:54
*** guoshan has joined #openstack-keystone04:56
*** tobberydberg has joined #openstack-keystone04:58
*** guoshan has quit IRC05:00
*** links has joined #openstack-keystone05:09
*** tobberydberg has quit IRC05:11
*** sc68cal has quit IRC05:12
*** madhaviy has joined #openstack-keystone05:12
*** sc68cal has joined #openstack-keystone05:24
*** tqtran has joined #openstack-keystone05:31
*** tqtran has quit IRC05:35
*** tobberydberg has joined #openstack-keystone05:38
*** tobberydberg has quit IRC05:43
*** GB21 has joined #openstack-keystone05:52
*** guoshan has joined #openstack-keystone06:09
*** guoshan has quit IRC06:13
*** guoshan has joined #openstack-keystone06:15
*** spzala has joined #openstack-keystone06:24
*** spzala has quit IRC06:29
openstackgerritRichard Avelar proposed openstack/keystone: Add doctor check for security_compliance
*** tobberydberg has joined #openstack-keystone06:39
*** richm has quit IRC06:41
*** agrebennikov_ has quit IRC06:50
*** tobberydberg has quit IRC06:52
*** jaosorior has joined #openstack-keystone07:00
*** tesseract has joined #openstack-keystone07:07
*** tesseract is now known as Guest9999707:07
*** GB21 has quit IRC07:09
*** Guest99997 is now known as tesseract-07:13
*** tobberydberg has joined #openstack-keystone07:19
*** GB21 has joined #openstack-keystone07:21
*** guoshan has quit IRC07:22
*** tobberydberg has quit IRC07:23
*** rcernin has joined #openstack-keystone07:28
*** guoshan has joined #openstack-keystone07:30
*** GB21 has quit IRC07:34
*** tqtran has joined #openstack-keystone07:34
*** tqtran has quit IRC07:39
*** GB21 has joined #openstack-keystone07:45
*** Dinesh_Bhor has quit IRC07:49
*** GB21 has quit IRC07:55
*** jaosorior has quit IRC07:55
*** jaosorior has joined #openstack-keystone07:55
*** jaosorior has quit IRC08:00
*** jaosorior has joined #openstack-keystone08:02
*** pnavarro has joined #openstack-keystone08:02
*** udesale has quit IRC08:07
*** pcaruana has joined #openstack-keystone08:16
openstackgerritRichard Avelar proposed openstack/keystone: Add id to conflict error if caused by duplicate id
openstackgerritShan Guo proposed openstack/keystone: Fix typo in api-ref doc
*** tobberydberg has joined #openstack-keystone08:20
*** tobberyd_ has joined #openstack-keystone08:27
*** tobberydberg has quit IRC08:30
*** tobberyd_ has quit IRC08:32
*** henrynash has joined #openstack-keystone08:37
*** ChanServ sets mode: +v henrynash08:37
*** henrynash has quit IRC08:52
*** udesale has joined #openstack-keystone08:54
*** udesale has quit IRC08:54
*** udesale has joined #openstack-keystone08:55
*** udesale has quit IRC08:56
*** udesale has joined #openstack-keystone08:57
*** tobberydberg has joined #openstack-keystone08:58
*** tobberydberg has quit IRC08:59
*** zzzeek has quit IRC09:00
*** tobberydberg has joined #openstack-keystone09:00
*** zzzeek has joined #openstack-keystone09:00
*** namnh has joined #openstack-keystone09:05
*** tqtran has joined #openstack-keystone09:36
*** tqtran has quit IRC09:40
*** GB21 has joined #openstack-keystone09:49
*** davechen has quit IRC09:56
*** eandersson has quit IRC10:03
*** liujiong has quit IRC10:06
*** zhangjl has left #openstack-keystone10:21
*** tovin07 has quit IRC10:22
*** guoshan has quit IRC10:24
*** hoangcx has quit IRC10:30
*** GB21 has quit IRC10:39
openstackgerritJulia Varlamova proposed openstack/keystone: Change DevStack plugin to setup multi-Keystone
*** jaosorior is now known as jaosorior_lunch11:00
*** GB21 has joined #openstack-keystone11:01
*** richm has joined #openstack-keystone11:11
*** madhaviy has quit IRC11:13
*** henrynash has joined #openstack-keystone11:21
*** ChanServ sets mode: +v henrynash11:21
*** madhaviy has joined #openstack-keystone11:22
*** spzala has joined #openstack-keystone11:24
*** spzala has quit IRC11:29
*** nicolasbock has joined #openstack-keystone11:35
*** david-lyle_ has joined #openstack-keystone11:35
*** tqtran has joined #openstack-keystone11:37
*** tsufiev has left #openstack-keystone11:37
*** david-lyle has quit IRC11:37
*** tqtran has quit IRC11:41
*** edmondsw has joined #openstack-keystone11:47
*** jaosorior_lunch is now known as jaosorior11:55
*** edmondsw_ has joined #openstack-keystone12:02
*** henrynash has quit IRC12:02
*** edmondsw_ has quit IRC12:03
*** dikonoor has joined #openstack-keystone12:09
*** dave-mccowan has joined #openstack-keystone12:09
*** guoshan has joined #openstack-keystone12:10
*** namnh has quit IRC12:12
*** zhangjl has joined #openstack-keystone12:14
*** raildo has joined #openstack-keystone12:17
dikonoorstevemar: Hi Steve..12:22
dikonoorstevemar: I am looking on information related to
dikonoorstevemar: basically on if the community has arrived at any conclusion on how to deal with resource clean up when project is deleted12:23
dikonoorayoung: dolphm: anyone has the latest on this ?12:24
bretondikonoor: nothing has actually been implemented12:25
bretondikonoor: people use ospurge sometimes12:25
dikonoorbreton : ok.. So anyone who wants to go about with the clean up has the option to use only ospurge. Are there any blueprints or anything else planned ?12:26
*** jamielennox is now known as jamielennox|away12:33
bretondikonoor: i'd say there is nothing until someone actively works on it. I don't know anybody who would work in it.12:35
dikonoorbreton : ok..12:37
dikonoorbreton : A similar problem would happen with userid as well12:38
dikonoorDo you know if orpurge handles that as well ?12:38
*** GB21 has quit IRC12:40
bretondikonoor: don't know12:40
*** zhangjl has quit IRC12:50
*** pcaruana has quit IRC13:05
*** pcaruana has joined #openstack-keystone13:08
samueldmqmorning keystone13:10
*** asettle has quit IRC13:18
*** asettle has joined #openstack-keystone13:19
ayoungdikonoor, it is an intractable problem. We do not know all of the systems out there, or what resources they have, nor what is the safe way to delete them.  The only approach would be to reguster tasks with something like mistral that are run based on notifications from Keystone13:24
*** maestropandy has joined #openstack-keystone13:31
*** maestropandy has left #openstack-keystone13:31
*** maestropandy has joined #openstack-keystone13:39
*** maestropandy has left #openstack-keystone13:39
*** tqtran has joined #openstack-keystone13:39
*** tqtran has quit IRC13:43
openstackgerritSamuel Pilla proposed openstack/keystone: API Documentation for user password expires
openstackgerritJulia Varlamova proposed openstack/keystone: Change DevStack plugin to setup multi-Keystone
*** boris-42 has quit IRC13:51
*** spzala has joined #openstack-keystone13:51
*** boris-42 has joined #openstack-keystone13:51
*** narasimha_SV_ has joined #openstack-keystone13:58
edmondswayoung dstanek lbragstad stevemar I added my comments to
ayoungedmondsw, I saw.  I was just about to address13:58
edmondswjust finished, so there are more than what I saved yesterday13:59
ayoungedmondsw, details aside, when we discussed you were pretty set against it.13:59
edmondswI wouldn't say that13:59
edmondswI am very against certain portions, but not most of it13:59
ayoungedmondsw,  well, the whole thing has to fall together in order to work.  Is there anything there that you feel absolutely must be changed, and how?14:00
*** daemontool has joined #openstack-keystone14:00
edmondswone is that you have to allow multiple roles per API14:01
edmondswthere's no reason to restrict that to a singe role14:01
edmondswthere are plenty of reasons not to14:01
ayoungedmondsw, OK lets start there14:01
*** lunarlamp is now known as mariusv14:02
edmondswayoung go through the comments let's whittle them down... there are a bunch of things that should just be simple edits for you, like fixing spelling or clarifying something14:02
ayoungedmondsw, I can do that, but I want to address the "stop ship" elements14:02
ayoungedmondsw, I originally had it as multiple roles.  It is possible to do, just adds a slew of complexity, but that was not the real reason14:03
edmondswabsolutely... when you go through the comments and come to one of those, if what I said in the comment didn't convince you, ping me and we'll talk14:03
edmondswwhat complexity does it add?14:03
edmondswkinda seems the opposite to me...14:03
ayoungedmondsw, so one goal here is to provide a means to delegate to a subset of operations.  And in order to do that, there needs to be some hierarchy from the roles a user is assigned to the roles that map to an operation.  Today that mapping is direct.14:04
ayoungI want to add exactly one mechanism for indirect mapping14:04
edmondswI could tell you must have originally had it as multiple roles, because several of my comments were "hey, this is a place that still says multiple roles :)"14:04
ayoungso your big complaint, as I understand it, is that adding additional "roles" messes up UX14:05
edmondswayoung "exactly one mechanism for indirect mapping" ?14:05
edmondswayoung, that would be one argument14:05
ayoungedmondsw, right.  If we put two or more roles directly into the map for an operation, we have 2 mechanisms;14:05
narasimha_SV_any one working on LDAP integration for keystone ?????????????????14:06
ayoungedmondsw, and, you commented that "roles" are actually "permissions"14:06
ayoungnarasimha_SV_, many people, but hold on for a moment, please14:06
edmondswthey should not be... you seem to be confusing the two in places14:06
ayoungedmondsw, the permission is what I am currently callin an api_role:  this role allows access to this api.14:07
ayoungI didn;t want to use the term "permission" because14:07
ayoungit has the potential to be wrong14:07
ayoungthe permission is also what the policy file allows14:07
rodrigodsknikolla, hey... think that for the federation plugin we just need to export the configs for the tempest plugin test and we are done14:07
ayoungand might even be a lower level thing than that...14:07
edmondswayoung right... api_role is part of a permission14:08
*** hrybacki has quit IRC14:08
ayoungright "part"14:08
*** hrybacki has joined #openstack-keystone14:08
ayoungI also did not want to introduce a new concept, nor rename an existing one14:08
ayoungI don't think I would have picked "role" from a blank slate14:08
ayounghenry's domain specific roles are more like traditional roles14:08
edmondswayoung not sure where you're going here...14:08
ayoungthe roles as implemented here are the middle layer of indirection14:09
ayoungbut I stuck with the term14:09
ayoungedmondsw, one big goal here is delegation14:09
ayoungI want someone to be able to say "I have the member role, but I want to be able to delegate just the ability to reboot a virtual machine"14:09
edmondswsure... but allowing/supporting delegation does not mean you have to require there only be one role allowed to do something14:10
ayoungif we say "rebooting a virtual machine requires either the member role or the reboot role" there is not relationship between the two, and you cannot delegate just that smaller role, or just that operation14:10
ayoungit is the relationship that is important14:10
edmondswayoung wait and let me answer that14:11
edmondswthere's really no problem there14:11
ayoungso, providing a middle layer, that can be changed without breaking existing workflows is essential14:11
ayoungand without having to explicitly assign new roles to everyone in order for them to delegate14:11
ayounglots of constraints here.14:11
ayoungGo ahead14:11
edmondswI'm not saying you can't create a new compute_server_delete role if you want, and make that implied by member, and then update api_roles to refer to that. I'm saying you shouldn't HAVE TO14:12
*** agrebennikov_ has joined #openstack-keystone14:12
edmondswmake sense?14:12
edmondswayoung ^14:14
ayoungedmondsw, I think I would like you to be more explicit on what the problems are of requiring that14:14
ayoungwhere would it mess people up.14:14
ayoungignoring the UX issue.14:14
ayoungWe can solve UX a different way if it proves to be a problem14:15
edmondswif I want to use implied roles and then have api_roles simplified down to a single role, great. Someone else should be allowed to instead specify multiple roles in their api_roles rule14:15
edmondswkeystonemiddleware shouldn't care which approach you want to take14:15
edmondswby making it a list, you leave that up to the deployers to decide14:15
edmondswso problems or requiring a single role:14:16
edmondsw1) you now require folks who have multiple roles that need to do x to have all those roles linked in an implied role hierarchy... which may deployers (e.g. me) will not be able to do without creating a bunch more roles than they have today to serve as intermediaries14:17
edmondswmore roles leads to a lot of problems. If you want to take those on in your deployment, be my guest, but I don't want to do that in mine14:18
edmondswmore roles leads to the problems you alluded to in the spec with larger token responses. It leads to worse UX, etc.14:18
edmondswnarasimha_SV go ahead and throw out your question14:20
ayoungedmondsw, so that, to me, all resolves to UX14:20
ayoungif we could hide the lowest level roles from the normal UX flow, the mechanism would be the same14:21
edmondswlarger token responses leads to perf issues, code complexity... not just UX14:21
ayoungedmondsw, so, not in the token14:21
ayoungthe implied roles will only get expanded in the api_role fetch14:21
edmondswI don't think you can hide them effectively14:21
edmondswayoung I addressed why that won't work in my comments14:22
edmondswbreaks the caching model14:22
ayoungedmondsw, if we tag a role as 'internal' and say that list_roles does not show them unless you pass internal=true14:22
ayoungedmondsw, you mean because someone could update the roles and the fetch would not know about them until next fetch?14:22
*** andrewbogott has quit IRC14:23
*** andrewbogott has joined #openstack-keystone14:23
*** andrewbogott has quit IRC14:23
*** andrewbogott has joined #openstack-keystone14:23
edmondswayoung, oh, maybe I'm wrong about the caching issue...14:24
edmondswthe cached token would have some role, e.g. compute_delete_server14:25
ayoungedmondsw, one question, though, is do you really envision the need to delegate each individual operation? I suspect that what we really are going to have is a handful of operations that need to be isolated, but most would be OK with "Member".  I just don't want to build too much mechanism up front: I'd rather let the complexity emerge14:26
edmondswbut whatever checks the cache to see if a token it has is valid should be ok if it doesn't look at the role on the cached token... it should only look at the role on the token it actually received14:26
ayoungIf it turns out that we do need multiple, non-implied roles per API we can relax the uniqueness constraint on the API portion:14:27
edmondswayoung remember that I don't even have a member role14:27
ayoungthat GET + VERB has to be unique14:27
ayoungedmondsw, I did not know that.14:27
ayoungedmondsw, you have to give me some sense of your layout if you want me to take your setup into account.14:28
edmondswthought I said that the other day... I have admin, deployer, viewer, vm_manager, vm_user, image_manager, project_manager, storage_manager, etc.14:28
edmondswe.g. vm_user can only work with an existing VM (start, stop, that kind of thing) but can't actually create/delete it, etc.14:29
ayoungedmondsw, so  you have a manager role per service, or is it per resource?14:30
edmondswno, I don't have a role per service14:30
ayoungwell, storage_manager is cinder specific, I assume14:31
edmondswclose, but not quite14:31
ayoungedmondsw, so is it "reader" that messes you up, as it is a cross cutting concern?14:31
ayoungi.e. storage_manager should not be able to read vm's etc?14:32
edmondswa lot of them are cross-cutting14:32
edmondswright storage_manager doesn't have access to VMs14:32
ayoungso for reader, my approach would force you to create vm_reader, and then reader implies vm_reader, storage_reader etc14:33
ayounga bunch of roles that you would not assign on their own14:33
edmondswbut then what do I do about storage_manager?14:34
ayoungstorage_manager would imply storage_reader14:35
ayoungits a DAG, not a strict hierarchy14:35
edmondswthat might work for the reader stuff14:37
edmondswI think I've have more issues with other cases14:37
edmondswlots of rules are currently "role:x or role:y or role:z" but then another place is "role:x or role:y or role:a", etc.14:38
edmondswI can try to find a way to map those out using implied roles and see what I can come up with... that's a todo for me14:39
edmondswbut I still don't understand your reluctance to just allow multiple roles api_roles14:39
edmondswI don't see how that adds complexity as you claim14:39
*** dikonoor has quit IRC14:39
ayoungedmondsw, it was as I was going through the implementation details14:42
*** pcaruana has quit IRC14:42
edmondswayoung can you elaborate?14:43 sec...making coffee, too14:43
edmondswthis should be spelled out in the alternatives section14:43
ayoungedmondsw, so  I think that "multiple explicit roles per api" is possible as a follow on to this spec without too much extra work14:44
ayoungit started with me having APIs top manage two objects, and it was confusing14:44
ayoungif it was confusing to me, imaging how it would be to new users14:44
edmondswayoung then there must not be any reason not to just do it in this spec ;014:44
ayoungwell, hold on14:44
edmondsw"APIs to manage two objects" ??14:44
*** GB21 has joined #openstack-keystone14:45
ayoungyeah, the two objects were14:45
ayoung1.  the API objkect14:45
ayoungVERB + URL14:45
ayoungVERB + URL + SERVER actually14:45
ayoungthe second was API to Role14:45
edmondswwhy is that 2nd an object at all?14:45
ayoungedmondsw, so, if I loosened that constraint, made it possible to have multiple roles explicitly assigned to the API, that would address your biggest concern?14:46
edmondswwhy isn't the role infomation in the first object, so you only have one object?14:46
edmondswayoung I think that was the biggest, now let me go back and check again14:46
ayoungedmondsw, yes, that is a better implementation14:46
ayoungedmondsw, OK, I think I can make that work.  It means that we need decent semantics for how to remove/change api_roles14:47
edmondswayoung another objection was the inclusion of admin_project_only. That is a scope check and you lay this out as specifically being only a role check and leaving scope to the services to work out14:47
edmondswif we understand admin_project_only is a hack but really want to do it anyway for some reason, those reasons need to be clearly spelled out. And I would argue it should be a separate spec14:49
ayoungedmondsw, yeah.  I waffled on that14:49
ayoungI *think* we can safely remove that14:49
edmondswanother was my comment at line 18214:49
*** cargonza has quit IRC14:50
edmondswthe action APIs are a good example of where middleware role checks will not really do any good. Doesn't mean we can't do it for everything else's sake, but we should understand that policy.json/yaml editing will still be necessary for those14:50
*** cargonza has joined #openstack-keystone14:50
ayoungedmondsw, agreed14:50
edmondswI'd want some words about that in the spec14:51
ayounga lot of stuff done in policy.json is outside of RBAC.  I was not trying to solve everything here14:51
edmondswso people understand14:51
edmondswyeah, but this touches on what you ARE trying to solve :)14:51
edmondswwhich is why I think it should just be discussed14:51
edmondswno implementation changes, just discussed14:51
edmondswayoung another thing was in one place (line 241) you mentioned there would be new headers, but didn't say what or why... I don't see the need... what were you thinking there?14:52
ayoungedmondsw, yeah.  that confused people before too. That is explaining what actually happens today14:53
ayoungthey are not new headers, that is how Middleware communicates with the follow on layer14:53
ayoungwith the service14:53
*** raddaoui has quit IRC14:53
edmondswso just some clarification needed there it sounds like14:53
*** raddaoui has joined #openstack-keystone14:53
ayoung"there is no change" was my last attempt to do that.14:54
ayoungI'll try again14:54
edmondswayoung there were some comments around the way we handle defaults14:54
ayoungedmondsw, one possibility there14:54
ayoungwe could hook into the service catalog API14:54
ayoungwhen a service is created, we push in a default api_role based on the default role set in the keystone.conf14:55
edmondswI think that it should not be necessary to set api_roles for every service before you can start using this... one should be sufficient and any service which doesn't have api_roles set just works as it does today14:55
edmondswi.e., the default when you haven't explicitly set a default is to allow all14:55
ayoungwell, if they don't enable the RBAC check in the config file, it will.  But you are saying if they enable it, but have not posted any specific api_roles, it should still work14:55
ayoungOK,  here is what I was thinking14:56
ayoungwe have a default api_role like this:14:56
andreafAround Nov 20 the identity v2 own pwd reset test suddenly started taking almost double as run - I was looking for a change in Tempest that could explain but I found nothing - does this ring a bell to anyone?14:56
*** pcaruana has joined #openstack-keystone14:56
andreafThe matching v3 test is ok
ayoungSERVICE: ANY, PATTERN:ANY, ROLE:None.  When we fetch for a service, and there are no specific api_roles for that service, append that one instead14:57
ayoungedmondsw, I think that has the effect you are looking for14:57
*** AndyWojo has quit IRC14:58
*** AndyWojo has joined #openstack-keystone14:58
edmondswI actually liked your "default" in the example at line 199 better than that ANY stuff at line 26714:58
ayoungthe thing I don't like is that, if we do multiple api_roles per API, we have to OR them together.  This one would be "AND NOT"14:58
edmondswbut yeah14:58
ayoungwe need the ANY stuff, too14:58
edmondswthe ANY would be implicit, and understood in code14:59
edmondswremoves the issues of a user mucking with it14:59
edmondswdefault == ANY... it can't equal anything else14:59
ayoungedmondsw, but a sysadmin might need to remove that later for compliance14:59
*** links has quit IRC14:59
edmondsw"multiple api_roles together" ?15:00
ayoungwould rather not make it hard coded15:00
ayoungedmondsw, impl detai15:00
ayoungsay GET /v2/thing  is Member to start15:00
ayoungand you want a thingy role15:00
ayoungso you could add an additional api_role15:00
edmondswI'm not saying you can't change the default... you certainly can, as line 199 would allow... you can't just change what the definition of default is... default's definition is ANY verb, ANY pattern15:01
ayoungGET /v2/thing would then return roles [Member, thingy]15:01
ayoungI do want per service defaults, and a global too15:01
edmondswline 199 allows for that15:01
ayoungwe need a way to admin it, too, though15:02
ayoungOK,  I think I need 2 variations on the bulk fetch API15:03
ayoung1 used for enforcement, one for admin15:03
ayoungimplementation detail15:03
ayoungI want to be able to distinguish between15:03
ayoung321abc GET /v2/thing  and 987bcd GET /v2/thing15:04
ayoungIf I want to delete only15:04
ayoung 987bcd GET /v2/thing  role:thingy15:04
edmondswwhat are 321abc and 987bcd there?15:04
ayoungI should be able to to that15:04
ayoungthose are the api_role['id'] values15:04
edmondswwhy would there be 2 for the same API?15:05
ayoungedmondsw, so there is def a need to specify the upgrade workflow here15:05
ayoungwhat do we do when a new version of nova comes out with more apis15:05
edmondswlist that under deployer impacts15:05
*** tobberyd_ has joined #openstack-keystone15:06
edmondswthey would need to understand that the default rule will be used for new APIs until they specify an explicit rule15:06
ayoung id: 987bcd verb:GET /pattern:v2/thing role:thingy  vs id:321abc verb:GET pattern:/v2/thing role:member15:06
edmondswno no no15:07
edmondsw987bcd verb:GET /pattern:v2/thing role:['thingy','member']15:07
ayoungbut then your workflow needs to know the existing roles in order to be able to update it15:07
edmondswnot necessarily15:08
*** tobberydberg has quit IRC15:09
edmondswuse POST and have the body specify what you want to remove from where15:09
ayoungPATCH /v3/api_role/987bc  body={role: member}15:09
ayoungor better15:09
*** henrynash has joined #openstack-keystone15:09
*** ChanServ sets mode: +v henrynash15:09
ayoungPATCH /v3/api_role/987bc  body={add_roles: [member], delete_roles:[thingy]}15:09
ayoungbut nothing we have works like that now15:09
*** tobberyd_ has quit IRC15:10
edmondswayoung I would suggest that the global default be to allow all (so that it's ok if you're not setting api_roles on some services), but that the project-specific default (if they create api_roles for that project but don't specify a default) be admin15:13
ayoungedmondsw, trying to avoid POST except for creating a new one15:13
edmondswayoung yeah, if you use POST it would need to be something like /v3/api_roles/edit and I'm not a huge fan but it can work15:14
edmondswif you can make PATCH work, that's probably better15:14
ayoungedmondsw, Yeah, my understanding is that, on a given api_role PUT should erase the old set of roles and replace with the given set.  PATCH should allow modifications of the set by element.15:16
ayoungDELETE should remove the whole pattern15:16
edmondswayoung that is correct. It's not how OpenStack does things, but it's how REST is supposed to work :)15:16
*** henrynash has quit IRC15:16
*** pkoraca has quit IRC15:17
edmondswI should say it's not how MOST OpenStack APIs work... a few do15:17
edmondswand more power to them, and we should add to that list15:17
*** henrynash has joined #openstack-keystone15:17
*** ChanServ sets mode: +v henrynash15:17
*** pkoraca has joined #openstack-keystone15:17
ayoungedmondsw, so, omne thing I need to sort is to make it clear which are explicitly assigned roles and which are implied.15:17
*** henrynash has quit IRC15:18
ayoungthe use case is "I want to know what roles I need to delegate to someone else in order to perform this operation"15:18
ayoungideally, you would pass the complete URL (or  the section) to Keystone and it would pass you back the roles, but I think doing a fetch and a match to start makes sense15:19
edmondswyou mean fetch the whole list of api_roles?15:20
*** clsacramento has quit IRC15:24
*** robcresswell has quit IRC15:24
*** robcresswell has joined #openstack-keystone15:25
*** lamt has joined #openstack-keystone15:25
*** guoshan has quit IRC15:26
ayoungedmondsw, for a service15:27
ayoungedmondsw, same as the middleware would have to do to enforce15:27
edmondswyeah... I agree that ideally you'd be able to just specify which URL you want to know about, but fetching the whole thing might be ok to start with15:28
edmondswwould want to write the code that does the fetch/match in such a way that other things could use it, for cases like this15:29
edmondswI think we went through my most significant comments. Progress!15:29
dstanekayoung: why is url better than just the operation? like nova:boot_vm15:32
*** chris_hultin|AWA is now known as chris_hultin15:33
*** daemontool has quit IRC15:33
*** ravelar has joined #openstack-keystone15:34
*** jaosorior has quit IRC15:35
*** narasimha_SV_ has quit IRC15:41
*** ravelar has quit IRC15:42
*** chris_hultin is now known as chris_hultin|AWA15:43
edmondswdstanek I assumed it's because the middleware is told the URL, and wouldn't know how to map that to nova:boot_vm15:43
edmondswayoung ^15:44
dstanekedmondsw: something has to map url to operation though...and i don't think it should be the cloud admin doing that in keystone15:44
dstaneki'd rather a service have to be responsible for maintaining that map15:44
edmondswit's not15:44
edmondswthe service is doing that15:44
edmondsweven without this middleware, the service does that today, right?15:45
dstanekedmondsw: as an admin if i was to change the role used for an operation i have to know the url and http method15:45
edmondswthat wouldn't change15:45
edmondswwhich you would know, right?15:45
dstaneki think that's terrible and violates REST15:45
edmondswbecause the APIs is how you interact with the service... that's the contract15:45
dstaneki don't know that now, but i can change policy15:46
edmondswif you want to use something like boot_vm, that "boot_vm" is actually something new that the user won't understand and will have to lookup which API that maps to15:46
edmondswdstanek policy should have also worked this way... the fact that it doesn't is a knock on the guys that implemented policy15:46
edmondswthey weren't thinking about UX, clearly15:47
*** chris_hultin|AWA is now known as chris_hultin15:47
dstanekwhy do i ever have to know the URL. in a real RESTful system the URLs could change15:47
*** ravelar has joined #openstack-keystone15:48
edmondswthe only time YOU don't have to know the URL if is you use some client that abstracts that away from you15:48
edmondswthe contract is and always has been the URL15:48
edmondswand is in every RESTFUL system15:48
edmondswthat's what makes it RESTful... that the REST API is the contract15:48
dstanekedmondsw: actually that's not true the only URL that should be hardcoded is entry points all other urls should be followed via relationships - what when do is not REST15:49
edmondswno... relationships are great but they are optional, not required15:49
dstanekHATEOAS is mostly clear on this subject15:50
edmondswand I don't think there's any system where you only need to know one entry point URL15:50
ayoungdstanek, sorry, missed the notification.  THere is no way to make compute:start_server to the URL that executes it. A user does not know what policy rule is going to be executed15:50
dstanekedmondsw: how about every website ever?15:50
edmondswwebsites are not in any sense RESTful15:50
dstanekedmondsw: that is what Ray based his research on15:51
dstanekayoung: they don't know what operation they are protecting?15:51
edmondswI'm pretty sure Roy would agree with me on this... websites are not RESTful15:51
ayoungideally, there would be "query role for this API" verb that would say "assuimg the resource you want exists, this is the role you would need to execute against it"15:51
edmondswI've read Roy's stuff... I don't think I'm diverging from him here15:52
dstanekedmondsw: what we do is like uri templating and that's normally frowned upon...but we do it much, much worse because the template isn't in the body of the response it's in the client15:53
edmondswayoung, i.e. a permissions API :)15:53
ayoungedmondsw, a persmissions verb specifically15:53
edmondswdstanek we do a lot of bad things... like using PUT to update when it's supposed to be replace15:53
*** pece has joined #openstack-keystone15:54
ayoungso instead of GET /v3/users/<userID> I could do  QUERY v3/users/<userID>  and get back {roles: [a,bn c]15:54
*** catintheroof has joined #openstack-keystone15:54
dstanekayoung: why is making me know the URL better than knowing i'm doing an identity:get_user?15:55
*** tesseract- has quit IRC15:56
knikollarodrigods: awesome! let's get it done.15:56
ayoungdstanek, because you always know the URL you are trying to execute15:56
ayoungyou can run openstack <op> --debug and figure it op15:57
dstanekedmondsw: an oldy, but goody
*** edtubill has joined #openstack-keystone15:58
dstanekedmondsw: short, short is that if a client knows URLs beyond a handful on entry points then you are doing it wrong15:58
ayoungdstanek, we could even build the matching capability into keystone client...15:58
ayoungHmmm15:58 of his big points there15:59
ayoung"A REST API must not define fixed resource names or hierarchies "15:59
ayoungI pushed for that in Keystone a few years back, that was the whole "keystone should do HTML" thing15:59
dstanekayoung: i don't care about HTML specifically, but conceptually that's a great idea16:00
edmondswdstanek, I'm reading... haven't gotten to anything like that yet16:00
ayoungdstanek, HTML was just a way to make people see it16:00
dstanekedmondsw: last bullet is that specific point16:01
ayoungdstanek, Ideally, in an OpenStack system, the user has an AUTH URL, and discovers everything else from there.16:01
dstanekA REST API should be entered with no prior knowledge beyond the initial URI (bookmark)16:01
edmondswdstanek, found it...16:01
edmondswso then forget calling this REST :)16:02
dstanekwith REST there are tradeoffs, but wouldn't it be great if a client could contact keystone and just navigate links?16:02
dstanekthis client wouldn't have to be intelligent at all, just scripted16:02
edmondswif this is not and never will be REST, then what Roy says about REST can be ignored here16:02
dstanekedmondsw: i've said that since i started working on openstack. we are an HTTP RPC API16:02
dstanekthat highlights my point nicely.... i can create policy right now for nova by having a list of operations. i have no idea what the URLs are and i don't care. what i am hearing now is that you want me to care16:04
edmondswdstanek no, you can't16:05
edmondswyou can't create policy for nova without digging through nova's code... I know, I've had to do it :(16:05
ayoungdstanek,, lets assume that is the goal here.  Now, add in delegation.  How can a user discover what she needs to delegate to another user in order to have that other user perform an operation on her behalf?16:05
dstanekwhat operation is 'GET /blah' vs. 'PUT /blah' vs. 'PATCH /blah' vs. 'POST /blah'16:05
ayoungedmondsw, +++++++16:05
ayoungedmondsw, that is a huge driving point behind the RBAC spec16:05
dstanekayoung: in your world what would a user have to know?16:06
edmondswdstanek I've spent hours trying to figure out where a policy setting is actually being checked in code to determine what it's really for16:06
dstanekedmondsw: so in practice you are looking at the URLs?16:06
edmondswif i understand the questionm16:06
ayoungdstanek, so, with RBAC, everything is a role.  If you have an operation that requires a role, you delegate only that role16:06
*** rcernin has quit IRC16:07
ayoungand, in my world operation={URL + VERB}16:07
openstackgerritMerged openstack/keystone: Fix typo in api-ref doc
ayoungdstanek, as edmondsw pointed out earlier, however, Nova has some cases where it hides the operation inside the payload of the PUT/POST  body16:09
dstanekayoung: so pretend we have an awesome GUI for delegation. i would expect to see a nice list of responsibilites that can be deletegated (boot, shutdown, snapshot, whatever) right?16:09
dstanekusers will never see URLs in that case16:10
ayoungdstanek, that is a UI decision, how to present.  Take it back a step16:10
ayoungsay you want to do this from Pythong16:10
*** spligak has quit IRC16:10
ayoungand you know "thit API is from nova client"16:10
ayounghow do you figure out what to delegate?16:11
ayoungone option could be that you have the execption hander call into keystoneclient with the URL it tried16:11
dstanekayoung: i have a list of things you can do to a resource and i pick from the list16:11
*** chlong has joined #openstack-keystone16:11
ayoungand keystone client looks it up in the keystone API16:11
dstaneki don't care about the client directly16:11
*** chlong has quit IRC16:12
*** chlong has joined #openstack-keystone16:12
ayoungdstanek, that was exactly the use case david-lyle_ asked me about at the SUmmit several years back that lead to this approach16:12
dstanekit would actually be super awesome if the OSC commands perfectly aligned with the operation in policy and documentation16:12
ayounghe wanted to know: based on the roles that a user has, what should I show her?16:12
dstaneksure, probably so he can have certain buttons like 'reboot' appear based on that role16:13
dstanekdefinitely not a 'POST /vm/{id}/something/reboot' button16:14
dstanekmy general point is that services already need to know their URLs and how that maps to operations. why does anyone else have to care?16:15
ayoungdstanek, because first and formost our contract is the APIs.  Non Python services need to be supported here, too16:16
ayoungdstanek, it was dolphm, that beat that idea into my head.  I agree with him.16:16
*** ravelar1 has joined #openstack-keystone16:17
*** ravelar has quit IRC16:17
dstanekayoung: i don't that what i'm saying excludes anything16:18
ayoungdstanek, if you are going to boot a server from Rust code, you need to know the URL you are calling.16:19
ayoungShould you need to know "that maps to compute:create_server too?16:19
ayoungIf so, how do we map that, or map it backwards?  I need to doe compute:create_server so what URL do I need to call?16:19
ayoungI want to make the hyperlink the definitive thing, and automate determining the connection between that and the roles required to perform it16:20
*** henrynash has joined #openstack-keystone16:20
*** ChanServ sets mode: +v henrynash16:20
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS
dstanekayoung: because we are not a RESTful system then there will need to be mapping somewhere. i'd honestly like to push that into client writers than policy writers and users.16:22
*** henrynash has quit IRC16:23
ayoungdstanek, please expound on that16:23
dstanekyou only really need to know the URL currently if you write your own client or use curl right?16:23
dstaneki've used both python and java clients to create vms and i have no idea what URLs were actually used. but i do know that i created them. and i suspect i know how to modify policy for them (but you guys did mention nova dragons)16:25
openstackgerritSamuel Pilla proposed openstack/keystone: API Documentation for user password expires
dstaneki may say 'nova.reboot("123")' or 'nova->reboot_vm("123")' and in my mind that maps to an operation i am doing16:26
dstaneknow if i using curl then i've probably already lost (or i'm probably developing/debuggin openstack)16:27
*** adrian_otto has joined #openstack-keystone16:27
ayoungdstanek, your mind may map that, but there is, as of now, no way of automatically correctly mapping that to policy16:27
dstanekas an admin of a domain i was to give you the right to start and reboot VMs. i can't imagine horizon will show this as a list of URLs16:28
ayoungHowever, if it were based on the URL, both the Java and Python apis would have a means to do so16:28
ayoungdstanek, the more information an API provides, the more the UX team can do with it.16:29
dstanekayoung: clients now already know the mapping (generally speaking) they named the method reboot because it reboots16:29
ayoungAn example from the FreeIPA UI:16:29
ayoungIPA, based on LDAP, can query down to the individual property level is a user can read write (and more)16:29
ayoungbased on that, the UI can chose to show a given field as read only, writable, or not bother to show it16:30
ayoungYou don't need to show the field name, just the expected permissions on it16:30
ayoungSo, Horizon would say "here is a complex page, with multiple panels. Let me query what a user can do for Op1, Op2, Op2 and tailor that page to them16:31
ayoungThey would not give the user a list of URLs, they would query based on the state of the system.  Not something we can do today16:31
dstanekayoung: what would the query on?16:31
edmondswdstanek horizon is a client. So it's just fine that it needs to know the URLs. Doesn't mean it will show the URLs to users in its buttons16:32
ayoungdstanek, to start, they could query a list API, see if that goes through16:32
ayoungif it does, they could select an item from that list and query on that16:32
*** kragniz has quit IRC16:32
*** henrynash has joined #openstack-keystone16:33
*** ChanServ sets mode: +v henrynash16:33
dstanekso say they are on page for a VM they have to query on a bunch of URLs that are somewhat related to VMs?16:33
*** kragniz has joined #openstack-keystone16:33
dstanekin my mind this goes back to what i wanted in atlanta. a heirarchy of operations grouped by resource16:34
ayoungdstanek, so, they *could* but in all likelhood, they would fetch and cache the information instead16:34
edmondswdstanek no, they would query the api_roles API to see what they should/shouldn't show16:34
dstanekthat would be all in one document and the document could be dynamic based on the user16:34
ayoungedmondsw, ++16:34
ayoungdstanek, ... actually, this would be pretty much that, or at least enough information to generate it16:35
*** henrynash has quit IRC16:35
ayoungkind of like a permissions based json_home16:35
edmondswapi_roles response is your document, just tied to role instead of to user. The client will know the role of the user, so it amounts to the same thing16:35
ayoungbut, the thing is that we are trying to solve this for more than just the known openstack services16:35
ayoungthere are an ever growing set of them that use Keystone now16:35
dstanekso each client maintains their own list of URLs groups by resource under this scheme?16:36
ayoungWe could generate the one for the user, though, from that data.16:36
ayoungdstanek, the "SERVICE" is the set of resources grouped together here16:36
openstackgerritRichard Avelar proposed openstack/keystone: Add doctor tests on security_compliance and rename
ayoungand, I'd like to point out that we could totally abuse that term16:36
edmondswdstanek ?16:36
dstanekayoung: but i want to know what can be done to this VM. how do i do that?16:37
ayoungand have a different "service" value for different endpoints of the same service...16:37
edmondswdstanek to know what can be done to VMs (it's based on resource type, not instance) you query the api_roles API and parse out the information for that resource type16:37
edmondswit will tell you which roles can call those APIs16:38
edmondswyou already know which APIs you support calling and what buttons you've mapped those to16:38
ayoungdstanek, I think you are getting at the fact that a VM is a complex object with multiple operations on it, and that they might be buried inside the POST operations for a simple WEB API.  I can't claim that I am solving that here16:38
ayoungThe wide variety in how different APIs are implemented make it impossible to retro fit a tool to work with all of them.  I am trying to get us to the start of a process that gives us a way to grow these rules16:39
ayoungsome might end up requiring service engineers to come up with new APIs for exisint resources16:39
ayoungand someone might end up demanding that we look inside the POST/PUT/PATCH payloads16:39
ayoungI am trying to avoid doing that prematurely16:40
ayoungthis is not going to be the end all be all, just a reasonable progression based on the current state, and the limitiations and requests we've had in the past several years16:40
openstackgerritSamuel Pilla proposed openstack/keystone: API Documentation for user password expires
dstanekayoung: ok, i want to capture some of this...16:42
ayoungI think this approach will drive us toward more restful solutions16:42
ayoungdstanek, awesome16:42
dstanekayoung: if i am writing a client do i need to care about policy...should i?16:42
ayoungdstanek, edmondsw thanks so much. These are the conversations I've wanted to have around this topic.  I did not want to be forcing something on other people, but rather helpoing refine and guide based on mahny people's experiences16:43
ayoungdstanek, ideally, no16:43
ayoungdstanek, I see policy as a cross cutting concern, specifically, the RBAC side of it16:43
ayoungfor delegation, it is a case of saying, if User 1 can do this, they need to be able to set up automation to do it on their behalf that can do only that16:43
dstanekayoung: i'm going to argue out every point until we get it right :-P16:44
ayoung"that" in this case is the operation, whatever it is16:44
dstanekayoung: i'm assuming as a user of a client you only care about policy when you get a message saying you don't have permission16:44
ayoungdstanek, how about instead of "until we get it right" we aim for "until we get something practical"16:44
dstanekayoung: fair enough16:44
dstanekayoung: as a cloud admin i care about policy so that i can protect some operations16:45
ayoungdstanek, I would say I also care about it when I want to have something else do it on my behalf16:45
ayoungdelegation is a huge driving factor here16:45
dstanekand as a user wishing to delegate responsibility i care because i have to know what can be delegated16:45
ayoungdstanek, remember people asking for a "READ ONLY" role?16:45
ayoungdstanek, right16:45
dstanekayoung: yep, i'm breaking up all the cases16:46
ayoungdstanek, so we have a 2 dimensional system:  role is scoped to project.  project is the set of resources of a specific type that are all treated the same way16:46
ayoungits imperfect, but it is what we have16:46
ayoungso we can vary the role, or we can vary the project16:46
dstanekayoung: do we consider horizon a client liek edmondsw said or should it have a deeper knowledge about policy? i think it needs that deep understanding16:47
ayoungthis spec is focused on varying only the role.16:47
ayoungit is a cliejnt16:47
ayoungdstanek, ideally, a single openstack deployment would have one horizon instance for each X....where X is some granularity of group of users16:47
ayoungI could see a case where, with Federation, each IdP gets its own Horizon16:47
ayoungand its own AUTH_URL16:47
*** browne has joined #openstack-keystone16:47
ayoungstill talking to the same keystone database16:48
dstanekayoung: i'm not really focused on the spec directly right now. i'm trying to discover what the end state of policy should be (within the constraints of openstack, of course) so that i can properly judge all the specs and marching in that direction16:48
edmondswsome clients will need less understanding of what's allowed than horizon, but I would still call horizon a client16:48
*** Ephur has joined #openstack-keystone16:48
edmondswdstanek ++16:48
*** clenimar has joined #openstack-keystone16:49
dstanekedmondsw: yes, i agree that technically it's a client, but in our context i think we need to treat it as special16:49
edmondswdstanek yes, it (and other UI clients) are probably the only things that will call this api_roles API besides the validation logic in middleware16:50
*** udesale has quit IRC16:54
*** tqtran has joined #openstack-keystone16:55
ayoungedmondsw, I can see Heat using it, and Mistral16:55
ayoungHeat often has to create trusts for users.  This would allow Heat to create scoped down trusts based on the workflows the user is setting up16:56
*** rcernin has joined #openstack-keystone16:59
dstanekayoung: do you think the openstack community would be open to using links and relations more to avoid hardcoding URLs?17:00
ayoungdstanek, Heh. That is a good question. I think you will not get a consensus, but the majority of people would prefer it17:01
ayoungWe would need to be able to provide a means to use those links17:01
ayoungand I think that "meaning" is the hardest part of all17:01
ayoungthere is *always* some A-priori knowledge you have.17:02
ayoungThe goal is to minimize the amount, and to maximize discoverability17:02
*** asettle has quit IRC17:02
ayoungthat is why I don't like the API/JSON-Home emphasis, but I understand why people want it17:03
*** asettle has joined #openstack-keystone17:03
dstanekayoung: yep. part of the HATEOAS constraint to to spend time documenting the doctype and relationships17:03
*** pcaruana has quit IRC17:03
dstanekinstead of keystone documenting '/v2/users' we should be documenting that as a list-users relation or something liek that17:04
ayoungusers is a doc type?17:04
*** asettle__ has joined #openstack-keystone17:05
ayoungdstanek, multiple APIs get to the same doc-types?17:05
dstanekno, our doctype is based on JSON, but isn't documented on consistent. /v3/users is a link that appears on the main versioned resource?17:06
dstanekso, as a client i know 3 things to get a list of users: the entrypoint, the version i was and the relation i need17:06
dstaneki GET / and find the version i want from JSON-Home. from there i get that resouce and look for a relation.17:07
*** asettle has quit IRC17:07
dstanekit's really just orchestration of a standard HTTP client17:07
*** Zer0Byte__ has joined #openstack-keystone17:09
*** Zer0Byte__ has quit IRC17:09
*** asettle__ has quit IRC17:09
ayoungdstanek, should the GET /v3 response  from keystone have a list of resources in it?17:10
ayoungactually, not there, it would be later...17:10
*** udesale has joined #openstack-keystone17:10
ayoungOK, so we start with an AUTH_URL, which really should tell the user where to start17:11
ayounglets assume a Federation use case, as AI think that will be the norm17:11
ayoungnow,  lets assume a Keystone server that supports at least 2 IdPs17:11
ayoungso the AUTH_URL ideallyt would be  https://hostname:port/v3/OS_FEDERATION/idp/<idpID>17:12
ayoungI know our current scheme does not support this17:12
ayoungbut stick with me17:12
dstanekayoung: right17:12
ayounglets assume it does, and now the user wants ot authenticate17:12
ayoungfrom that URL, they should get a list of protocols17:12
ayoungand then they can chose which to use for this session17:13
ayoungso they go to  https://hostname:port/v3/OS_FEDERATION/idp/redhat/protocol/x509 and get an unscoped token17:13
ayoungthat token response should have  mini service catalog in it17:13
ayoungjamielennox suggested that a long time back. That service catalog should have only the identity endpoint with enough information about the things you can do with an unscoped toke17:14
ayounglist projects for user is the big one17:14
*** Marcellin__ has joined #openstack-keystone17:14
ayoungbut change password, and other keystone things that are not necessarily scoped, too17:14
ayoungnow, the user picks a project and rescopes:  uses their unscoped token to get a scoped one for that project17:15
ayoungthat token does not necessarily have to have every role on it.17:15
ayoungI would argue that, if you are an adminisrtator, it should have "Member" on it17:15
ayoungand to convert an unscoped token to a scoped token with admin on it, you have to explicitly request it17:16
ayoungbut back to discoverability17:16
dstanekso far you are descibing something very similar to what i'd love to have17:16
ayoungonce I have that scoped token, I should get a list of services from the service catalog17:16
ayoungnow, I pick the Keystone one, and I query it17:16
*** GB21 has quit IRC17:16
ayoungand it tells me the resources support by Keystone17:16
ayoungthe service value here is kindof the doctype17:17
ayoungit is a shorthand for the description doc for the identity service17:17
ayoungnow, we do it this way to streamline common cases, but it could also flow like this:17:18
ayoungwhen I use the unscoped token to get a scoped token, all I get back is a URL that says "here is the service catalog"17:18
ayoungI use that URL to fetch the service catalog, and from there I get the URL to the identity service17:19
ayoungfrom the URL for the identity service, I get a set of resources that the identity service can manage:  this list should be filtered by my role assignment on that project17:20
ayoungonly show me resources that I can, in some way, effect17:20
ayoungso that doc would have /project/<id> in it, as well as a link to list the users with roles on that project.17:21
dstanekyep, like in a webpage that shows a field as readonly as opposed to it being in a writable text box17:21
ayoungdstanek, or a dynimic DIV that renders only if it has data, but yes17:21
knikollathe discoverability aspect of this looks really really cool.17:22
ayoungdstanek, this is why I wanted keystone to render in HTML.  It makes all this so obvious17:22
dstanekthe tradeoff with this approach is the number of requests needed against the ease at which clients can be generically implemented17:23
ayoungyou hit your keystone with a web browser, you get a token, you click around, and there is a link to everything you want to do17:23
dstanekthe number of requests can be mitigated with caching, but some of the dynamicness might have to go away17:23
*** nicolasbock has quit IRC17:23
*** nicolasbock has joined #openstack-keystone17:23
ayoungfor a given resource, there should be a link to a page that gives you a form in HTML17:23
ayoungdstanek, that is why we have cache headers17:23
ayoungthe resource URLs themselves would not change much17:24
ayoungif a user lost a role assignemnt, the URL that points to that role assignment by id would 40417:24
dstanekayoung: no, but they may vary based on user/role/whatever if we are not careful17:24
ayoungdstanek, we have a lot of objects that are named by uuids17:24
dstanekall that is part of the consideration for designing an API that is not solely URL based17:24
ayoungthe /user/role might also return it17:25
ayoungbut it would have a self link toe /v3/role_assignment/<id>17:25
dstanekwhy hardcode /user/1234 when /user?id=1234 would work too?17:25
ayoungdstanek, I don;t care17:25
ayoungso long as there is a canonical way to define it, it works for me17:26
dstanekayoung: exactly!17:26
dstanekyou don't even need to define it, instead you define a user relation17:26
dstanekfirst you define all the relations so that a client developer will know what they mean17:27
*** chlong has quit IRC17:27
dstanekthen you defined a doctype so that clients will know how/where to find stuff17:27
ayoungdstanek, right, so I know that to change a user I need to call PATCH <USERURL>.  I can try it and get back a 401 and see that I don't have permission.17:28
dstanekfor example, html is the doctype and you know what to do with an input and a button. defines the relations17:28
ayoungBut lets say we are talking...a network in Neutron17:28
ayoungI don't want to change it, but I have a service that does17:29
ayoungI know I could change it by calling PATCH <networkURL>17:29
ayoungbut I don't want to call it17:29
ayoung I want to let that service call it at some point in the future17:29
ayoungI want to create a delegation that says "you can do this, and only this"17:29
dstanekyou would deletgate networking:update-network17:31
ayoungdstanek, how would you know that?17:32
dstanekmaybe even 'networking:update-network:id=xyz'17:32
knikollawould keystone or neutron maintain that?17:32
ayoungso I should be able to query PATCH <URL> and get back 'networking:update-network:id=xyz'17:32
dstanekyou know what the relation update-network mean17:32
ayoungdstanek, that is A-Priori knowlege, what we were trying to avoid above17:32
dstanekayoung: you have to have entrypoint and an understanding of relations a-priori17:33
ayoungdstanek, instead, on the GET  <URL>   you should get back a link that has 'networking:update-network:id=xyz'  in it17:33
ayoungbut...thinmk what that means: we are requiring a specific value on every GET operation throughout openstack17:34
ayoungRoles and tokens are already out of band information17:34
dstanekno, so what i'm thinking (and i haven't designed out all of the cases):17:34
ayoungso...I'm compromising here17:35
ayounggo on17:35
dstaneka user is given access to update a particular network via roles or whatever17:35
dstanekthat is stored as the allowed relation and the id (this is only one way)17:35
dstanekwhen something goes to use that delegation they know they want to update a network. they crawl through the resources to find that network. more concretely then would17:36
*** chrisplo has quit IRC17:37
dstanekGET / on neutron, find the search of query for networks, get the correct one and get the method/url for updating that network17:37
dstanekthat assumes that all services are RESTful though, which will probably not happen in my lifetime17:38
ayoungdstanek, so at a minimum, I want an API/Mechanism that lets me say "OK, I have this URL here, what do I need to do to execute it?"17:39
dstanekwhat's the case where you as a user actually have the url?17:40
openstackgerritSamuel Pilla proposed openstack/keystone: API Documentation for user password expires
*** henrynash has joined #openstack-keystone17:45
*** ChanServ sets mode: +v henrynash17:45
*** chris_hultin is now known as chris_hultin|AWA17:47
*** Zer0Byte__ has joined #openstack-keystone17:50
*** rcernin has quit IRC17:52
*** rcernin has joined #openstack-keystone17:52
*** chlong has joined #openstack-keystone18:01
*** GB21 has joined #openstack-keystone18:05
*** jdennis1 has joined #openstack-keystone18:11
*** jdennis has quit IRC18:12
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: API Documentation for user password expires
openstackgerritRichard Avelar proposed openstack/keystone: Add checks for doctor credential symptoms
*** rcernin has quit IRC18:17
*** henrynash has quit IRC18:20
*** asettle has joined #openstack-keystone18:24
*** asettle has quit IRC18:26
*** asettle has joined #openstack-keystone18:26
openstackgerritRichard Avelar proposed openstack/keystone: Add doctor checks for ldap symptoms
*** harlowja has joined #openstack-keystone18:32
*** harlowja_ has joined #openstack-keystone18:34
*** harlowja has quit IRC18:35
*** ravelar1 has quit IRC18:35
*** GB21 has quit IRC18:36
openstackgerritSamuel de Medeiros Queiroz proposed openstack/keystone: Add doctor tests on security_compliance and rename
*** haplo37_ has quit IRC18:55
*** haplo37_ has joined #openstack-keystone18:56
*** haplo37_ has quit IRC18:59
*** haplo37_ has joined #openstack-keystone18:59
*** david-lyle_ is now known as david-lyle19:13
*** asettle has quit IRC19:16
*** asettle has joined #openstack-keystone19:16
stevemarso many doctor tests :|19:18
stevemarnote, i'm not dying ^ i am referring to the keystone-doctor19:21
*** asettle has quit IRC19:21
stevemarsome say he is related to dr. doom19:21
openstackgerritGage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS
*** udesale has quit IRC19:26
*** chris_hultin|AWA is now known as chris_hultin19:37
knikollastevemar: can we add a doctor test for symptom too many doctor tests?19:40
gagehugometa doctor tests19:43
*** openstack has joined #openstack-keystone19:44
*** Marcellin__ has quit IRC19:49
stevemarknikolla: :)19:51
morganknikolla: E_TOO_MANY_TESTS("You've added another test... Sorry but you must now increase your premiums/buy private keystone-health-insurance to accommodate the extra labor needed to test your keystone install. We recommend talking to your local keystone developer for more information." (cc stevemar )20:02
knikollamorgan: keystone-health-insurance hahaha20:05
*** masber has quit IRC20:07
*** masber has joined #openstack-keystone20:07
*** spzala has quit IRC20:18
*** raildo has quit IRC20:30
dstanekis ldap on devstack broken?20:38
*** rcernin has joined #openstack-keystone20:38
*** rcernin has quit IRC20:38
*** rcernin has joined #openstack-keystone20:38
*** spzala has joined #openstack-keystone20:42
*** spzala has quit IRC20:46
*** spzala has joined #openstack-keystone20:56
*** masuberu has joined #openstack-keystone20:58
*** jamielennox|away is now known as jamielennox20:58
*** masber has quit IRC20:59
rodrigodsdstanek, looks like it is21:03
rodrigodsannakoppad was taking a look on it21:04
knikollarodrigods: are you going to make the project-config patch for the env vars you need in the tests?21:06
rodrigodsknikolla, it's on my todo list21:07
rodrigodsi also need to add a feature flag for the tests21:07
rodrigodsbut,... you can go ahead if you have some free time21:07
knikollarodrigods: i'm afraid to even look at my todo list21:07
*** adrian_otto has quit IRC21:08
rodrigodsi should be able to do that next week21:09
*** ravelar1 has joined #openstack-keystone21:11
dstanekrodrigods: hmmm...that sucks. i really want to test21:12
ayoungedmondsw, I rememberwhy I wanted the is_admin_project check in RBAC21:25
edmondswayoung why?21:25
ayoungit was to give power to the admins to decide whether it should be a global admin check or not21:25
ayoungsince it is not yet definied in all the policy files, it gives a way to get it into the field, too21:26
ayoungbut that is just me being lazy21:26
edmondswand they don't have that in policy because...21:26
ayoungthere might be an API that is currently admin only21:26
ayoungcuz I have not got all the reviews through to do it...21:26
edmondswI would pull it out either way, and make it a separate spec where we can debate the merits21:27
ayoungedmondsw, deal21:27
*** chlong has quit IRC21:29
*** edtubill has quit IRC21:34
*** ravelar1 has quit IRC21:37
*** adrian_otto has joined #openstack-keystone21:37
morganedmondsw: oh hi!21:40
morganedmondsw: that is a name i've not seen in a while21:40
edmondswmorgan hey there21:40
edmondswyou caught me... ;)21:40
morganoh adriant isn't here21:40
morganedmondsw: yah.21:41
morganedmondsw: you should come around more often. we're friendly (still), I swear21:41
edmondswyeah, it's all a matter of time... I will be at the PTG though21:41
morgani've booked my ticket21:41
edmondswand hopefully around more21:41
morgani may be there, i may not21:41
edmondswwell, I hope you will21:42
morganbut it is quite possible you can find me there21:42
* morgan skipped barcelona and the keystone midcycle21:42
* edmondsw did as well21:42
morgandstanek: ok21:42
morgangoing to start on the MFA stuff21:42
morgandstanek: what do you think, an additional column on USER21:42
morganor a new table with a user FK21:43
morgancc ayoung, bknudson, stevemar, and the rest of the cores [if you care]21:43
* morgan is leaning towards a separate table21:43
morganwith a FK.21:43
morgannot a "FK" in sql sense, i guess, just a "logical" fk so we could support LDAP users with this API since Auth is semi-independant of LDAP21:44
*** ravelar1 has joined #openstack-keystone21:45
morganzzzeek: does Alembic allow for multiple migration repos for a single DB?21:47
morganzzzeek: because... i remember it didn't before...21:47
zzzeekmorgan: yes21:47
morganzzzeek: cool.21:47
morganstevemar: we need to do the collapse for mitaka migrations.21:48
morganstevemar: to*21:48
morgannot for21:48
* morgan is a bit sad the expand/contract repos aren't alembic21:48
morganthat could have been a natural progression from SQL-A21:48
*** edmondsw has quit IRC21:48
zzzeekmorgan: neutron does all of this21:50
*** dave-mccowan has quit IRC21:50
zzzeekper-release expand/contract directories21:50
morganzzzeek: yeah, i figured. just keystone had an opportunity to move to alembic :)21:50
morganwith the expand/contract directory addtions21:50
morganbut we didn't.21:50
morgan*oh well*21:50
* morgan does this migration with SQL-A-Migrate21:50
*** edmondsw has joined #openstack-keystone21:52
*** edmondsw has quit IRC21:52
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS
*** spzala has quit IRC21:57
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS
*** chlong has joined #openstack-keystone22:02
*** spzala has joined #openstack-keystone22:03
openstackgerritSamuel Pilla proposed openstack/keystone: Add password expiration queries for PCI-DSS
*** rcernin has quit IRC22:04
*** jamielennox is now known as jamielennox|away22:04
ayoungmorgan, needs to be outside of LDAP and Federation for certain22:05
ayoungbeyond real care here22:05
openstackgerritRon De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers
openstackgerritayoung proposed openstack/keystone-specs: Role Check from Middleware
*** spzala has quit IRC22:07
morganayoung: done, making it a separate table22:08
openstackgerritRon De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers
*** jamielennox|away is now known as jamielennox22:11
*** ravelar1 has quit IRC22:17
*** asettle has joined #openstack-keystone22:19
openstackgerritRon De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers
*** asettle has quit IRC22:24
stevemarmorgan: hmm, why do we *need* to collapse the migrations?22:31
openstackgerritRon De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers
openstackgerritRon De Rose proposed openstack/keystone: Require domain_id when registering Identity Providers
*** browne has quit IRC22:44
rderoseayoung: ^ modified this patch to enforce 1:1 (idp:domain)22:44
*** arunkant has quit IRC22:44
*** tqtran has quit IRC22:44
*** pnavarro has quit IRC22:46
*** arunkant has joined #openstack-keystone22:47
*** tqtran has joined #openstack-keystone22:47
*** browne has joined #openstack-keystone22:47
stevemarrderose: ++22:50
stevemarrodrigods: you don't need a bug for this! :P
openstackLaunchpad bug 1648886 in OpenStack Identity (keystone) "OpenStack Identity API doc pointing to specs" [Undecided,New]22:50
ayoungrderose, will that work?22:52
ayoungstevemar, never hurts to have a bug recorded before you fix something, lets you forget about it and soemone else can fix22:52
ayoungmorgan, I read qthat as SQL-A-Migraine22:53
*** chris_hultin is now known as chris_hultin|AWA22:55
brownefederation quesetion: does keystone keep some sort of state when doing the SAML exchange?23:04
brownei notice in my setup, whcih has two keystones behind a haproxy  talking with a 3rd party IDP23:04
brownei get a infitite loop where theres a redirect to the IDP, then back to the other keystone, then another redirect back to IDP, etc, etc23:05
*** r1chardj0n3s is now known as r1chardj0n3s_afk23:05
brownei'm using mellon, and made sure the key, cert, and xml are the same on each keystone23:05
ayoungbrowne, something is misconfigured23:09
ayoungbrowne, that sounds like a Mellon setup problem, though, not keystone at all.  Hasn;t gotten to the keystone layer I think23:10
stevemarbrowne: oh there was something about that...23:10
browneayoung: yeah, maybe its mellon specific, still not sure why23:11
brownemy haproxy is configured to load balance round-robin, so the request doesn't go back to the same keystone23:11
ayoungbrowne, fpaste your httpd/conf.d/ config file for the mellon part please23:11
brownethis is Mitaka, btw23:13
browneand that file in the paste is ansible(ized)23:13
*** ravelar1 has joined #openstack-keystone23:13
brownei'm new to federation, but believe i have it mostly working23:15
stevemarbrowne: uh, this is so... i remember marek sending me an email about this23:15
ayoungbrowne, {{ ansible_eth0.ipv4.address }}  should probably be a hostname23:16
browneif i shutdown one of the apaches(keystone), then auth works23:16
ayoungyou should be using TLS23:16
browneayoung: yeah, there are no hostnames.  private IPs only on this mgmt network23:16
ayoungbrowne, does that match what you tell the outside world?23:17
browneTLS is provided using SSL termination at haproxy23:17
ayounga lot of redirect problems are due to the names not matching23:17
ayoungare you trying to do websso?23:17
ayoungbrowne, does it get as far as letting you log in to the IdP?23:18
brownethen i think the saml token goes to the other keystone, and it begins again23:18
ayoungso once you log in, it kicks you back to the same URL that you origianlly hit on Keystone, which does not accept the SAML assertion and thus kicks you back to the IdP....23:19
browneuntil the IdP quits telling me there were too many requests23:19
browneayoung: yes23:19
ayoungI think you need to make the two keystone servers have the same hostname23:19
ayoung<VirtualHost {{ ansible_eth0.ipv4.address }}:5000>  should be <VirtualHost {{ keystone_hostname }}:5000>23:20
browneso what part matters for that?  mellon?23:20
brownefor mellon i generated the key, cert, xml for the public_hostname of haproxy23:20
ayoungbrowne, mellon is going to post a request to the idp with its identity.  call that keystone1.  IdP will grant an assertion valid for keystone1.  HA sensds the response to keystone2.23:21
browneayoung: i don't have any hostnames on this controller.  only IPs for keystone, apache, horizon, etc23:21
ayoungKeystone 2 looks at assertion and says "this is not for me"23:21
ayoungbrowne, give it one and see if it works23:21
*** ravelar1 has quit IRC23:21
*** agrebennikov_ has quit IRC23:21
ayoungits a virtual host directive, so it has to map to the public IP23:21
browneunfortunately its not possible in our setup23:22
ayoungbrowne, this is SAML.  Has nothing to do with Keystone23:22
ayoungan assertion for host1 is not valid for host223:22
browneso is there something in SAML that puts the host's IP in it?23:23
ayoungyou newed to convince your setup that host1 and host2 are the same thing23:23
stevemarbrowne: can you DM me an email address?23:23
ayoungbrowne, yes, it has to23:23
stevemarbrowne: you are using memcache in your setup right?23:23
browneayoung: ok, i'll do more digging.  maybe i can work around this somehow23:25
browneanother thing i've seen is weirdness with federation users23:25
ayoungbrowne, can you pin the HA proxy to a single Keystone server.23:25
ayoungI wouldn't advise it23:25
browneayoung:  yeah, that's the current workaround.23:25
brownesucks for performance23:26
ayoungyeah, so they need the same name somehow.  WHat are you using for an AUTH_URL?23:26
ayoungfor grins lets say it is23:26
browneayoung: our auth_url is a public hostname at port 500023:27
browneon https23:27
stevemarbrowne: let me know if the email i sent helps23:27
ayoungok, so give that a DNS name23:27
ayoungcall it openstack.<domain>23:27
ayoungyour auth_url becomes
*** chlong has quit IRC23:28
ayoungthe HA proxy setup will forward things to the local, but should still honor the hostname, I think you need to set some directive there23:28
ayounglet me see my POC....23:29
browneyep, that is how its setup.  haproxy has the which forwards to one of two keystones23:29
brownecurrently in round-robin mode, but maybe i just need to change that23:30
ayoungbrowne, make that your virstualhost23:30
ayoungnot the ip address23:30
brownethat won't work because apache is on a different node that has no public network connectivity23:30
ayoungdoes not matter23:30
ayoungha proxy will sent the hostname along with the rewritten IP address23:31
ayoungServerName https://openstack.ayoung-dell-t1700.test  might also be sufficient browne23:32
ayoungor your equivalent23:32
brownei can try, as long as it doesn't attempt to bind on that address23:33
*** ravelar1 has joined #openstack-keystone23:33
*** adrian_otto has quit IRC23:33
ayoungVirtualHost  just means that it will take requests for that hostname and map them to the stanza23:35
ayoungfor ServerName, I think it is used in outgoing requests, and that is probably the one you need23:36
browneok, cool, thx i'll give it a shot23:38
*** ravelar1 has quit IRC23:38
brownethe other oddity i see is when i have a federated user with the same user name in keystone23:38
browne2016-12-06 23:40:49.113583 2016-12-06 23:40:49.109 8656 WARNING keystone.common.wsgi [req-e3487ca3-ee4c-4bf8-b6c0-a61825b2ecf4 - - - - -] Authorization failed. Unable to reconcile identity attribute user_id as it has conflicting values 720780bafe4c4c1eb2edae2c4e97d502 and 3728a5d84f854950963a0db196a66aa2 (Disable insecure_debug mode to suppress these details.) (Disable insecure_debug mode to suppress these details.) from 10.123:38
browneand they're on different domains, so i don't understand this error23:39
ayoungrderose, ^^ sounds like mapping issues23:39
*** ravelar1 has joined #openstack-keystone23:41
*** ravelar1 has quit IRC23:46
*** Ephur has quit IRC23:47
rderoseayoung browne: hmm... federated unique_id is not being checked against the
rderosebrowne: what do you mean, on different domains?  do you mean different identity providers?23:59

Generated by 2.14.0 by Marius Gedminas - find it at!