| *** browne has quit IRC | 00:05 | |
| *** browne has joined #openstack-keystone | 00:09 | |
| *** lamt has joined #openstack-keystone | 00:12 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Extend User API to support federated attributes https://review.openstack.org/426449 | 00:13 |
|---|---|---|
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Extend User API to support federated attributes https://review.openstack.org/426449 | 00:15 |
| *** _cjones_ has quit IRC | 00:21 | |
| *** _cjones_ has joined #openstack-keystone | 00:22 | |
| *** _cjones_ has quit IRC | 00:26 | |
| *** lamt has quit IRC | 00:31 | |
| *** thorst has joined #openstack-keystone | 00:31 | |
| *** thorst has quit IRC | 00:36 | |
| *** tovin07 has joined #openstack-keystone | 00:38 | |
| *** thorst has joined #openstack-keystone | 00:41 | |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Ensure token expiration is always consistent https://review.openstack.org/429067 | 00:57 |
| adriant_ | Would I be able to do a single API call (maybe 2) to work out if two projects are in the same tree after work on this spec is done: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/materialize-project-hierarchy.html | 00:59 |
| adriant_ | ? | 00:59 |
| adriant_ | Because currently I'd need to do a full upward tree traversal to the non-domain root to see if they are both in the same tree. | 01:00 |
| *** thorst has quit IRC | 01:01 | |
| *** catintheroof has joined #openstack-keystone | 01:04 | |
| *** ngupta has quit IRC | 01:07 | |
| *** jamielennox is now known as jamielennox|away | 01:16 | |
| *** liujiong has joined #openstack-keystone | 01:17 | |
| *** guoshan has joined #openstack-keystone | 01:24 | |
| *** prashkre_ has joined #openstack-keystone | 01:32 | |
| *** prashkre has quit IRC | 01:32 | |
| *** browne has quit IRC | 01:36 | |
| *** browne has joined #openstack-keystone | 01:40 | |
| rodrigods | adriant_, you can do that via the "parents_as_ids" query parameter | 01:44 |
| rodrigods | so you get for both projects and check if they have the same ID there | 01:44 |
| *** adrian_otto has quit IRC | 01:44 | |
| adriant_ | rodrigods, oh, can I do that now? | 01:45 |
| rodrigods | adriant_, you do a GET /v3/projects/<project_id>?parents_as_ids=true | 01:45 |
| rodrigods | yes | 01:45 |
| rodrigods | it returns the parents of the project organized in a dictionary | 01:45 |
| rodrigods | only the IDs | 01:45 |
| adriant_ | rodrigods, oh! Fantastic. I haven't had to try yet, but that works perfectly for something I'll need. | 01:45 |
| adriant_ | that's fine, I just need to compare roots | 01:46 |
| rodrigods | adriant_, great! | 01:46 |
| adriant_ | it's always nice to find out and API already supports the thing you need | 01:47 |
| adriant_ | an* | 01:48 |
| rodrigods | adriant_, ++ it is supposed to be documented, but looks like it isn't | 01:48 |
| adriant_ | rodrigods, while I'm at it, is there a single API call to get all children for a given project? I haven't looked too deeply into it yet, but don't remember seeing it in the docs. | 01:49 |
| *** browne has quit IRC | 01:49 | |
| rodrigods | adriant_, yep! | 01:50 |
| rodrigods | subtree_as_ids :) | 01:50 |
| adriant_ | I know I can do project list and "parent_id=<project_id>" | 01:50 |
| adriant_ | but I never looked too deep for subtrees | 01:51 |
| adriant_ | ah, but just IDs? | 01:51 |
| rodrigods | yes... just the IDs | 01:51 |
| rodrigods | organized in a dict | 01:51 |
| adriant_ | so I'd then need to do a get query for each... | 01:51 |
| adriant_ | ugh | 01:51 |
| rodrigods | we also have subtree_as_list and parents_as_list | 01:51 |
| rodrigods | which returns the info of the projects | 01:51 |
| rodrigods | however... they only return info for projects the user has access to | 01:52 |
| adriant_ | subtree as list sounds like what I want | 01:52 |
| adriant_ | oh | 01:52 |
| rodrigods | aka have role assignments on them | 01:52 |
| adriant_ | I need an admin command that return a full subtree | 01:52 |
| rodrigods | we don't have it :( | 01:52 |
| adriant_ | so it shouldn't care about roles | 01:52 |
| adriant_ | k | 01:52 |
| rodrigods | however... you can do a subtree_as_ids and then query for each project | 01:53 |
| rodrigods | there you will have the infos | 01:53 |
| rodrigods | i personally don't like the *as_list API (although i've implemented myself) | 01:53 |
| adriant_ | but then I'm doing an O(n) operation for subtree info :( | 01:54 |
| rodrigods | adriant_, yeah... i know | 01:54 |
| rodrigods | but it is tricky to not leak information for such API calls | 01:54 |
| rodrigods | so we decided to do like that | 01:55 |
| adriant_ | Ok, I think in this case I'll just stick to only showing just the immediate subtree, as I can do that with projects.list(parent_id=<current_project>) | 01:55 |
| rodrigods | adriant_, do you have huge hierarchies? | 01:56 |
| adriant_ | not yet :P | 01:56 |
| rodrigods | ok | 01:56 |
| adriant_ | but after I'm done... probably reasonably wide | 01:56 |
| adriant_ | I'm setting max depth at 4 or 5 | 01:56 |
| adriant_ | and some limit in breadth | 01:57 |
| adriant_ | we aren't using heirarchies since we're a single domain cloud, so I'm doing some weird wrapper logic and project_path based naming to allow something 'like' HMT to work. | 01:57 |
| adriant_ | single domain 'public' cloud... | 01:58 |
| adriant_ | so a project name will end up: "my-company/some-team/website-project/dev" | 01:59 |
| rodrigods | hmm nice | 01:59 |
| adriant_ | I'll post a thread and some demos when I get it all working nicely to the mailing list. | 01:59 |
| rodrigods | we thought a lot about hierarchical names for projects | 01:59 |
| rodrigods | turns out we would need a whole new API version to support it | 01:59 |
| rodrigods | adriant_, nice! | 01:59 |
| adriant_ | yeah, that's why I'm doing it as just a naming convention | 02:00 |
| adriant_ | to allow semi-unique subproject naming | 02:00 |
| adriant_ | I remember reading the specs for unique namespaces for subprojects and liked the path system best | 02:01 |
| adriant_ | so I'm doing that with our management service using just the name field, but... my max depth is 64chars :P | 02:01 |
| *** catintheroof has quit IRC | 02:01 | |
| rodrigods | heh | 02:01 |
| adriant_ | because the keystone project name field is 64... | 02:01 |
| adriant_ | or was it 100? | 02:02 |
| rodrigods | is it still 64? | 02:02 |
| adriant_ | lemme check | 02:02 |
| rodrigods | yep | 02:03 |
| rodrigods | it is: https://github.com/openstack/keystone/blob/master/keystone/common/sql/migrate_repo/versions/067_kilo.py#L96 | 02:03 |
| adriant_ | name = sql.Column(sql.String(64), nullable=False) | 02:03 |
| adriant_ | :( | 02:03 |
| adriant_ | while 'name' in all other openstack projects is 255 | 02:03 |
| rodrigods | :( | 02:05 |
| adriant_ | rodrigods, I complained a whilke back on the mailing list but nothing happened. May just submit a patch. | 02:08 |
| rodrigods | adriant_, ++ | 02:08 |
| adriant_ | although having the id be 64 is also a little silly since keystone uses uui4.hex which is always 32 :P | 02:09 |
| *** gyee has quit IRC | 02:12 | |
| *** gyee has joined #openstack-keystone | 02:12 | |
| *** ngupta has joined #openstack-keystone | 02:16 | |
| *** MasterOfBugs has quit IRC | 02:20 | |
| *** agrebennikov_ has quit IRC | 02:24 | |
| *** ngupta has quit IRC | 02:33 | |
| *** ngupta has joined #openstack-keystone | 02:33 | |
| *** namnh has joined #openstack-keystone | 02:34 | |
| *** ngupta has quit IRC | 02:38 | |
| *** martinus__ has quit IRC | 02:40 | |
| *** martinus__ has joined #openstack-keystone | 02:43 | |
| *** gyee has quit IRC | 02:58 | |
| *** gyee has joined #openstack-keystone | 02:59 | |
| *** dave-mccowan has joined #openstack-keystone | 03:07 | |
| *** links has joined #openstack-keystone | 03:08 | |
| *** ngupta has joined #openstack-keystone | 03:15 | |
| *** erlon has quit IRC | 03:35 | |
| *** thorst has joined #openstack-keystone | 03:50 | |
| *** thorst has quit IRC | 03:50 | |
| *** rcernin has quit IRC | 03:50 | |
| *** nicolasbock has quit IRC | 04:06 | |
| *** dave-mccowan has quit IRC | 04:16 | |
| *** dnalezyt has quit IRC | 04:23 | |
| *** thorst has joined #openstack-keystone | 04:32 | |
| *** thorst has quit IRC | 04:32 | |
| *** adrian_otto has joined #openstack-keystone | 04:38 | |
| openstackgerrit | Tony Breeds proposed openstack/keystone master: [DNM] Testing WebOb 1.7.1 https://review.openstack.org/439997 | 04:41 |
| openstackgerrit | Tony Breeds proposed openstack/keystonemiddleware master: [DNM] Testing WebOb 1.7.1 https://review.openstack.org/439998 | 04:41 |
| *** adrian_otto has quit IRC | 04:54 | |
| *** h5t4_ has joined #openstack-keystone | 04:57 | |
| *** guoshan has quit IRC | 05:00 | |
| *** lamt has joined #openstack-keystone | 05:02 | |
| *** thorst has joined #openstack-keystone | 05:03 | |
| *** ravelar has quit IRC | 05:03 | |
| *** lamt has quit IRC | 05:05 | |
| *** guoshan has joined #openstack-keystone | 05:12 | |
| *** thorst has quit IRC | 05:16 | |
| *** adriant_ has quit IRC | 05:20 | |
| *** rderose has quit IRC | 05:21 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements https://review.openstack.org/439355 | 05:21 |
| *** guoshan has quit IRC | 05:27 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements https://review.openstack.org/439219 | 05:28 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystoneauth master: Updated from global requirements https://review.openstack.org/439317 | 05:28 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements https://review.openstack.org/439318 | 05:28 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements https://review.openstack.org/439355 | 05:36 |
| *** prashkre has joined #openstack-keystone | 05:49 | |
| *** prashkre_ has quit IRC | 05:49 | |
| *** prashkre_ has joined #openstack-keystone | 05:50 | |
| *** prashkre has quit IRC | 05:50 | |
| *** h5t4_ has quit IRC | 05:53 | |
| *** guoshan has joined #openstack-keystone | 05:55 | |
| *** dikonoor has joined #openstack-keystone | 05:59 | |
| *** arturb has quit IRC | 06:03 | |
| *** Dinesh_Bhor has quit IRC | 06:09 | |
| *** ngupta has quit IRC | 06:18 | |
| *** arturb has joined #openstack-keystone | 06:27 | |
| *** prashkre__ has joined #openstack-keystone | 06:29 | |
| *** prashkre_ has quit IRC | 06:29 | |
| *** prashkre_ has joined #openstack-keystone | 06:31 | |
| *** prashkre__ has quit IRC | 06:31 | |
| *** edmondsw has joined #openstack-keystone | 06:32 | |
| *** prashkre_ has quit IRC | 06:34 | |
| *** prashkre_ has joined #openstack-keystone | 06:34 | |
| *** richm has quit IRC | 06:43 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 06:46 | |
| *** zhurong has joined #openstack-keystone | 06:47 | |
| *** h5t4 has joined #openstack-keystone | 06:51 | |
| *** zhurong has quit IRC | 06:53 | |
| *** gyee has quit IRC | 06:54 | |
| *** edmondsw has quit IRC | 06:56 | |
| *** namnh has quit IRC | 07:06 | |
| *** rcernin has joined #openstack-keystone | 07:18 | |
| *** tesseract has joined #openstack-keystone | 07:18 | |
| *** namnh has joined #openstack-keystone | 07:23 | |
| *** edmondsw has joined #openstack-keystone | 07:24 | |
| *** edmondsw has quit IRC | 07:29 | |
| *** edmondsw has joined #openstack-keystone | 07:29 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone master: Imported Translations from Zanata https://review.openstack.org/439420 | 07:32 |
| *** edmondsw has quit IRC | 07:34 | |
| *** zhugaoxiao has joined #openstack-keystone | 07:34 | |
| *** prashkre_ has quit IRC | 07:38 | |
| *** prashkre_ has joined #openstack-keystone | 07:39 | |
| *** prashkre__ has joined #openstack-keystone | 07:45 | |
| *** prashkre_ has quit IRC | 07:45 | |
| *** slunkad has quit IRC | 08:07 | |
| *** slunkad has joined #openstack-keystone | 08:11 | |
| *** pcaruana has joined #openstack-keystone | 08:13 | |
| *** DFFlanders has joined #openstack-keystone | 08:41 | |
| *** jaosorior has joined #openstack-keystone | 08:56 | |
| *** zzzeek has quit IRC | 09:00 | |
| *** zzzeek has joined #openstack-keystone | 09:00 | |
| openstackgerrit | Rico Lin proposed openstack/python-keystoneclient master: Update test requirement https://review.openstack.org/440235 | 09:10 |
| openstackgerrit | Rico Lin proposed openstack/keystoneauth master: Update test requirement https://review.openstack.org/440236 | 09:13 |
| *** thorst has joined #openstack-keystone | 09:13 | |
| *** thorst has quit IRC | 09:18 | |
| *** guoshan has quit IRC | 09:20 | |
| *** arunkant has quit IRC | 09:47 | |
| *** namnh has quit IRC | 09:55 | |
| *** aasthad has quit IRC | 10:02 | |
| *** liujiong has quit IRC | 10:07 | |
| *** tovin07 has quit IRC | 10:12 | |
| openstackgerrit | Rico Lin proposed openstack/oslo.policy master: [Fix gate]Update test requirement https://review.openstack.org/440314 | 10:29 |
| *** links has quit IRC | 10:31 | |
| *** links has joined #openstack-keystone | 10:47 | |
| *** dikonoor has quit IRC | 10:49 | |
| *** DFFlanders has quit IRC | 10:51 | |
| *** mvk has quit IRC | 10:57 | |
| *** nicolasbock has joined #openstack-keystone | 11:01 | |
| *** egonzalez has joined #openstack-keystone | 11:04 | |
| *** dikonoor has joined #openstack-keystone | 11:07 | |
| *** dikonoo has joined #openstack-keystone | 11:08 | |
| *** dikonoor has quit IRC | 11:11 | |
| *** richm has joined #openstack-keystone | 11:11 | |
| *** dikonoor has joined #openstack-keystone | 11:12 | |
| *** thorst has joined #openstack-keystone | 11:14 | |
| *** dikonoo has quit IRC | 11:15 | |
| *** thorst has quit IRC | 11:19 | |
| *** edmondsw has joined #openstack-keystone | 11:20 | |
| *** edmondsw has quit IRC | 11:25 | |
| *** mvk has joined #openstack-keystone | 11:28 | |
| *** dikonoor has quit IRC | 11:42 | |
| *** dikonoor has joined #openstack-keystone | 11:51 | |
| *** links has quit IRC | 11:51 | |
| openstackgerrit | Rico Lin proposed openstack/ldappool master: [Fix gate]Update test requirement https://review.openstack.org/440446 | 11:53 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/oslo.policy master: Updated from global requirements https://review.openstack.org/440139 | 11:53 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/pycadf master: Updated from global requirements https://review.openstack.org/440451 | 11:54 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements https://review.openstack.org/439355 | 11:54 |
| *** links has joined #openstack-keystone | 12:04 | |
| *** raildo has joined #openstack-keystone | 12:13 | |
| *** raildo_ has joined #openstack-keystone | 12:13 | |
| *** ngupta has joined #openstack-keystone | 12:22 | |
| *** ngupta has quit IRC | 12:27 | |
| *** thorst has joined #openstack-keystone | 12:45 | |
| *** catintheroof has joined #openstack-keystone | 12:56 | |
| *** raildo has quit IRC | 12:59 | |
| *** raildo_ is now known as raildo | 12:59 | |
| *** rderose has joined #openstack-keystone | 13:13 | |
| *** jdennis has quit IRC | 13:14 | |
| *** jlwhite has quit IRC | 13:15 | |
| *** jlwhite has joined #openstack-keystone | 13:15 | |
| *** ngupta has joined #openstack-keystone | 13:23 | |
| *** ngupta has quit IRC | 13:27 | |
| *** chlong_ has joined #openstack-keystone | 13:40 | |
| *** jdennis has joined #openstack-keystone | 13:42 | |
| *** mvk has quit IRC | 13:52 | |
| *** prashkre__ has quit IRC | 13:53 | |
| *** spilla has joined #openstack-keystone | 14:03 | |
| *** breton has quit IRC | 14:07 | |
| *** lamt has joined #openstack-keystone | 14:11 | |
| *** lamt has quit IRC | 14:12 | |
| *** links has quit IRC | 14:12 | |
| *** lamt has joined #openstack-keystone | 14:25 | |
| dstanek | rderose: look as https://review.openstack.org/440593 and let me know where our thoughts don't jive | 14:25 |
| rderose | dstanek: okay | 14:27 |
| *** edmondsw has joined #openstack-keystone | 14:32 | |
| rderose | dstanek: what is the key a hash of? | 14:32 |
| *** breton has joined #openstack-keystone | 14:32 | |
| rderose | dstanek: ah, I see random bytes | 14:34 |
| dstanek | rderose: yep, random bytes | 14:35 |
| dstanek | rderose: i think that spec is really only missing a strong justification and some elaboration on the security issues | 14:36 |
| dstanek | and then that would be a clear picture of how i see api keys | 14:36 |
| rderose | dstanek: yeah, I think that can work. the only issue is hitting the database for every validation | 14:36 |
| rderose | but as we discussed, we're already doing that with revocation events | 14:37 |
| dstanek | rderose: i think we are doing that for other reasons too. remember when you validate a token you get back a ton of information | 14:37 |
| rderose | dstanek: okay | 14:38 |
| *** ngupta has joined #openstack-keystone | 14:42 | |
| *** ngupta_ has joined #openstack-keystone | 14:43 | |
| *** johndperkins has joined #openstack-keystone | 14:45 | |
| *** ngupta has quit IRC | 14:46 | |
| *** ngupta_ has quit IRC | 14:49 | |
| *** ngupta has joined #openstack-keystone | 14:49 | |
| *** prashkre has joined #openstack-keystone | 14:50 | |
| openstackgerrit | Merged openstack/keystone master: Remove EndpointFilterCatalog https://review.openstack.org/438210 | 14:51 |
| *** mvk has joined #openstack-keystone | 14:56 | |
| *** lamt has quit IRC | 15:01 | |
| *** johndperkins has quit IRC | 15:03 | |
| *** johndperkins has joined #openstack-keystone | 15:05 | |
| *** dikonoor has quit IRC | 15:06 | |
| *** rderose has quit IRC | 15:11 | |
| openstackgerrit | Merged openstack/keystone master: Exchange cURL examples for openstackclient https://review.openstack.org/438389 | 15:13 |
| dstanek | i'd be interested in hearing from dolphm, notmorgan, jamielennox|away and others https://review.openstack.org/440593 - do my thoughts on API keys reflect yours? | 15:14 |
| *** ravelar has joined #openstack-keystone | 15:16 | |
| *** chris_hultin|AWA is now known as chris_hultin | 15:16 | |
| *** lamt has joined #openstack-keystone | 15:19 | |
| dolphm | dstanek: i'll review, but the one thought i had that i threw on that easel was that api keys should be subject to quota limits, so you should only be able to generate like 100 api keys per user by default, or something | 15:22 |
| dolphm | dstanek: just to prevent the "i need to boot a vm! <create API key> <use API key to boot vm> <discard API key>" pattern like we see with tokens | 15:23 |
| dstanek | dolphm: lol, sure. that would be so much harder then the normal flow already :-) | 15:25 |
| dstanek | dolphm: at least we'll have quote in keystone. now keystone can use it too! | 15:25 |
| *** dave-mccowan has joined #openstack-keystone | 15:26 | |
| dolphm | dstanek: specifically, i don't want them to expire, and i want there to be such a low number of API keys that cache hits are likely | 15:26 |
| dolphm | dstanek: and yeah, dogfood | 15:26 |
| dstanek | dolphm: we have to be careful with caching since api keys are more like passwords than tokens | 15:28 |
| dolphm | dstanek: don't we already hash or encrypt tokens in cache? | 15:29 |
| dstanek | "more like" meaning a compromise of an api key is like a compromise of a password (with a limited scope) since there is no expiration | 15:29 |
| dolphm | dstanek: (in auth_token) | 15:29 |
| dstanek | dolphm: yes, i'm not worried about the actual storage. just limiting the mess in case of a compromise | 15:30 |
| *** spzala has joined #openstack-keystone | 15:30 | |
| dolphm | dstanek: ++ | 15:31 |
| dstanek | for example, it may be wise to cache the output of an api-key (like the token body style response) and make sure we hit the DB each time (or much more frequently) to make sure it's still valid | 15:31 |
| *** lucasxu has joined #openstack-keystone | 15:32 | |
| *** lamt has quit IRC | 15:33 | |
| dolphm | dstanek: so, like count() whether the key is in the db, and if so, you know it's immutable and you can return from cache? why not just delete from cache when an api key is revoked? | 15:33 |
| *** lamt has joined #openstack-keystone | 15:34 | |
| dstanek | dolphm: actually that's a good point. i was thinking of distributed caching like with varnish | 15:35 |
| dstanek | doing too many things at once this morning | 15:35 |
| dolphm | man, i haven't heard anyone mention varnish in forever | 15:35 |
| dolphm | dstanek: are any openstack deployers using varnish? | 15:36 |
| dstanek | probably not. our cache headers suck | 15:39 |
| dstanek | i use it for all kinds of things though | 15:39 |
| dolphm | oh, that's true | 15:39 |
| prashkre | rodrigods:lbragstad: Hi Lance/Rodrigo. I am working on the follow up patch for https://review.openstack.org/#/c/440281. Could you please help me how to release notes. do we follow any process to create release notes? | 15:41 |
| lbragstad | prashkre i'm actually in the middle of reviewing that patch :) | 15:42 |
| prashkre | lbragstad: sure. | 15:43 |
| *** rakhmerov has quit IRC | 15:43 | |
| *** rderose has joined #openstack-keystone | 15:46 | |
| prashkre | lbragstad: At time of my first contribution, I have followed [1] to create release notes for nova. do we have any such process for keystone. [1] https://docs.openstack.org/developer/nova/code-review.html?highlight=release%2520notes#release-notes | 15:48 |
| *** rakhmerov has joined #openstack-keystone | 15:49 | |
| gagehugo | prashkre that's what I use as well | 15:50 |
| gagehugo | it's the same process | 15:50 |
| notmorgan | dolphm: we do not encrypt tokens in cache. in ksm there is an option. to but is rarely used. | 15:50 |
| notmorgan | and we have not implemented cache control stuff for keystone, we should. | 15:51 |
| dolphm | "we do not" == "devstack doesn't" ? | 15:51 |
| dstanek | prashkre: yeah, keystone uses reno so the docs apply here as well | 15:52 |
| dstanek | notmorgan: i thought we did encrypt tokens in the cache | 15:52 |
| notmorgan | you have to configure it I. ksm | 15:53 |
| notmorgan | in* | 15:53 |
| notmorgan | most people I know don't bother to | 15:53 |
| notmorgan | keystone does not have those options. | 15:53 |
| dstanek | notmorgan: fair enough. we support it even if it's not used | 15:54 |
| dstanek | keystone should if we cache credentials | 15:54 |
| notmorgan | dolphm: I want an expiration always passed on creation of API keys, but 0 means doesn't expire | 15:54 |
| notmorgan | dolphm: and I agree, quota limit on them is good. | 15:54 |
| dolphm | null is more explicit than a timestamp in the past | 15:55 |
| dstanek | notmorgan: any other thoughts about the implementation. i documented what i thought to be a real simple implementation | 15:55 |
| notmorgan | dolphm: sure, but must be passed. | 15:55 |
| dstanek | also, why do we use X-Auth-Token instead of Authorization? | 15:55 |
| notmorgan | dstanek: I can implement the encryption in cache in about 10m in dogpile | 15:55 |
| bknudson_ | if you delete your token while the instance is booting it'll fail. | 15:56 |
| dolphm | dstanek: that's what nova or swift used before keystone existed *shrug* | 15:56 |
| bknudson_ | (I mean the instance will fail to boot) | 15:56 |
| notmorgan | because folks who did that didn't read the RFC saying don't x-prefix headers ;) | 15:57 |
| dstanek | notmorgan: not cache encryption implementation - api key implementation | 15:57 |
| notmorgan | but yeah historical, nova did that before, we do it now | 15:57 |
| notmorgan | dstanek: I was commenting we can implement encryption in cache trivially. | 15:58 |
| notmorgan | that's all. | 15:58 |
| dstanek | what i've not thought through is what nova does with an | 15:58 |
| dstanek | API key. just pass it through like a token? | 15:58 |
| *** lamt has quit IRC | 15:58 | |
| dstanek | or would they go and get a token for it? | 15:59 |
| notmorgan | well depends on implementation | 15:59 |
| notmorgan | me, I'd like to make it a signed request | 15:59 |
| bknudson_ | the api key better have the catalog so that nova can find the other services | 15:59 |
| notmorgan | but that is a lot of moving parts | 15:59 |
| *** rcernin has quit IRC | 15:59 | |
| notmorgan | likely need to use it to get a token | 15:59 |
| notmorgan | because of service catalog reasons. | 15:59 |
| rderose | notmorgan: that is how I originally thought of it | 15:59 |
| rderose | notmorgan: https://review.openstack.org/#/c/438761/8 | 16:00 |
| notmorgan | also <rant>stupid endpoint being dynamic based upon user token</rant> | 16:00 |
| rderose | working on updating this though | 16:00 |
| *** ayoung has quit IRC | 16:00 | |
| notmorgan | the endpoint filtering based on tokens is going to bite us again here. | 16:00 |
| notmorgan | anyways, so likely needs a normal token. | 16:00 |
| *** chlong_ has quit IRC | 16:01 | |
| bknudson_ | I don't think we considered the issues with endpoint filtering and how nova uses tokens. | 16:01 |
| *** chlong__ has joined #openstack-keystone | 16:01 | |
| bknudson_ | what if glance is filtered out and I try to boot an instance? | 16:02 |
| notmorgan | I am still of the opinion the catalog should be static and not change because of auth context. the endpoint should say "nope" if it isn't allowed. | 16:02 |
| notmorgan | bknudson_: you are possibly very broken. | 16:02 |
| notmorgan | we don't test those cases... in fact I'd use that as an argument to deprecate filtering. | 16:02 |
| notmorgan | ;) | 16:02 |
| dstanek | rderose: i think the same way about the service. weren't you also thinkin thinking that the user would need to get a token for the api-key? | 16:02 |
| notmorgan | if the catalog was static, things like apikeys could go straight to the service. | 16:03 |
| bknudson_ | maybe nova shouldn't use the client's service catalog. | 16:03 |
| notmorgan | or you could do discovery if you need. | 16:03 |
| dstanek | notmorgan: signed requests would be awesome, but i think that it could be added on later | 16:03 |
| bknudson_ | what's the advantage of signed requests over client certificates? | 16:04 |
| notmorgan | bknudson_: different mechanism for validation. x509 is heavy to validate everywhere. | 16:04 |
| *** rderose has quit IRC | 16:04 | |
| notmorgan | signed requests can be confirmed by keystone via ksm | 16:05 |
| *** rderose has joined #openstack-keystone | 16:05 | |
| dstanek | notmorgan: wait, so you're thnking that the user never sends the api-key to nova? | 16:05 |
| notmorgan | signed request would be sent to the endpoint directly. | 16:05 |
| notmorgan | dstanek: that would be my choice, the API key would be the signing secret | 16:05 |
| bknudson_ | signed requests seem to break REST... I'm not going to sign requests by hand. | 16:05 |
| rderose | dstanek: a token for the API key? the other way round, you auth with an api key and request a token was my original thought | 16:05 |
| notmorgan | hmac, time, nonce, request, secret id | 16:06 |
| notmorgan | ksm asks keystone to validate. (same as today) | 16:06 |
| notmorgan | keystone validates. | 16:06 |
| bknudson_ | a fernet token from an API key would be very small | 16:06 |
| notmorgan | secret never hits the wire. | 16:06 |
| dstanek | rderose: user presents api-key and gets token is what i was saying | 16:06 |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Validate rolling upgrade is run in order https://review.openstack.org/437441 | 16:06 |
| rderose | dstanek: ah, yes | 16:06 |
| notmorgan | dstanek: that would be my choice, second choice is api-key to nova direct, third (easier and most likely to be implemented) api-key to keystone for token | 16:07 |
| *** markvoelker has quit IRC | 16:07 | |
| notmorgan | we can also work backwards | 16:07 |
| bknudson_ | let's just start API keys with "MII" and then auth_token knows what it is. | 16:07 |
| dstanek | if api-key isn't a bearer token then it's not really an api-key; at that point we are just providing the user with "alternative passwords" #notmyauthz | 16:08 |
| rderose | bknudson_: "MII"? | 16:08 |
| notmorgan | bknudson_: I kind of hate you right now ;) | 16:08 |
| bknudson_ | that's how auth_token used to figure out if a token was PKI or UUID. | 16:08 |
| notmorgan | rderose: PKI tokens. | 16:08 |
| bknudson_ | it's probably still there. | 16:09 |
| dstanek | bknudson_: ++ MI6 would be cooler | 16:09 |
| rderose | :) | 16:09 |
| notmorgan | bknudson_: I thought we ripped that Mii crap out | 16:10 |
| *** ayoung has joined #openstack-keystone | 16:10 | |
| notmorgan | though we may not have removed the CMS code from everywhere. | 16:10 |
| bknudson_ | actually, auth_token sends every token to keystone for validation now so it's just keystone would have to know that the token's an API key | 16:10 |
| bknudson_ | API key would have to be scoped | 16:11 |
| notmorgan | yes | 16:11 |
| rderose | bknudson_: yeah, agree | 16:12 |
| prashkre | gagehugo:dstanek: Thank you!. | 16:12 |
| *** markvoelker has joined #openstack-keystone | 16:12 | |
| rderose | bknudson_: but if we treat API keys as a credential that auths and request a scoped token, then validation doesn't have to change (maybe) | 16:12 |
| bknudson_ | sure. I was thinking of the case of being able to use api keys against nova directly. | 16:13 |
| rderose | bknudson_: I see | 16:13 |
| notmorgan | bknudson_: if we do that can we just jump to signed requests. | 16:14 |
| bknudson_ | which might be a useful feature | 16:14 |
| notmorgan | it eliminates the secret on the wire. | 16:14 |
| notmorgan | no more scrubbing of logs needed in ksm/nova | 16:14 |
| notmorgan | no secrets in the logs | 16:14 |
| bknudson_ | my problem with signed requests is I can't do them using curl | 16:15 |
| notmorgan | we could write a curl extension ;) | 16:15 |
| bknudson_ | so auth_token middleware would validate the signature? | 16:15 |
| notmorgan | ATM would send to keystone. same as a time | 16:15 |
| notmorgan | token* | 16:15 |
| bknudson_ | the whole request? | 16:16 |
| notmorgan | yes, minus body like glance image thing | 16:16 |
| notmorgan | not body, data like glance images | 16:16 |
| bknudson_ | ok, so the headers would give you enough info to check that the user made the request... | 16:17 |
| bknudson_ | it's not really to protect the data, just to prove the user was the sender | 16:17 |
| notmorgan | yes | 16:18 |
| bknudson_ | that sounds ok... maybe can limit the headers so it's not all of them. | 16:18 |
| notmorgan | and keystone would return the values expected same as validation | 16:18 |
| notmorgan | of tokens. | 16:18 |
| *** lamt has joined #openstack-keystone | 16:18 | |
| bknudson_ | and limit the header size. so wouldn't be too much data | 16:18 |
| bknudson_ | ok, let's do that. | 16:19 |
| *** lamt has quit IRC | 16:19 | |
| bknudson_ | do we need to prevent replay attacks? So keystone needs to store the nonces already used? | 16:20 |
| notmorgan | we would use ksm for nonces IMO | 16:20 |
| bknudson_ | we'd have to figure out how nova could "forward" the request. | 16:21 |
| notmorgan | keystone doesn't need to care, ksm can care for it, since I'd make endpoint part of the signature. | 16:21 |
| notmorgan | to start, we can just pass back an actual token to nova for the forwarding. | 16:22 |
| notmorgan | and make keystone tokens mostly a service-to-service thing | 16:22 |
| notmorgan | then clean that up as the next bit | 16:22 |
| bknudson_ | would require a change to nova since it's not getting the token from auth_token | 16:22 |
| notmorgan | ksm would pass the token down in the context | 16:23 |
| notmorgan | don't need to change nova, ksm owns the request before it hits nova | 16:23 |
| bknudson_ | y, we can make it work, just saying nova doesn't get the token from auth_token, it gets it from the original request. | 16:23 |
| notmorgan | right, ksm can fudge that for nova | 16:24 |
| bknudson_ | ah, I see. | 16:24 |
| notmorgan | since ksm can muck with the request object. | 16:24 |
| bknudson_ | just update the request to set x-auth-token. | 16:24 |
| notmorgan | yep | 16:24 |
| notmorgan | the idea is to separate concerns further. service to service is one workflow that is hard to change | 16:25 |
| notmorgan | user to service is easier in many ways | 16:25 |
| *** dikonoor has joined #openstack-keystone | 16:25 | |
| notmorgan | give users a better mechanism, with benefits, they'll use ot | 16:25 |
| notmorgan | it* | 16:25 |
| *** prashkre has quit IRC | 16:26 | |
| *** prashkre has joined #openstack-keystone | 16:26 | |
| notmorgan | services are a lot of code change, so we focus on that as a separate concern. we may find service to service bearer tokens are the best choice and just keep it. | 16:26 |
| notmorgan | also if the catalog is static, user can just get the catalog (light weight keystone call) and send signed request to <endpoint> | 16:27 |
| notmorgan | if discovery is needed. | 16:27 |
| bknudson_ | I thought we were just going to use dns. | 16:28 |
| notmorgan | I'd like that | 16:28 |
| notmorgan | but if we can't, ... we could still do keystone discovery | 16:29 |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Extend User API to support federated attributes https://review.openstack.org/426449 | 16:29 |
| *** lamt has joined #openstack-keystone | 16:30 | |
| *** prashkre has quit IRC | 16:30 | |
| *** ducttape_ has joined #openstack-keystone | 16:30 | |
| *** ducttape_ has left #openstack-keystone | 16:31 | |
| openstackgerrit | Merged openstack/keystone master: Fix some typo in releasenotes https://review.openstack.org/437770 | 16:38 |
| *** h5t4 has quit IRC | 16:41 | |
| *** agrebennikov_ has joined #openstack-keystone | 16:42 | |
| *** pcaruana has quit IRC | 16:42 | |
| *** prashkre has joined #openstack-keystone | 16:46 | |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: Fix duplicate handling for user-specified IDs https://review.openstack.org/438896 | 16:47 |
| *** browne has joined #openstack-keystone | 16:48 | |
| *** _cjones_ has joined #openstack-keystone | 16:49 | |
| *** _cjones_ has quit IRC | 16:49 | |
| *** _cjones_ has joined #openstack-keystone | 16:50 | |
| *** egonzalez has quit IRC | 17:08 | |
| *** dave-mcc_ has joined #openstack-keystone | 17:12 | |
| *** dave-mccowan has quit IRC | 17:13 | |
| *** dave-mccowan has joined #openstack-keystone | 17:15 | |
| *** dave-mcc_ has quit IRC | 17:17 | |
| *** aasthad has joined #openstack-keystone | 17:19 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: Change is_admin_project to False by default https://review.openstack.org/438035 | 17:25 |
| dstanek | bknudson_: ++ to using api keys against the services | 17:29 |
| bknudson_ | seems handy but I'm not sure how many would wind up using it since they'll still be using existing tools. | 17:30 |
| bknudson_ | but if I was writing a new tool to check server status it would be easier to just use nova. | 17:31 |
| dstanek | bknudson_: the intent is for users to use it in place of passwords or tokens in config files | 17:33 |
| lbragstad | prashkre i left my comments on https://review.openstack.org/#/c/440281/1 | 17:34 |
| bknudson_ | right, so you can get a regular token using an api key | 17:34 |
| lbragstad | prashkre i think we should just remove the notification to persist the revocation event | 17:34 |
| lbragstad | prashkre instead of moving the validation bits | 17:34 |
| bknudson_ | but as an extension maybe could also support using api key against another service. | 17:35 |
| lbragstad | prashkre i have to step away for a minute | 17:35 |
| ayoung | Can I just +2A my own damn patch that has been sitting since October with only stevemar having looked at it. https://review.openstack.org/#/c/387161/ and | 17:36 |
| dstanek | bknudson_: sure you could if we didn't want to push the key to the service | 17:36 |
| *** lucasxu has quit IRC | 17:36 | |
| lbragstad | ayoung i'm still reviewing it | 17:37 |
| lbragstad | i started looking at the series yesterday | 17:37 |
| ayoung | lbragstad, TYVM | 17:37 |
| ayoung | lbragstad, but it should not be a PTL responsibility to review every patch | 17:37 |
| lbragstad | ayoung i'm not reviewing it from a PTL only perspective, i'm truly interested in it :) | 17:38 |
| ayoung | lbragstad, that is still only one reviewer. stevemar only +1ed it | 17:38 |
| *** lucasxu has joined #openstack-keystone | 17:38 | |
| * lbragstad runs away to grab lunch | 17:38 | |
| dstanek | ayoung: i've blocked out most of my morning tomorrow to review patches! so i'm excited about that | 17:40 |
| ayoung | dstanek, Thanks | 17:40 |
| * dstanek might be sick in the head | 17:40 | |
| knikolla | o/ | 17:41 |
| ayoung | the goal is to get down to the point where the only thing failing is the Tempest tests on the is_admin checks for Nova, Keystone, etc | 17:42 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements https://review.openstack.org/439219 | 17:43 |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone master: Remove password_expires_ignore_user_ids https://review.openstack.org/438208 | 17:46 |
| *** browne has quit IRC | 17:49 | |
| *** adrian_otto has joined #openstack-keystone | 17:52 | |
| *** tesseract has quit IRC | 17:52 | |
| ayoung | lbragstad, so the error on the last patch in the series is Tempest based: they are making admin users all over the place as opposed to onlu\y in the admin project http://logs.openstack.org/36/257636/18/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/b387390/console.html#_2017-03-01_17_25_42_159046 | 17:53 |
| *** h5t4_ has joined #openstack-keystone | 17:53 | |
| ayoung | In other words, the patch is right, the tests are wrong. | 17:53 |
| ayoung | Same is true-ish for the tests in Nova | 17:53 |
| ayoung | https://review.openstack.org/#/c/384148/ | 17:54 |
| *** lucasxu has quit IRC | 17:54 | |
| *** spzala has quit IRC | 18:06 | |
| *** erlon has joined #openstack-keystone | 18:07 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone-specs master: Add API access key credentials https://review.openstack.org/438761 | 18:10 |
| *** lamt has quit IRC | 18:16 | |
| ayoung | rderose, https://review.openstack.org/#/c/438761/9/specs/keystone/pike/api-keys.rst what is the point? | 18:17 |
| ayoung | sounds like you are mixing two different concepts there: | 18:17 |
| ayoung | 1. Servcie users | 18:17 |
| ayoung | 2. Delegations | 18:17 |
| ayoung | what's driving that? | 18:18 |
| *** jaosorior has quit IRC | 18:19 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone-specs master: Add API access key credentials https://review.openstack.org/438761 | 18:21 |
| openstackgerrit | Ron De Rose proposed openstack/keystone-specs master: Add API access key credentials https://review.openstack.org/438761 | 18:25 |
| rderose | ayoung: this came out of the ptg, the main use case is allowing me as a developer to give limited access to my scripts or jobs that run against my project resources | 18:27 |
| rderose | ayoung: so that I'm not putting my username/password in configuration files | 18:28 |
| rderose | ayoung: jamielennox started this conversation, he has spec out there that's similar, but was more about having different authorization for each type of auth method: | 18:29 |
| *** edmondsw has quit IRC | 18:29 | |
| rderose | ayoung: https://review.openstack.org/#/c/389870/ | 18:29 |
| ayoung | rderose, so its roughly comparable to allowing an average user to create a service user and giving them a non-redelegatable limited access trust | 18:30 |
| ayoung | yep, I've talked about that with him | 18:30 |
| rderose | ayoung: yeah, I suppose (that was a mouth full :) ) | 18:30 |
| *** Krishna has joined #openstack-keystone | 18:30 | |
| *** dikonoor has quit IRC | 18:31 | |
| *** Krishna has quit IRC | 18:31 | |
| ayoung | the unified delegation stuff that amakarov was working on a while back would support this | 18:31 |
| rderose | ayoung: oh really | 18:31 |
| *** kris7987 has joined #openstack-keystone | 18:31 | |
| ayoung | yep, the idea is that we should not have different delegation mechanisms for role assignments, trusts, OAUTH, and now this | 18:32 |
| rderose | hmm... | 18:32 |
| *** edmondsw has joined #openstack-keystone | 18:32 | |
| *** lucasxu has joined #openstack-keystone | 18:32 | |
| ayoung | rderose, I like where you are going with this, but please look at the existing mechanisms and reuse where ever possible | 18:32 |
| rderose | ayoung: okay | 18:32 |
| kris7987 | is there any effort going to support Cassandra as backend for Keystone? if so what is the timeline? | 18:33 |
| rderose | ayoung: are you thinking, in terms of existing mechanisms, as OAuth and/or delegation? | 18:34 |
| ayoung | kris7987, no and I would not pursue | 18:34 |
| ayoung | rderose, look at the unified delegation patches...I think they are still posted | 18:34 |
| rderose | ayoung: cool, will do. thx | 18:34 |
| ayoung | rderose, IE...its hard to get this right. You want to reuse the mechanisms in the trusts code | 18:34 |
| kris7987 | @ayoung is there any reason? | 18:35 |
| ayoung | kris7987, yes, long history. We origianlly were built on a Key-value-pair based architecture | 18:35 |
| ayoung | its all SQL now due to the complexity of the interelationships between the objects | 18:36 |
| ayoung | that is a really short version, probably unsatisfying, but let me ask...why Cassandra? | 18:36 |
| *** edmondsw has quit IRC | 18:36 | |
| kris7987 | @ayoung thanks | 18:36 |
| ayoung | BTW, no @ sign needed in IRC | 18:36 |
| kris7987 | @young well or any other distributed DB's for handling Multi-DC situations. | 18:37 |
| ayoung | kris7987, the biggest frustration most people have with the MySQL based approach is multi-site. Is that the problem you are trying to deal with? | 18:37 |
| kris7987 | ok | 18:37 |
| kris7987 | yes | 18:37 |
| openstackgerrit | Merged openstack/keystone master: Removing group role assignments results in overly broad revocation events https://review.openstack.org/440281 | 18:39 |
| ayoung | kris7987, yeah, Gallera multi-site seems to be what the operators have all settled on. With Keystone and Fernet tokens, the worst of the lag problems are handled OK | 18:40 |
| ayoung | you can issue tokens from one server and validate them on another OK | 18:40 |
| kris7987 | yes i was thinking along the same line. | 18:41 |
| notmorgan | there is nothing that prevents a cassandra backend... but keeping parity with the codebase is a challenge. | 18:41 |
| ayoung | fernet does not hit the Database. Doesn't help when you are doing updates, but those should be rare enough cross database... | 18:41 |
| openstackgerrit | Ron De Rose proposed openstack/keystone-specs master: Add API access key credentials https://review.openstack.org/438761 | 18:41 |
| ayoung | notmorgan, you removed the KVS code yourself, you hippogriff | 18:41 |
| notmorgan | ayoung: yes i did | 18:41 |
| notmorgan | it doesn't mean someone can't make their own backend that is out-of-tree | 18:41 |
| notmorgan | sorry i wasn't clear on that | 18:41 |
| ayoung | notmorgan, I like what Termie said about plugins in his "OpenStack is doomed" talk] | 18:42 |
| ayoung | basically its our way of saying "we don;t want that" | 18:42 |
| notmorgan | plugins don't bother me. [they have a place, aka like ksa auth plugins"] | 18:42 |
| notmorgan | extensions... | 18:42 |
| notmorgan | those (much more in line with what termie was talking about) are terrible | 18:42 |
| notmorgan | and i agree cause doom-y-things | 18:43 |
| *** spzala has joined #openstack-keystone | 18:43 | |
| ayoung | notmorgan, yeah, he was referring more to 3rd party plugins, like Cinder's Augean stable of drivers that thingee cleaned way back when | 18:43 |
| kris7987 | I was also thinking of making keystone as RBAC system for managing non openstack roles | 18:43 |
| ayoung | kris7987, so was I, once upon a time | 18:43 |
| notmorgan | kris7987: you can do that but be warned... keystone really has gaps on that front and was designed with openstack in mind | 18:43 |
| notmorgan | i would like it if keystone could easily perform that as a generic authz service | 18:44 |
| ayoung | Keystone was not designed | 18:44 |
| notmorgan | it... well, it does things weird. | 18:44 |
| notmorgan | ayoung: lol true enough. | 18:44 |
| ayoung | it emerged. Crawled from the slime of dark Scottish Loch | 18:44 |
| *** jose-phi_ has joined #openstack-keystone | 18:44 | |
| notmorgan | ayoung: nothing that cool, def. didn't come from scotland. it was dredged out of the SF bay | 18:45 |
| ayoung | I think it was dredged from a river in San Antonio prepraring for the River Walk revitalization | 18:45 |
| notmorgan | hah | 18:45 |
| ayoung | you are thinking of Treasure Island | 18:46 |
| *** jose-phillips has quit IRC | 18:46 | |
| kris7987 | you know with some changes.keystone really has a shot on becoming a generic RBAC/ API gateway solution ;-) | 18:51 |
| *** spzala has quit IRC | 18:51 | |
| *** jdennis has quit IRC | 18:51 | |
| *** jdennis has joined #openstack-keystone | 18:57 | |
| *** kris7987 has quit IRC | 18:58 | |
| *** _cjones_ has quit IRC | 19:01 | |
| *** _cjones_ has joined #openstack-keystone | 19:01 | |
| lbragstad | ravelar what happens if we do valdiation in the controller for the federated attributes? https://review.openstack.org/#/c/426449/28/keystone/identity/schema.py | 19:04 |
| *** _cjones_ has quit IRC | 19:06 | |
| *** adrian_otto has quit IRC | 19:07 | |
| lbragstad | ravelar for v3, we typically try to keep validation of requests in the controller layer, instead of buried in the manager | 19:07 |
| ravelar | lbragstad validation already happens with json schema right? | 19:08 |
| lbragstad | ravelar what happens if we move validation from identity/core.py to identity/schema.py? | 19:08 |
| ravelar | lbragstad what validation exactly are you referring to? | 19:08 |
| lbragstad | ravelar right - we define a scheme of things we accept and the schema is enforced at the controller level | 19:08 |
| lbragstad | ravelar for example https://github.com/openstack/keystone/blob/master/keystone/identity/schema.py is our schema for identity related objecst | 19:09 |
| *** thorst has quit IRC | 19:09 | |
| lbragstad | ravelar which we apply in the controllers https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L215 | 19:09 |
| ravelar | lbragstad yes | 19:09 |
| *** thorst has joined #openstack-keystone | 19:10 | |
| lbragstad | ravelar your patch does some additional validation in the identity manager - https://review.openstack.org/#/c/426449/28/keystone/identity/core.py | 19:10 |
| ravelar | lbragstad right, unit tests call manager directly with self.identity_api which bypass this in some cases | 19:10 |
| lbragstad | ravelar I'm wondering what happens if we move the validation you're introducing in core.py into the schema we already have defined in identity/schema.py | 19:10 |
| rderose | lbragstad ravelar: so the main issue is we can't enforce that fed != [] without fixing a ton of tests, right? | 19:10 |
| lbragstad | ahhh | 19:11 |
| ravelar | yeah, moral of the story is you can validate it anywhere and it will fail regardless if you force the constraint of all or nothing | 19:11 |
| lbragstad | ravelar so your patch works now because you have the validation in core.py | 19:11 |
| lbragstad | ravelar but if you move that validation into jsonschema, then it fails because you're bypassing the controller | 19:12 |
| lbragstad | and other tests are hitting the issue because they aren't going through the controller | 19:12 |
| ravelar | lbragstad exactly | 19:12 |
| lbragstad | ravelar i see | 19:13 |
| lbragstad | hmmm | 19:13 |
| ravelar | lbragstad alot of unit tests for user go straight to self.identity_api.create_user and then recycle the user to again go back into identity_api | 19:13 |
| lbragstad | so - in order for us to do this properly (in the sense that we keep validation in the controller) we have to refactor a lot of tests | 19:13 |
| lbragstad | because we do things like self.identity_api.create_user() **everywhere** in the tests to set things up, which calls directly into the manage and bypasses validation | 19:14 |
| *** edmondsw has joined #openstack-keystone | 19:14 | |
| *** thorst has quit IRC | 19:14 | |
| ravelar | lbragstad yup, its actually quiet intersting | 19:14 |
| lbragstad | ravelar do you know how many tests fail as a byproduct of moving this all into controller validation? | 19:15 |
| *** adrian_otto has joined #openstack-keystone | 19:16 | |
| ravelar | lbragstad let me get that for you | 19:17 |
| knikolla | i'm already in the process of trying to refactor ldap tests, so i can help if you decide to tackle this | 19:18 |
| knikolla | refactoring is fun | 19:18 |
| *** lucasxu has quit IRC | 19:18 | |
| lbragstad | knikolla i would say it depends on the refactor ;) | 19:19 |
| *** lucasxu has joined #openstack-keystone | 19:19 | |
| ravelar | lbragstad ++ | 19:19 |
| ravelar | knikolla has a go to attitude | 19:19 |
| *** prashkre has quit IRC | 19:20 | |
| knikolla | :) | 19:22 |
| *** adrian_otto has quit IRC | 19:23 | |
| *** adrian_otto has joined #openstack-keystone | 19:25 | |
| lbragstad | knikolla ravelar rderose so - ideally we would want our v3 tests to use self.post('v3/users/') instead of self.identity_api.create_user() | 19:25 |
| ravelar | lbragstad knikolla test that fail from no validation in core for attribute 20 | 19:25 |
| ravelar | lbragstad knikolla current times that self.identity_api.some_user_method is called to bypass controller 200+ | 19:26 |
| lbragstad | for some reason I think i was expecting that to be more | 19:27 |
| knikolla | same | 19:27 |
| ravelar | lbragstad well the tests inside api unit testing like test_v3_identity already call self.post | 19:28 |
| ravelar | its the ones inside things like identity/test_core | 19:28 |
| ravelar | that essentially do this | 19:28 |
| lbragstad | ravelar knikolla maybe we should start an etherpad | 19:28 |
| knikolla | lbragstad: ++ | 19:29 |
| lbragstad | knikolla ravelar rderose https://etherpad.openstack.org/p/keystone-v3-federated-attribute-test-refactor | 19:29 |
| ravelar | lbragstad so my question is, we still call self.identity_api.create_user, etc when we are specifically trying to test the functionality of the method | 19:30 |
| ravelar | lbragstad only in the instance of the failing tests we should use something like unit.new_user when we want to just create a new user for things that dont require going to self.identity_api.create_user? | 19:30 |
| lbragstad | ravelar I think that would be the starting point because it's the least amount of work for us to merge that patch | 19:33 |
| lbragstad | ravelar but I think we eventually need to come to consensus on how we go about setting things up in tests. | 19:33 |
| ravelar | lbragstad ah I see :) | 19:35 |
| *** lamt has joined #openstack-keystone | 19:35 | |
| knikolla | we need to also take into consideration nonwritable backends | 19:35 |
| knikolla | otherwise a lot of ldap code will stay there indefinitely | 19:35 |
| knikolla | but that's a next step | 19:36 |
| rderose | lbragstad: following the etherpad and agree | 19:36 |
| *** lamt has quit IRC | 19:36 | |
| rderose | lbragstad: but for 426449, we could keep the check in core for now | 19:36 |
| rderose | lbragstad ravelar: and do this refactoring/fixing in subsequent patches | 19:37 |
| *** lamt has joined #openstack-keystone | 19:37 | |
| rderose | knikolla: ^ | 19:37 |
| knikolla | rderose: that can work too. | 19:37 |
| robcresswell | lbragstad: o/ Just had a thought, we probably dont have much to discuss in the cross-project this week. Should I cancel this weeks one? | 19:37 |
| *** MasterOfBugs has joined #openstack-keystone | 19:37 | |
| lbragstad | robcresswell sure - that sounds good | 19:37 |
| knikolla | rderose: nothing will change behaviour-wise | 19:37 |
| rderose | knikolla: right | 19:38 |
| lbragstad | robcresswell i thought last weeks dicussion was good | 19:38 |
| lbragstad | discussion* | 19:38 |
| robcresswell | lbragstad: Me too! It's got me thinking about trying to setup weekly meetings with other projects | 19:38 |
| lbragstad | robcresswell ++ | 19:38 |
| *** spilla has quit IRC | 19:38 | |
| lbragstad | robcresswell i like the pattern and it proved productive, at least for our groups | 19:39 |
| robcresswell | We've solved a bunch of issues and then have more in the pipeline. Very productive | 19:39 |
| robcresswell | Agreed | 19:39 |
| *** adrian_otto has quit IRC | 19:45 | |
| *** edmondsw has quit IRC | 19:47 | |
| lbragstad | ravelar do you have a diff of moving the validation into schema.py? I was going to run all the tests with it to get a list of things we need to fix | 19:47 |
| ravelar | lbragstad removed it earlier to work on another patch, but I quickly added the change again | 19:49 |
| ravelar | lbragstad one sec | 19:49 |
| lbragstad | ravelar i have a copy locally too that i'm working on too | 19:49 |
| *** edmondsw has joined #openstack-keystone | 19:50 | |
| ravelar | here is the one I did when I made the changes you wanted | 19:50 |
| ravelar | ahh it disappeared | 19:51 |
| *** ayoung has quit IRC | 19:53 | |
| ravelar | lbragstad http://paste.openstack.org/show/601177/ | 19:54 |
| lbragstad | ravelar sweet - that's pretty much what i changed locally | 19:55 |
| lbragstad | http://cdn.pasteraw.com/tgsqgiuc7lktmsh6ftskxnxz2zp8ldy | 19:57 |
| *** jamielennox|away is now known as jamielennox | 20:02 | |
| knikolla | lbragstad: thoughts on https://bugs.launchpad.net/keystone/+bug/1669070 ? should i go ahead and change the router? | 20:14 |
| openstack | Launchpad bug 1669070 in OpenStack Identity (keystone) "Checking whether group has role assignment on domain without specifying a role ID result in HTTP 200" [Undecided,New] | 20:14 |
| lbragstad | knikolla yeah - i saw that one yesterday, i still need to dig into it | 20:16 |
| lbragstad | knikolla are you able to recreate it? | 20:16 |
| knikolla | yeah. the list_grants call is registered for both get and head, so roles/ gives back the head of listing. | 20:17 |
| knikolla | lbragstad | 20:17 |
| lbragstad | ravelar do the failures in the etherpad look consistent with the ones you found? | 20:17 |
| lbragstad | knikolla hmm | 20:17 |
| knikolla | lbragstad: https://github.com/openstack/keystone/blob/master/keystone/assignment/routers.py#L190 | 20:18 |
| *** lamt has quit IRC | 20:23 | |
| lbragstad | knikolla interesting - i think there are two bugs there, right? | 20:23 |
| lbragstad | knikolla one is that head shouldn't return a body | 20:23 |
| lbragstad | knikolla and the other is that if you pass that call a non-existent role, it returns 200 instead of a 400 or 404 | 20:23 |
| knikolla | lbragstad: it's not returning a body. well, it's setting content-type to json, but there is no body. | 20:24 |
| lbragstad | knikolla ah - ok, for some reason I was thinking a body was getting returned | 20:24 |
| *** lamt has joined #openstack-keystone | 20:25 | |
| knikolla | lbragstad: the other one is because it's going to the listing api call (which also supports head) | 20:25 |
| lbragstad | so GET returns the body HEAD does not, right? | 20:25 |
| knikolla | lbragstad: yes | 20:25 |
| lbragstad | good | 20:25 |
| knikolla | lbragstad: the bug isn't as much as a "non-existant" role, but an empty role. if you pass 123 as the role it gives back 404 correctly. | 20:26 |
| knikolla | with no role present it strips the ending "/" and does a head on role list | 20:27 |
| knikolla | so the fix is either making role listing with HEAD return 404 | 20:27 |
| knikolla | or leaving the current behaviour | 20:27 |
| lbragstad | knikolla oh | 20:27 |
| lbragstad | got it | 20:28 |
| *** chris_hultin is now known as chris_hultin|AWA | 20:28 | |
| dstanek | i'm not quite understanding the osc->osc_lib transition all wrapped un in cliff | 20:28 |
| lbragstad | so it's the difference between https://github.com/openstack/keystone/blob/master/keystone/assignment/routers.py#L168 and https://github.com/openstack/keystone/blob/master/keystone/assignment/routers.py#L189 | 20:28 |
| knikolla | lbragstad: yes | 20:28 |
| knikolla | lbragstad: http://cdn.pasteraw.com/8qxgcubbxdbi8ku4w5p1o1bycx497g9 | 20:29 |
| lbragstad | knikolla ah... so it ultimately makes no sense to call HEAD on the list_grants api | 20:30 |
| dstanek | knikolla: is that really what it's doing? getting the first role? | 20:31 |
| lbragstad | dstanek well we have two apis that are similar, one checks the grant and the other lists the grants, | 20:32 |
| knikolla | dstanek: no, it's just giving back the head of role listing when no role_id has been provided. as it strips our the ending "/" | 20:32 |
| lbragstad | but it doesn't make sense to call HEAD on the list grants api because there is no body | 20:32 |
| lbragstad | returned from keystone | 20:32 |
| * lbragstad dstanek https://bugs.launchpad.net/keystone/+bug/1669070 | 20:32 | |
| openstack | Launchpad bug 1669070 in OpenStack Identity (keystone) "Checking whether group has role assignment on domain without specifying a role ID result in HTTP 200" [Undecided,New] | 20:32 |
| lbragstad | knikolla the issues is that i think we'd be breaking backwards compatibility if we changed that 200 to be a 400 :( | 20:34 |
| dstanek | can you do a GET on that resource? | 20:35 |
| *** h5t4_ has quit IRC | 20:35 | |
| *** thorst has joined #openstack-keystone | 20:35 | |
| knikolla | dstanek: http://cdn.pasteraw.com/h90i1m4njvoa9tsysa8xyy6021lywsv | 20:36 |
| knikolla | lbragstad: that's my concern too, and why i asked for opinions | 20:36 |
| knikolla | lbragstad: it's undocumented behaviour, but something might rely on doing head to list_grants | 20:37 |
| lbragstad | knikolla i would imagine they are broken since you'd be expecting something back but getting nothing :( | 20:38 |
| knikolla | lbragstad: not really. GET works. | 20:38 |
| knikolla | lbragstad: the ONLY weird thing is that if you don't validate that you are passing an empty role_id, you will default to the role listing | 20:39 |
| knikolla | and if you rely on that for checking if you have a role | 20:39 |
| lbragstad | which doesn't make any sense when listing things | 20:39 |
| lbragstad | does the logic for listing check role assignment? | 20:40 |
| knikolla | lbragstad: that should work and give you back only the roles you have | 20:40 |
| knikolla | in my testing case, i have no roles on the domain | 20:41 |
| knikolla | so it's empty | 20:41 |
| lbragstad | hmm | 20:41 |
| knikolla | i don't think anything is really broken from this bug, just awkward behaviour | 20:41 |
| lbragstad | clients written to get anything useful out of HEAD list assignments are probably mislead | 20:42 |
| lbragstad | and if anyone is checking a specific assignment, they should be checking for it explicitly | 20:42 |
| lbragstad | using head to list assignment doesn't really make much sense to me | 20:43 |
| knikolla | lbragstad: check rather than list, if they don't validate strings and pass an empty one | 20:43 |
| knikolla | lbragstad: yeah | 20:43 |
| lbragstad | curious to hear if dstanek has an opinion | 20:43 |
| lbragstad | but yeah - it sounds like if a client isn't validating roles properly before using those api, it could get weird | 20:44 |
| lbragstad | because they would effectively be seeing a 200 OK from HEAD list assignment instead of HEAD check assignments | 20:45 |
| knikolla | we need opinionated api people | 20:47 |
| lbragstad | i wonder if anyone from the API WG is in this channel? | 20:47 |
| *** DFFlanders has joined #openstack-keystone | 20:47 | |
| *** jose-phillips has joined #openstack-keystone | 20:52 | |
| *** jose-phi_ has quit IRC | 20:53 | |
| openstackgerrit | Anthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault https://review.openstack.org/439070 | 20:56 |
| openstackgerrit | Eric Brown proposed openstack/keystone master: Modify examples to use v3 URLs https://review.openstack.org/440807 | 20:57 |
| openstackgerrit | Anthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault https://review.openstack.org/439070 | 20:58 |
| openstackgerrit | Anthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault https://review.openstack.org/439070 | 20:59 |
| *** adriant has joined #openstack-keystone | 20:59 | |
| bknudson_ | apache converts HEAD calls to GET calls. | 21:05 |
| bknudson_ | so if you're running in mod_wsgi apache keystone is never going to see a HEAD request. | 21:06 |
| dstanek | bknudson_: the backward compat rules don't allow a 2xx to go to a 4xx | 21:06 |
| lbragstad | right | 21:07 |
| dstanek | bknudson_: oops...mean lbragstad and knikolla | 21:07 |
| lbragstad | I left a comment | 21:07 |
| dstanek | HEAD should really be allowed on anything that allows a GET | 21:07 |
| * lbragstad goes to see if SpamapS is in -dev | 21:07 | |
| lbragstad | dstanek but do we have to worry about the case where a client is trying to call check_grant but accidentally calls list_grants because they didn't validate the role id before building the url? | 21:08 |
| dstanek | lbragstad: it's certainly an unfortunate API flaw, but the bug would be in the client | 21:11 |
| knikolla | dstanek: that's what i thought too about being generally acceptable for HEAD. if you can do a GET, you can do a HEAD. | 21:11 |
| openstackgerrit | Anthony Washington proposed openstack/oslo.policy master: Add additional param to policy.RuleDefault https://review.openstack.org/439070 | 21:12 |
| lbragstad | so maybe our best plan of action is to clearly document it in the API reg | 21:12 |
| lbragstad | ref* | 21:12 |
| dstanek | and bknudson_ is right. keystone won't know it's a head request. apache will ask for a GET and show off the body | 21:12 |
| knikolla | dstanek: is that always the case? i think i changed the router to only register GET for list_grants and doing HEAD gave me a 404 | 21:14 |
| knikolla | dstanek: under apache | 21:14 |
| dstanek | knikolla: i'm pretty sure. i'd have to try though | 21:15 |
| knikolla | dstanek: trying now, give me a sec | 21:16 |
| dstanek | knikolla: you can't give a 404 for a head of the same resource that give a 200 for a get | 21:16 |
| lbragstad | ah | 21:16 |
| dstanek | first line says why that's invalid https://tools.ietf.org/html/rfc7231#section-4.3.2 | 21:17 |
| knikolla | dstanek: i understand that it's invalid, i was just curious if what you said about apache is true | 21:17 |
| knikolla | dstanek: http://cdn.pasteraw.com/7vtev6z12xzdhn2qwobm8aorgmsnanz | 21:17 |
| knikolla | i changed the router to register only get for that url, and head gave a 404, while get a 200 | 21:17 |
| dstanek | knikolla: added to mod_wsgi a long time ago http://modwsgi.readthedocs.io/en/develop/release-notes/version-2.0.html maybe they changed it? | 21:18 |
| knikolla | bknudson_: ^^ | 21:18 |
| dstanek | knikolla: are you using mod_wsgi, uwsgi or something else? | 21:19 |
| knikolla | dstanek: stock devstack, so mod_wsgi | 21:19 |
| openstackgerrit | Sean Dague proposed openstack/keystone-specs master: WIP: early rough draft of unified limits https://review.openstack.org/440815 | 21:19 |
| bknudson_ | http://modwsgi.readthedocs.io/en/develop/release-notes/version-2.0.html says "20. Always change a HEAD request into a GET request." | 21:20 |
| dstanek | bknudson_: you copied my link :P | 21:20 |
| bknudson_ | it's possible the behavior of mod_wsgi has changed. | 21:21 |
| *** adrian_otto has joined #openstack-keystone | 21:21 | |
| knikolla | or our framework is doing fancy stuff | 21:21 |
| dstanek | knikolla: it can't be us - we don't have control over that | 21:22 |
| *** lamt has quit IRC | 21:22 | |
| knikolla | dstanek: bknudson_: http://modwsgi.readthedocs.io/en/develop/release-notes/version-4.3.0.html | 21:26 |
| knikolla | number 12 | 21:26 |
| bknudson_ | oh, cool | 21:27 |
| bknudson_ | maybe changed when got a newer ubuntu | 21:27 |
| knikolla | bknudson_: yeah, xenial has 4.3.0 | 21:28 |
| dstanek | interesting....so it will now do it sometimes :-) | 21:28 |
| bknudson_ | wish we had tempest testing for more keystone functions | 21:29 |
| *** edmondsw has quit IRC | 21:31 | |
| *** edmondsw has joined #openstack-keystone | 21:35 | |
| ravelar | lbragstad sorry for late comment, meetings. Yeah they are all results of calling the api directly | 21:43 |
| *** dave-mccowan has quit IRC | 21:44 | |
| *** chris_hultin|AWA is now known as chris_hultin | 21:45 | |
| *** chris_hultin is now known as chris_hultin|AWA | 21:49 | |
| lbragstad | ravelar so it's all ldap tests | 21:49 |
| ravelar | lbragstad pretty much | 21:50 |
| ravelar | all the tests were located in either test_v3_identity or identity/backends | 21:50 |
| *** anteaya has quit IRC | 21:54 | |
| *** cburgess has quit IRC | 21:54 | |
| *** cburgess has joined #openstack-keystone | 22:00 | |
| *** ravelar has quit IRC | 22:01 | |
| *** rderose has quit IRC | 22:03 | |
| *** mwheckmann has joined #openstack-keystone | 22:04 | |
| *** cburgess has quit IRC | 22:04 | |
| *** ravelar has joined #openstack-keystone | 22:05 | |
| *** anteaya has joined #openstack-keystone | 22:07 | |
| *** thorst has quit IRC | 22:08 | |
| mwheckmann | hello. I added a couple of comments to bug # 968696 and I'm wondering if I'm wait out on left field.. Should I even expect those things to work right now or we still in the incremental process of fixing the admin issue? | 22:09 |
| *** ravelar has quit IRC | 22:09 | |
| *** cburgess has joined #openstack-keystone | 22:10 | |
| knikolla | lbragstad: i plan to remove the "update" tests in a later patch | 22:12 |
| knikolla | lbragstad: i have a patch now which removes every instance of delete in ldap tests and code | 22:12 |
| knikolla | update is next | 22:12 |
| lbragstad | knikolla nice - ravelar should be able to rebase on those then | 22:13 |
| knikolla | lbragstad: we could get the patch in with the logic in the manager, like it is now, and we can move it over to the controller after that is done. | 22:14 |
| notmorgan | knikolla: what logic is the issue? | 22:14 |
| lbragstad | knikolla that's true | 22:15 |
| knikolla | notmorgan: https://etherpad.openstack.org/p/keystone-v3-federated-attribute-test-refactor | 22:15 |
| notmorgan | bknudson_: re HEAD/GET If Apache 2.X, this will not however be done if there are no Apache output filters registered which could change the response headers or content. | 22:16 |
| notmorgan | bknudson_: this is just what is passed to the backend, apache should *still* respond with the correct data from a GET. | 22:16 |
| *** cburgess has quit IRC | 22:16 | |
| notmorgan | knikolla: ah | 22:16 |
| *** cburgess has joined #openstack-keystone | 22:22 | |
| *** ngupta_ has joined #openstack-keystone | 22:32 | |
| *** rderose has joined #openstack-keystone | 22:33 | |
| notmorgan | cburgess: welcome back. | 22:34 |
| *** ngupta has quit IRC | 22:34 | |
| *** ngupta_ has quit IRC | 22:36 | |
| *** thorst has joined #openstack-keystone | 22:36 | |
| *** catintheroof has quit IRC | 22:40 | |
| *** thorst has quit IRC | 22:41 | |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone master: Move driver loading inside of dict https://review.openstack.org/440845 | 22:48 |
| cburgess | notmorgan Thanks... my znc bouncer got horked up some how. | 22:49 |
| notmorgan | cburgess: use weechat | 22:51 |
| notmorgan | cburgess: or irccloud. :P | 22:51 |
| cburgess | notmorgan Is that what all the cool kids use now? | 22:52 |
| notmorgan | eh. most cool kids don't use IRC. you must have us confused with some other group of people :P | 22:53 |
| notmorgan | ;) | 22:54 |
| *** ravelar has joined #openstack-keystone | 22:55 | |
| dstanek | mwheckmann: it depends of what you are trying to get to work | 23:01 |
| dstanek | mwheckmann: from your comment on the bug it looks like neutron isn't quite working properly. you may want to submit you patch to them through gerrit | 23:04 |
| mwheckmann | dstanek: ok. I will do that. What about my first comment though? About keystone not setting the "is_admin_project" for domain scoped tokens | 23:06 |
| dstanek | mwheckmann: i believe that should be set when you have a token scoped to a project and that project is the admin project. is that not happening for you? | 23:12 |
| mwheckmann | that is happening, but the problem is if I present a domain scoped token. I get full admin rights on certain projects because "is_admin_project" is not set and it defaults to True for legacy support. It's basically a security hole. | 23:13 |
| mwheckmann | There was a patch for that in Keystone (Token model class) but that function never seems to get called. | 23:14 |
| mwheckmann | I have to go pick up my daughter... I can continue talking about it tomorrow.. sorry. | 23:15 |
| dstanek | mwheckmann: sure, np | 23:15 |
| *** adrian_otto has quit IRC | 23:16 | |
| *** mwheckmann has left #openstack-keystone | 23:16 | |
| *** thorst has joined #openstack-keystone | 23:17 | |
| *** thorst has quit IRC | 23:19 | |
| *** lucasxu has quit IRC | 23:22 | |
| *** ngupta has joined #openstack-keystone | 23:23 | |
| *** erlon has quit IRC | 23:25 | |
| *** adrian_otto has joined #openstack-keystone | 23:32 | |
| *** MasterOfBugs has quit IRC | 23:32 | |
| *** MasterOfBugs has joined #openstack-keystone | 23:33 | |
| *** jamielennox is now known as jamielennox|away | 23:37 | |
| *** MasterOfBugs has quit IRC | 23:38 | |
| *** _cjones_ has joined #openstack-keystone | 23:55 | |
| *** _cjones_ has quit IRC | 23:55 | |
| *** _cjones_ has joined #openstack-keystone | 23:55 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements https://review.openstack.org/439219 | 23:55 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!