| *** thorst_afk has joined #openstack-keystone | 00:00 | |
| *** jamielennox|away is now known as jamielennox | 00:02 | |
| *** spzala has joined #openstack-keystone | 00:21 | |
| *** spzala has quit IRC | 00:26 | |
| *** thorst_afk has quit IRC | 00:33 | |
| *** spzala has joined #openstack-keystone | 00:38 | |
| *** thorst_afk has joined #openstack-keystone | 00:42 | |
| *** thorst_afk has quit IRC | 00:43 | |
| *** lucasxu has joined #openstack-keystone | 00:46 | |
| *** lucasxu has quit IRC | 00:46 | |
| *** zhurong has joined #openstack-keystone | 00:49 | |
| openstackgerrit | Samuel de Medeiros Queiroz proposed openstack/keystone master: Move grant policies to DocumentedRuleDefault https://review.openstack.org/449244 | 00:54 |
|---|---|---|
| *** cheran has joined #openstack-keystone | 00:58 | |
| *** jamielennox is now known as jamielennox|away | 01:00 | |
| *** jamielennox|away is now known as jamielennox | 01:10 | |
| *** thorst_afk has joined #openstack-keystone | 01:14 | |
| gagehugo | cheran awesome | 01:19 |
| *** 7GHAA59HN has joined #openstack-keystone | 01:20 | |
| *** liujiong has joined #openstack-keystone | 01:22 | |
| *** aojea has joined #openstack-keystone | 01:23 | |
| *** aojea has quit IRC | 01:27 | |
| *** zhurong has quit IRC | 01:29 | |
| *** spzala has quit IRC | 01:30 | |
| *** 7GHAA59HN has quit IRC | 01:30 | |
| *** shuyingy_ has joined #openstack-keystone | 01:30 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: Add project tags api-ref document and reno https://review.openstack.org/472396 | 01:30 |
| *** thorst_afk has quit IRC | 01:31 | |
| *** piliman974 has quit IRC | 01:33 | |
| *** piliman974 has joined #openstack-keystone | 01:35 | |
| *** markvoelker has joined #openstack-keystone | 01:35 | |
| *** namnh has joined #openstack-keystone | 01:37 | |
| *** thorst_afk has joined #openstack-keystone | 01:38 | |
| *** dave-mccowan has joined #openstack-keystone | 01:38 | |
| *** thorst_afk has quit IRC | 01:44 | |
| *** r-daneel has quit IRC | 01:47 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: Add project tags api-ref document and reno https://review.openstack.org/472396 | 01:56 |
| *** piliman974 has quit IRC | 01:59 | |
| *** zhurong has joined #openstack-keystone | 02:04 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: Add project tags api-ref documentation and reno https://review.openstack.org/472396 | 02:04 |
| *** thorst_afk has joined #openstack-keystone | 02:06 | |
| *** Shunli has joined #openstack-keystone | 02:08 | |
| *** markvoelker has quit IRC | 02:09 | |
| openstackgerrit | zhengliuyang proposed openstack/keystone master: Redundant conflict exception ensure default role https://review.openstack.org/472497 | 02:30 |
| *** thorst_afk has joined #openstack-keystone | 02:37 | |
| *** zsli_ has joined #openstack-keystone | 02:38 | |
| *** zsli__ has joined #openstack-keystone | 02:41 | |
| *** Shunli has quit IRC | 02:41 | |
| *** Shunli has joined #openstack-keystone | 02:43 | |
| *** zsli_ has quit IRC | 02:44 | |
| *** markvoelker has joined #openstack-keystone | 02:44 | |
| *** zsli__ has quit IRC | 02:45 | |
| *** thorst_afk has quit IRC | 02:48 | |
| *** spzala has joined #openstack-keystone | 02:53 | |
| *** spzala_ has joined #openstack-keystone | 02:53 | |
| *** spzala has quit IRC | 02:53 | |
| *** ducttape_ has joined #openstack-keystone | 02:59 | |
| *** phalmos has quit IRC | 03:02 | |
| *** ducttape_ has quit IRC | 03:05 | |
| *** ducttape_ has joined #openstack-keystone | 03:11 | |
| *** ducttape_ has quit IRC | 03:16 | |
| *** cheran has quit IRC | 03:17 | |
| *** dikonoor has joined #openstack-keystone | 03:27 | |
| *** ducttape_ has joined #openstack-keystone | 03:33 | |
| openstackgerrit | zhengliuyang proposed openstack/keystone master: Add annotation about token authenticate https://review.openstack.org/472511 | 03:45 |
| *** thorst_afk has joined #openstack-keystone | 03:45 | |
| *** ducttape_ has quit IRC | 03:46 | |
| *** dave-mccowan has quit IRC | 03:47 | |
| *** ducttape_ has joined #openstack-keystone | 03:52 | |
| *** ducttap__ has joined #openstack-keystone | 03:58 | |
| *** spzala_ has quit IRC | 04:00 | |
| *** ducttape_ has quit IRC | 04:01 | |
| *** ducttape_ has joined #openstack-keystone | 04:03 | |
| *** thorst_afk has quit IRC | 04:04 | |
| *** ducttap__ has quit IRC | 04:05 | |
| *** ducttape_ has quit IRC | 04:06 | |
| *** ducttape_ has joined #openstack-keystone | 04:10 | |
| *** spzala has joined #openstack-keystone | 04:17 | |
| *** ducttape_ has quit IRC | 04:17 | |
| *** links has joined #openstack-keystone | 04:20 | |
| *** spzala has quit IRC | 04:21 | |
| *** zhurong has quit IRC | 04:25 | |
| *** zhurong has joined #openstack-keystone | 04:34 | |
| *** aselius has quit IRC | 04:36 | |
| *** gyee has quit IRC | 04:49 | |
| *** spzala has joined #openstack-keystone | 04:58 | |
| *** spzala has quit IRC | 05:03 | |
| *** Guest72612 has quit IRC | 05:06 | |
| *** mfisch` has quit IRC | 05:06 | |
| *** med_ has joined #openstack-keystone | 05:06 | |
| *** mfisch has joined #openstack-keystone | 05:06 | |
| *** mfisch has quit IRC | 05:06 | |
| *** mfisch has joined #openstack-keystone | 05:06 | |
| *** med_ is now known as Guest6511 | 05:06 | |
| *** links has quit IRC | 05:10 | |
| *** aselius_ has joined #openstack-keystone | 05:12 | |
| *** tobberydberg has joined #openstack-keystone | 05:18 | |
| *** tobberydberg has quit IRC | 05:22 | |
| *** links has joined #openstack-keystone | 05:26 | |
| *** spzala has joined #openstack-keystone | 05:33 | |
| *** shuyingy_ has quit IRC | 05:33 | |
| *** shuyingy_ has joined #openstack-keystone | 05:34 | |
| *** spzala has quit IRC | 05:38 | |
| *** tobberydberg has joined #openstack-keystone | 05:41 | |
| *** nicolasbock has joined #openstack-keystone | 05:57 | |
| *** thorst_afk has joined #openstack-keystone | 06:02 | |
| *** nicolasbock has quit IRC | 06:02 | |
| *** thorst_afk has quit IRC | 06:06 | |
| *** spzala has joined #openstack-keystone | 06:13 | |
| *** nishaYadav has joined #openstack-keystone | 06:15 | |
| *** spzala has quit IRC | 06:18 | |
| *** jaosorior has joined #openstack-keystone | 06:18 | |
| *** edmondsw has joined #openstack-keystone | 06:43 | |
| *** edmondsw has quit IRC | 06:47 | |
| *** tesseract has joined #openstack-keystone | 06:53 | |
| *** zhurong has quit IRC | 06:55 | |
| *** spzala has joined #openstack-keystone | 06:55 | |
| *** zhurong has joined #openstack-keystone | 06:56 | |
| *** zhurong has quit IRC | 06:57 | |
| *** spzala has quit IRC | 06:59 | |
| *** thorst_afk has joined #openstack-keystone | 07:03 | |
| *** pcaruana has joined #openstack-keystone | 07:05 | |
| *** thorst_afk has quit IRC | 07:07 | |
| *** markvoelker has quit IRC | 07:08 | |
| cmurphy | morgan: jamielennox mordred all I cared about was not bundling an unrelated change into the endpointdata patch | 07:08 |
| *** links has quit IRC | 07:09 | |
| *** rcernin has joined #openstack-keystone | 07:09 | |
| *** spzala has joined #openstack-keystone | 07:11 | |
| *** spzala has quit IRC | 07:16 | |
| *** aselius_ has quit IRC | 07:21 | |
| *** links has joined #openstack-keystone | 07:25 | |
| *** aojea has joined #openstack-keystone | 07:31 | |
| *** bigjools has quit IRC | 07:36 | |
| *** bigjools has joined #openstack-keystone | 07:40 | |
| *** bigjools has quit IRC | 07:41 | |
| *** bigjools has joined #openstack-keystone | 07:41 | |
| openstackgerrit | Colleen Murphy proposed openstack/keystone-specs master: Application Credentials for application authn https://review.openstack.org/450415 | 07:41 |
| cmurphy | morgan: mordred lbragstad updated ^ | 07:41 |
| *** namnh has quit IRC | 07:58 | |
| *** zzzeek has quit IRC | 08:00 | |
| *** zzzeek has joined #openstack-keystone | 08:00 | |
| *** spzala has joined #openstack-keystone | 08:03 | |
| *** thorst_afk has joined #openstack-keystone | 08:03 | |
| *** spzala has quit IRC | 08:07 | |
| *** thorst_afk has quit IRC | 08:23 | |
| *** nishaYadav has quit IRC | 08:29 | |
| *** spzala has joined #openstack-keystone | 08:29 | |
| *** spzala has quit IRC | 08:34 | |
| *** shuying__ has joined #openstack-keystone | 08:36 | |
| *** shuyingy_ has quit IRC | 08:39 | |
| openstackgerrit | qtlu proposed openstack/keystone-specs master: Fix html_last_updated_fmt for Python3 https://review.openstack.org/472591 | 08:54 |
| *** spzala has joined #openstack-keystone | 09:00 | |
| *** spzala has quit IRC | 09:05 | |
| *** markvoelker has joined #openstack-keystone | 09:13 | |
| *** thorst_afk has joined #openstack-keystone | 09:20 | |
| *** jpena has joined #openstack-keystone | 09:24 | |
| *** thorst_afk has quit IRC | 09:24 | |
| jpena | hi, are there any plans for a new python-keystoneclient release anytime soon? | 09:24 |
| *** spzala has joined #openstack-keystone | 09:27 | |
| *** Shunli has quit IRC | 09:31 | |
| *** spzala has quit IRC | 09:32 | |
| openstackgerrit | Pallavi proposed openstack/ldappool master: Fix html_last_updated_fmt for Python3. https://review.openstack.org/472604 | 09:36 |
| *** markvoelker has quit IRC | 09:42 | |
| openstackgerrit | Merged openstack/ldappool master: Fix html_last_updated_fmt for Python3. https://review.openstack.org/472604 | 09:45 |
| *** links has quit IRC | 09:51 | |
| *** liujiong has quit IRC | 09:52 | |
| *** zhurong has joined #openstack-keystone | 09:55 | |
| *** spzala has joined #openstack-keystone | 09:59 | |
| *** namnh has joined #openstack-keystone | 10:03 | |
| *** links has joined #openstack-keystone | 10:03 | |
| *** spzala has quit IRC | 10:04 | |
| openstackgerrit | Lingyong Xu proposed openstack/keystonemiddleware master: Fix html_last_updated_fmt for Python3 https://review.openstack.org/472619 | 10:04 |
| *** zhurong has quit IRC | 10:06 | |
| *** edmondsw has joined #openstack-keystone | 10:19 | |
| *** piliman974 has joined #openstack-keystone | 10:21 | |
| *** edmondsw has quit IRC | 10:24 | |
| *** spzala has joined #openstack-keystone | 10:27 | |
| *** spzala has quit IRC | 10:32 | |
| *** markvoelker has joined #openstack-keystone | 10:39 | |
| *** nicolasbock has joined #openstack-keystone | 10:45 | |
| *** spzala has joined #openstack-keystone | 10:58 | |
| *** spzala has quit IRC | 11:02 | |
| *** markvoelker has quit IRC | 11:13 | |
| *** ducttape_ has joined #openstack-keystone | 11:18 | |
| *** ducttape_ has quit IRC | 11:23 | |
| *** spzala has joined #openstack-keystone | 11:29 | |
| *** nishaYadav has joined #openstack-keystone | 11:32 | |
| *** spzala has quit IRC | 11:34 | |
| *** edmondsw has joined #openstack-keystone | 11:42 | |
| *** raildo has joined #openstack-keystone | 11:49 | |
| *** xuhaigang has quit IRC | 11:50 | |
| *** aojea has quit IRC | 11:53 | |
| *** namnh has quit IRC | 11:55 | |
| *** thorst_afk has joined #openstack-keystone | 11:59 | |
| *** spzala has joined #openstack-keystone | 12:00 | |
| *** ducttape_ has joined #openstack-keystone | 12:02 | |
| *** spzala has quit IRC | 12:04 | |
| *** ducttape_ has quit IRC | 12:07 | |
| *** xuhaigang has joined #openstack-keystone | 12:07 | |
| *** markvoelker has joined #openstack-keystone | 12:10 | |
| *** ducttape_ has joined #openstack-keystone | 12:21 | |
| *** ducttap__ has joined #openstack-keystone | 12:22 | |
| *** ducttap__ has quit IRC | 12:22 | |
| *** ducttape_ has quit IRC | 12:25 | |
| *** spzala has joined #openstack-keystone | 12:28 | |
| *** jpena is now known as jpena|lunch | 12:28 | |
| *** spzala has quit IRC | 12:33 | |
| *** markvoelker has quit IRC | 12:36 | |
| *** markvoelker has joined #openstack-keystone | 12:36 | |
| *** jaosorior has quit IRC | 12:37 | |
| *** shuying__ has quit IRC | 12:38 | |
| *** catintheroof has joined #openstack-keystone | 12:40 | |
| *** dave-mccowan has joined #openstack-keystone | 12:43 | |
| *** catintheroof has quit IRC | 12:45 | |
| *** catintheroof has joined #openstack-keystone | 12:46 | |
| *** ducttape_ has joined #openstack-keystone | 12:48 | |
| *** links has quit IRC | 12:48 | |
| *** ducttape_ has quit IRC | 12:53 | |
| *** aojea has joined #openstack-keystone | 12:54 | |
| *** aojea has quit IRC | 12:59 | |
| *** spzala has joined #openstack-keystone | 12:59 | |
| mordred | morgan, cmurphy: I'm fine with any of it- I agree, at the very least it does not need to be in these patches | 13:02 |
| *** lucasxu has joined #openstack-keystone | 13:03 | |
| *** spzala has quit IRC | 13:03 | |
| cmurphy | o7 | 13:03 |
| *** ducttape_ has joined #openstack-keystone | 13:05 | |
| *** shuyingy_ has joined #openstack-keystone | 13:11 | |
| *** ducttape_ has quit IRC | 13:12 | |
| *** shuyingy_ has quit IRC | 13:15 | |
| *** lucasxu has quit IRC | 13:16 | |
| *** ducttape_ has joined #openstack-keystone | 13:16 | |
| *** ducttape_ has quit IRC | 13:16 | |
| *** ducttape_ has joined #openstack-keystone | 13:17 | |
| *** ducttape_ has quit IRC | 13:21 | |
| *** aojea has joined #openstack-keystone | 13:22 | |
| *** aojea has quit IRC | 13:26 | |
| *** spzala has joined #openstack-keystone | 13:29 | |
| *** spzala has quit IRC | 13:31 | |
| *** spzala has joined #openstack-keystone | 13:31 | |
| *** aojea has joined #openstack-keystone | 13:33 | |
| openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Rework EndpointData construction to normalize catalog first https://review.openstack.org/469085 | 13:36 |
| mordred | morgan, cmurphy: k. that's rebased on morgan's patch to remove self, then fixed the review comments | 13:36 |
| mordred | I'm thinking maybe not rebase the whole stack while we iterate on those two | 13:37 |
| *** jpena|lunch is now known as jpena | 13:38 | |
| *** spilla has joined #openstack-keystone | 13:41 | |
| *** chlong has joined #openstack-keystone | 13:51 | |
| *** jaosorior has joined #openstack-keystone | 13:56 | |
| mordred | morgan: or - maybe since I'm rebasing low in the stack I just squash the two so we can shift the larger discusion | 13:58 |
| *** pnavarro has joined #openstack-keystone | 13:59 | |
| *** nicolasbock has quit IRC | 14:03 | |
| *** lucasxu has joined #openstack-keystone | 14:09 | |
| *** lucasxu has quit IRC | 14:14 | |
| *** lucasxu has joined #openstack-keystone | 14:14 | |
| *** lucasxu has quit IRC | 14:16 | |
| *** tesseract has quit IRC | 14:16 | |
| *** aselius_ has joined #openstack-keystone | 14:19 | |
| lbragstad | jpena: i just reviewed the same release for python-keystoneclient you reviewed | 14:20 |
| *** lucasxu has joined #openstack-keystone | 14:20 | |
| *** tesseract has joined #openstack-keystone | 14:23 | |
| *** lucasxu has quit IRC | 14:23 | |
| *** dikonoor has quit IRC | 14:28 | |
| *** phalmos has joined #openstack-keystone | 14:29 | |
| *** dikonoor has joined #openstack-keystone | 14:30 | |
| *** tobberydberg has quit IRC | 14:30 | |
| *** tobberydberg has joined #openstack-keystone | 14:33 | |
| *** tobberydberg has quit IRC | 14:39 | |
| *** Dinesh_Bhor has quit IRC | 14:44 | |
| *** ducttape_ has joined #openstack-keystone | 14:44 | |
| *** ducttape_ has quit IRC | 14:46 | |
| *** ducttape_ has joined #openstack-keystone | 14:46 | |
| *** jpena is now known as jpena|off | 14:56 | |
| morgan | mordred: makes sense to me | 14:56 |
| -openstackstatus- NOTICE: The Gerrit service on review.openstack.org is being restarted now to clear an issue arising from an unanticipated SSH API connection flood | 14:56 | |
| *** jpena|off is now known as jpena | 14:58 | |
| *** rcernin has quit IRC | 15:08 | |
| *** jaosorior has quit IRC | 15:09 | |
| *** rderose has joined #openstack-keystone | 15:18 | |
| *** aselius_ has quit IRC | 15:26 | |
| *** aselius has joined #openstack-keystone | 15:26 | |
| *** tobberydberg has joined #openstack-keystone | 15:31 | |
| *** tobberydberg has quit IRC | 15:36 | |
| openstackgerrit | Nicolas Helgeson proposed openstack/keystone master: Added versions to keyston headers https://review.openstack.org/468189 | 15:36 |
| nishaYadav | hey! | 15:38 |
| nishaYadav | anyone around? I was wondering what's the official logo of keystone | 15:38 |
| lbragstad | nishaYadav: o/ | 15:39 |
| nishaYadav | lbragstad, hey! | 15:39 |
| lbragstad | nishaYadav: you can find the mascots here - https://www.openstack.org/project-mascots/ | 15:40 |
| openstackgerrit | Colleen Murphy proposed openstack/keystone-specs master: Application Credentials for application authn https://review.openstack.org/450415 | 15:41 |
| cmurphy | lbragstad: rderose ^ | 15:41 |
| rderose | cmurphy: ++ | 15:41 |
| nishaYadav | lbragstad, thanks, I was guessing the turle but wasn't sure. The link will help me for other projects too :) | 15:41 |
| lbragstad | rderose: \o/ | 15:44 |
| lbragstad | cmurphy: is there any reason to not just include those attributes when we need them in a subsequent release or implementation? | 15:45 |
| lbragstad | it would be an additive feature/change, so it shouldn't be backwards incompatible in anyway | 15:45 |
| cmurphy | lbragstad: my reasoning was that since they're not fleshed out yet, if we decide to change them at all it's harder to change after we've committed to the API, whereas adding new parameters is easier | 15:45 |
| lbragstad | i know i tripped on those definitions until i saw the disclaimer in the last sentence | 15:46 |
| rderose | lbragstad: :) | 15:47 |
| cmurphy | lbragstad: hmm so what's your suggestion? it wouldn't be additive if we've implemented enough of it to produce an error on a non-empty list | 15:51 |
| *** aojea has quit IRC | 15:51 | |
| lbragstad | cmurphy: oh - my suggestion was completely remove it from the first iteration | 15:51 |
| lbragstad | and then add those attributes when we need them | 15:52 |
| lbragstad | making it a completely additive change | 15:52 |
| lbragstad | right? | 15:52 |
| cmurphy | lbragstad: that makes sense to me | 15:52 |
| lbragstad | cmurphy: otherwise - i do share your concern | 15:52 |
| *** gyee has joined #openstack-keystone | 15:53 | |
| lbragstad | it's kinda tough to define the attributes, but not use them and keep them open for implementation "at some point in the future" | 15:53 |
| cmurphy | lbragstad: what if we just add "In the next iteration, we will add parameters that will look something like this:" | 15:53 |
| cmurphy | mordred: ^ | 15:53 |
| lbragstad | cmurphy: yes - we could even have a short section in there specification for that | 15:53 |
| lbragstad | like - "at the time of this writing, we find these attributes useful for these reasons, but we're not going to implement them in the first pass" | 15:54 |
| cmurphy | ++ | 15:54 |
| *** dikonoor has quit IRC | 15:57 | |
| lbragstad | cmurphy: updated with a comment | 15:59 |
| cmurphy | lbragstad: ty | 15:59 |
| *** jpena is now known as jpena|away | 16:01 | |
| *** r-daneel has joined #openstack-keystone | 16:01 | |
| cmurphy | hmm I'm noticing we have "Assigned the current role the creating User has on a Project, optionally accepting a list of roles that is a subset of the creating User's roles in that project." but we don't have a parameter for roles yet | 16:01 |
| cmurphy | that part is something that we'd want to do on the first round | 16:01 |
| *** f13o has joined #openstack-keystone | 16:05 | |
| f13o | Where can I read more on how Heat is treated from the PoV of other service policy.json? for example nova or neutron | 16:07 |
| f13o | If a cloud user can use heat api, how should I setup my neutron's policy.json so that my cloud user cannot add more private neutron networks (for example)? | 16:09 |
| f13o | (via heat api and using neutron api) | 16:09 |
| openstackgerrit | Colleen Murphy proposed openstack/keystone-specs master: Application Credentials for application authn https://review.openstack.org/450415 | 16:19 |
| cmurphy | lbragstad: rderose ^ | 16:19 |
| rderose | cmurphy: ++ | 16:20 |
| *** dikonoor has joined #openstack-keystone | 16:21 | |
| mordred | cmurphy, lbragstad: maybe lets add a description of an endpoint that can be queried now that exposes if limiting exists | 16:25 |
| mordred | so that a user can discover whether their cloud supports the next thing or not | 16:25 |
| mordred | since we _know_ it's a thing that we want in th efuture, but we don't know yet what it looks like, so we know there will be clouds that have credentials but not limits to them, and also clouds that will have both | 16:26 |
| mordred | I mean, it opens a slight can of worms because it would be the beginning of a "capabilities" endpoint - but that would be great anyway :) | 16:27 |
| *** tesseract has quit IRC | 16:32 | |
| *** pcaruana has quit IRC | 16:34 | |
| lbragstad | mordred: an endpoint for limiting? | 16:39 |
| lbragstad | for application credentials? | 16:39 |
| cmurphy | limiting == permission restricting ya ? | 16:40 |
| cmurphy | mordred: can you propose that? | 16:40 |
| lbragstad | i'm not sure i understand why we'd need a separate endpoint for limiting | 16:40 |
| *** piliman974 has quit IRC | 16:40 | |
| lbragstad | the attributes would either be in the application credential or not, right? | 16:40 |
| * lbragstad might be by himself in left field | 16:41 | |
| *** piliman974 has joined #openstack-keystone | 16:43 | |
| *** f13o has quit IRC | 16:44 | |
| *** rcernin has joined #openstack-keystone | 16:45 | |
| cmurphy | mordred is just on a version discovery rampage | 16:49 |
| *** f13o has joined #openstack-keystone | 17:00 | |
| cmurphy | lbragstad: rderose mordred I'm afk for ~45 minutes, please update the spec if you reach a consensus | 17:02 |
| lbragstad | cmurphy: ack | 17:03 |
| mordred | cmurphy: I can propose that - I can also do it as a separate thing real quick - Idon't think we should block the spec on that | 17:07 |
| mordred | lbragstad: I mostly want to push back on adding functionality with no way for a user to know if the functionality is supported as much as I can | 17:08 |
| samueldmq | hey ya | 17:08 |
| lbragstad | mordred: so you do want the unused attributes `api_access_list` and `api_access` included in the first iteration? | 17:09 |
| mordred | lbragstad: I don't think we need them there if we can *hand wave* agree to put something somewhere that will let a user know whether or not they can send them | 17:09 |
| lbragstad | mordred: oh - sure, i would be in favor of completely removing those attributes from the application credential object for the first iteration, and then we can document our thinking and why it would be a good thing to add in the future | 17:10 |
| mordred | lbragstad: ++ | 17:10 |
| lbragstad | mordred: i think that would address the concern that I had a few patch sets ago as well as rderose's | 17:11 |
| mordred | cool. cmurphy is afk so I'll do that rev right now | 17:11 |
| lbragstad | mordred: awesome | 17:11 |
| *** aojea has joined #openstack-keystone | 17:15 | |
| *** aojea has quit IRC | 17:19 | |
| mordred | lbragstad, cmurphy: in the spec, we have roles in a coupe of places and role_ids in a couple of places | 17:21 |
| mordred | lbragstad: which do you think we should use? | 17:21 |
| mordred | lbragstad: maybe roles - but have the requests accept name or id and the responses always return id? | 17:22 |
| lbragstad | mordred: morgan had a good point about role names | 17:22 |
| mordred | oh - he did? crap, I missed it | 17:22 |
| * mordred goes back to look | 17:22 | |
| lbragstad | mordred: yeah - cmurphy addressed the comment i think | 17:22 |
| *** jpena|away is now known as jpena | 17:22 | |
| mordred | ah- his point was just use names, yeah? | 17:22 |
| morgan | yep | 17:22 |
| mordred | cool | 17:22 |
| lbragstad | https://review.openstack.org/#/c/450415/15/specs/keystone/pike/application-credentials.rst@228 | 17:22 |
| morgan | since names are used *everywhere* | 17:22 |
| morgan | :) | 17:22 |
| mordred | there's still a coupe of role_id places - I'll fix them in this rev | 17:23 |
| *** jpena is now known as jpena|off | 17:23 | |
| ayoung | cmurphy, how about like this: | 17:35 |
| openstackgerrit | Monty Taylor proposed openstack/keystone-specs master: Application Credentials for application authn https://review.openstack.org/450415 | 17:35 |
| mordred | cmurphy, morgan, lbragstad, rderose: updated | 17:36 |
| ayoung | an application credential is always scoped to a project, and will include a subset of the roles assigned to the user for that project | 17:36 |
| morgan | thnx | 17:36 |
| ayoung | and we have an update...reading | 17:36 |
| ayoung | LGTM morgan | 17:37 |
| openstackgerrit | Nicolas Helgeson proposed openstack/keystone master: Added versions to keyston headers https://review.openstack.org/468189 | 17:37 |
| mordred | woot! | 17:37 |
| ayoung | morgan, quick question, would it be ok to implicitly create a trust when creating an application credential, and then have that show up in the list of trusts? | 17:38 |
| morgan | ayoung: uhm. maybe? | 17:38 |
| morgan | you should ask mordred though | 17:38 |
| ayoung | its an implementation detail. but should speed the implementation | 17:38 |
| morgan | it's his spec ;) | 17:38 |
| ayoung | morgan, think he's pragmatic enough to say "sure" | 17:38 |
| ayoung | morgan, are you working on an impl? | 17:39 |
| ayoung | er | 17:39 |
| morgan | nope | 17:39 |
| morgan | i am not | 17:39 |
| ayoung | mordred, are you working on an impl | 17:39 |
| morgan | hehe | 17:39 |
| ayoung | morgan, its your fault for having the same 3 letter prefix to your nick | 17:39 |
| mordred | ayoung: I don't think that's problematic at all | 17:40 |
| ayoung | cmurphy, regarding your question: | 17:40 |
| morgan | mordred: i do have one other question (impl detail), when a user creates a app cred, it is deleteable by any other user with write on the project... this seems oddly asymmetrical from an authn stance where a writer might want to create an action for a user they aren't. | 17:40 |
| morgan | you must be user X to make an app cred for user X | 17:41 |
| mordred | ayoung: although, since a trust is a delegation of a user's credentials, would the trust associated with a application credential imply an incorrect thing to a person looking at them? | 17:41 |
| morgan | but any user in W group can delete user X's app cred | 17:41 |
| mordred | especially if/when roles on a user change or the user is deleted? (I'm fine with that if it does, just asking) | 17:41 |
| ayoung | mordred, so a trust goes from one user (trustor) to another (trustee). In this case, a trustee would be the application, not a human | 17:41 |
| lbragstad | i don't think a user can specify the user id for an app cred, i think it's populated from the request | 17:41 |
| * morgan would have assumed it would be a separate permission/policy hook point (regardless of the default being any-writer) | 17:41 | |
| morgan | for delete-not-my-app-cred | 17:41 |
| morgan | something like is_owner or project_admin | 17:42 |
| morgan | or w/e | 17:42 |
| ayoung | we'd have to fudge a little on the application to make it a user, but we could fake that out by putting it in a hidden domain, much like we proposed doing with consumers for oauth | 17:42 |
| cmurphy | mordred: re roles vs role_ids i was trying to address morgan's comments and might have missed some spots | 17:42 |
| mordred | morgan: that's a good point - do you think we should include user_id in the request? | 17:42 |
| morgan | cmurphy: you did good. | 17:42 |
| mordred | ayoung: kk - yah- I think we can totally do that | 17:42 |
| morgan | mordred: i almost think we should | 17:42 |
| mordred | morgan: lemme take a quick stab at that | 17:43 |
| morgan | mordred: this comment and thought was not meant to de-rail the spec though | 17:43 |
| ayoung | mordred, if I create an app-credential, and then my user gets deleted, what should happen to the app cred? | 17:43 |
| morgan | mordred: if it's painful... we can punt that | 17:43 |
| morgan | ayoung: deleted | 17:43 |
| mordred | morgan: I'll do it as a follow up patch so we can discuss it separately | 17:43 |
| morgan | mordred: ++ | 17:43 |
| lbragstad | ayoung: it stays around from what i can tell | 17:43 |
| mordred | ayoung, morgan : no- it stays around | 17:43 |
| morgan | can it be used to auth still? | 17:43 |
| mordred | the app credential is only associated wiht a user at th emoment of creation, after that its lifecycle is independent | 17:43 |
| morgan | uhm | 17:44 |
| lbragstad | the reason was because that behavior it the same as using a regular user | 17:44 |
| morgan | uhhhh | 17:44 |
| mordred | this is one of the primary use cases | 17:44 |
| * lbragstad gets popcorn | 17:44 | |
| morgan | ok, i need to re-review the spec with a totally different mindset | 17:44 |
| morgan | this is going to cause a ton of weirdness and issues in audit trails, etc | 17:44 |
| mordred | so - it was also suggested that DELETE /user get a flag "delete all credentials for this user" | 17:44 |
| morgan | unless you're creating an implicit user | 17:44 |
| morgan | that is part of the app-cred | 17:45 |
| *** aojea has joined #openstack-keystone | 17:45 | |
| morgan | i always read the proposal as the same thing as google application-specific-passwords are | 17:45 |
| ayoung | mordred, so, how are app creds managed? | 17:45 |
| mordred | morgan: that's been my assumption - that we'd be creating an implicit lightweight user - but I could be wrong about htat from an impl perspective | 17:45 |
| ayoung | mordred, implicit light weight user is ok, But if you use trusts, you have a better admin setup | 17:45 |
| morgan | user has an alternative mechanism for authing for a specific app (like thunderbird, if it isn't 2fa aware) | 17:45 |
| morgan | if the user is deleted, the app-password no longer works, the user is dead. | 17:46 |
| ayoung | that lightweigh user can only do the things that I can do, if I create the app cred | 17:46 |
| mordred | yah. that's a thing people want to avoid | 17:46 |
| ayoung | otherwise, much wierdness ensues | 17:46 |
| mordred | because it's a nighmare for teasm | 17:46 |
| cmurphy | one of the main use cases was keeping automation running even if the creator gets fired | 17:46 |
| mordred | teams | 17:46 |
| mordred | yup | 17:46 |
| morgan | !! | 17:46 |
| ayoung | If you as an admin take away a role from me, but I have app creds (where I | 17:46 |
| openstack | morgan: Error: "!" is not a valid command. | 17:46 |
| ayoung | I've kep the passwrod cuz I'm sneaky) I still ahve that elelvated priv | 17:46 |
| morgan | yeah that is bad news | 17:47 |
| ayoung | morgan, now go and read the "unified dlegation" spec and much will be come clear | 17:47 |
| * ayoung misses amakarov | 17:47 | |
| morgan | ayoung: i've already read it a ton. | 17:47 |
| ayoung | yeah but once again I mean mordred | 17:47 |
| morgan | lol | 17:47 |
| mordred | morgan: maybe instead what we should do is make DELETE /user delete creds by default, but add a flag which is "do not delete app creds" | 17:48 |
| mordred | so that people for whom the ability is important can do so, but htey have to opt-in | 17:48 |
| morgan | mordred: i have to spend some time on this part of it | 17:48 |
| ayoung | So, there are two basic implementations, and I think we shouild explicitly allow both: | 17:49 |
| lbragstad | what should happen is at user deletion a prompt comes up and requires the app credential to be owned by someone else | 17:49 |
| ayoung | 1. a user can make an app-cred and that uses a trust | 17:49 |
| ayoung | user goes away, app cred is useless | 17:49 |
| ayoung | 2. an admin-type user can make an app-cred and that uses a role assignment | 17:49 |
| ayoung | admin user goes away, app-cred is still good | 17:49 |
| mordred | no. that's not good enough | 17:49 |
| ayoung | make it a flag | 17:50 |
| mordred | if you only allow a admin to do 2, the feature is broken | 17:50 |
| mordred | 2 is an essential end-user feature | 17:50 |
| ayoung | mordred, "admin" just means "someone with a higher role than Member" | 17:50 |
| mordred | right | 17:50 |
| mordred | 2 is an essential Member feature | 17:50 |
| ayoung | mordred, and this is why I want to fix RBAC | 17:50 |
| ayoung | you can't do any of this without decent RBAC | 17:50 |
| * ayoung goes off to privatly sob for a moment | 17:51 | |
| mordred | you can totally do all of this right now as described in the spec | 17:51 |
| mordred | and it's FINE for people | 17:51 |
| * ayoung comes back with eyes puffy and face strangely clean | 17:51 | |
| mordred | we can make user deletion delete app creds by default | 17:51 |
| mordred | as long as there is an escape valve for that some how | 17:51 |
| mordred | because otherwise this has the same limitations as oauth that make ops teams using oauth web-services cry | 17:52 |
| *** ducttape_ has quit IRC | 17:52 | |
| ayoung | mordred, make it a flag on the app-cred, and we can debate the implementation | 17:52 |
| mordred | ++ | 17:52 |
| mordred | I was just thinking the same thing | 17:52 |
| ayoung | I'm OK with both 1 and 2 being supported | 17:52 |
| morgan | ayoung: yes. that works. | 17:52 |
| mordred | "this is an app-cred that needs to persist" | 17:52 |
| morgan | i want to be very careful about app-creds that continue after a user that created it disappears | 17:53 |
| mordred | and then we could combine that with lbragstad's idea above ... | 17:53 |
| lbragstad | so - it's a flag that either tightly couples the user to the app cred or not | 17:53 |
| ayoung | just some way of making it a special thing to ask for persistant ones. And that is what needs decent RBAC. Because otherwise whayt you are going to have is deployments where ONLY admins can do ANY app cred | 17:53 |
| morgan | admin-specific/explicitly flagged is fine | 17:53 |
| mordred | if an admin goes to delete a user that has a persistent app cred associated | 17:53 |
| ayoung | lbragstad, ++ | 17:53 |
| morgan | ayoung: ++ | 17:53 |
| mordred | the admin either has to force-remove or provide a new user owner | 17:53 |
| ayoung | mordred, nah | 17:53 |
| morgan | mordred: i would go as far as to make a special user for persistent ones and that user cannot be deleted w/o clearing app-creds | 17:53 |
| cmurphy | as soon as the user creates it, they're going to put the id and secret in some config file and it will be known by the whole project team | 17:53 |
| morgan | ayoung: ^ | 17:54 |
| ayoung | mordred, if the app cred is persistant, it lasts beyond the user that created it | 17:54 |
| lbragstad | i don't think it makes sense to just have app creds floating around | 17:54 |
| mordred | morgan: but if we do that- it's the same security hole you're concerned about | 17:54 |
| morgan | i would want to decouple persistent ones from any specific user. | 17:54 |
| lbragstad | process tells me that if a user leaves or is deletes, their app creds should get new ownership | 17:54 |
| ayoung | we can swtich on policy who is allowed to make an persistant app cred, so it is a deployers decision | 17:54 |
| lbragstad | is deleted* | 17:54 |
| morgan | ayoung: that is fair. | 17:54 |
| mordred | nonononon | 17:54 |
| mordred | nononononno | 17:54 |
| morgan | mordred: it should be policy to allow/disallow creation of persistent creds (even if that is admin) | 17:55 |
| mordred | no | 17:55 |
| ayoung | implementation wise, I would always make an app-cred a light weight users. the app-cred record would indicate whether it should be a trust or a role assignemt to map to user-based vs persistent | 17:55 |
| morgan | ayoung: ok that is fine. | 17:55 |
| morgan | ayoung: impl detail aside. concepts lets work on that | 17:55 |
| morgan | mordred: so. there HAS to be a way to prevent normal users from creating a persistent app-cred that persists beyond their user account | 17:56 |
| ayoung | mordred, in general, a user should not be able to provide an end-run to getting canned from their job | 17:56 |
| mordred | morgan: I strongly disagree. there needs to be a way for an admin to delete persistent app creds when they delete a user | 17:56 |
| ayoung | ah | 17:56 |
| mordred | that's the important bit | 17:56 |
| morgan | if i have vexxhost account, and i create an app-cred, they delete my user, they shouldn't need to worry if any creds continue to exist | 17:56 |
| ayoung | mordred, I think that can be done by providing "list-app-cred-for user | xargs delete app-cred" type behavior | 17:56 |
| mordred | well, in that case, they'll be deleting your project | 17:56 |
| mordred | ayoung: YES | 17:57 |
| morgan | not nessicarily | 17:57 |
| morgan | what if i'm a subuser not the owner. | 17:57 |
| ayoung | might need to know the user-id though | 17:57 |
| ayoung | if we delete the user record, might not be a way to look up by id | 17:57 |
| morgan | and the subuser is deleted. | 17:57 |
| morgan | as an account owner i don't want to guess/have to chase this down | 17:57 |
| mordred | morgan: but yes - what if the default behavior of user deletion imploies list-app-cred-for user | xargs delete app-cred | 17:57 |
| mordred | so delete does what you expect | 17:57 |
| mordred | and there is no worries | 17:58 |
| ayoung | those would be the non-persistnat ones, mordred | 17:58 |
| mordred | but - you can optionally delete a user and _not_ delete its app creds | 17:58 |
| morgan | so you're saying add new flags/capabilities to delete-user? | 17:58 |
| lbragstad | but the valve you talked about allows the opposite for a privileged individual | 17:58 |
| mordred | morgan: yes | 17:58 |
| ayoung | hmmm | 17:58 |
| morgan | ugh. | 17:58 |
| morgan | i really would rather make app-creds that persist explicitly opt-in for that cred | 17:58 |
| ayoung | yeah... | 17:58 |
| mordred | sure. I'm fine with that bit | 17:58 |
| morgan | and something that can be controlled. | 17:58 |
| cmurphy | once the app cred is created it will get used in automation and the cat is out of the bag, it doesn't matter who created it or what happens to them | 17:59 |
| mordred | but not that bit | 17:59 |
| lbragstad | what happens when we're dealing with application creds for a federated user? | 17:59 |
| mordred | I dont' want to implement a feature that nobody will be able to actually use because it'll get disabled/turned-off | 17:59 |
| ayoung | would be nice to be able to re-enable an app cred or "persitify" one that is user-linked | 17:59 |
| morgan | mordred: i have to -1 this spec at this point based upon this, and near a -2 (not yet) | 17:59 |
| ayoung | Dufenshmirtz: I call this my Persistenator! | 17:59 |
| morgan | i'm sorry, this is treading on scary grounds. | 17:59 |
| mordred | morgan: that's fine - I think we can figure it out - we seem to all at least understand the use case now :) | 18:00 |
| ayoung | yeah, removing my +2 | 18:00 |
| morgan | i'm almost inclined to say no persistent app-creds that live beyond a user | 18:00 |
| morgan | so if you need one, get a user and allow admins to create creds attached to another user | 18:00 |
| lbragstad | ok - so maybe we need to back up a bit | 18:00 |
| morgan | s/admin/project admin/ | 18:00 |
| morgan | the base concept of app-cred is good | 18:00 |
| morgan | lets start there | 18:01 |
| morgan | really. the sticking point is persistence beyond user lifecycl | 18:01 |
| morgan | e | 18:01 |
| lbragstad | not thinking about app credentials any more, how would we ideally solve the issue of a user setting up a bunch of stuff in a project, leaving, and having that stuff still work? | 18:01 |
| ayoung | default for an app cred is a delegation from a user. | 18:01 |
| mordred | ugh | 18:01 |
| * mordred now goes off to cry in the corner | 18:01 | |
| morgan | lbragstad: you don't want that. | 18:01 |
| ayoung | upgraded app cred is an explicit role assignment | 18:01 |
| morgan | you REALY don't want that | 18:01 |
| morgan | as a default general thing | 18:02 |
| lbragstad | morgan: that's the question that burned a forum session in boston :) | 18:02 |
| morgan | you want the ability to specifically allow it in *some* cases | 18:02 |
| ayoung | lbragstad, they should create a service user, assign roles to that service user and then go away | 18:02 |
| ayoung | and... | 18:02 |
| ayoung | if you are worried about that service user having too much power located in one place | 18:02 |
| lbragstad | but - that doesn't get us away from having to put passwords in configuration files | 18:02 |
| morgan | neither really does this | 18:03 |
| ayoung | then that sercvice user creates a bunch of these trust-like app-creds | 18:03 |
| morgan | this *is* a password | 18:03 |
| cmurphy | this is better because these can be rotated, passwords can't | 18:03 |
| lbragstad | it is - but the case made was that it doesn't expose password conventions for other service users in the deployment | 18:03 |
| mordred | morgan: ok. I can live with starting at a point where persistent creds are an opt-in/must-be-enabled feature | 18:03 |
| lbragstad | cmurphy: that too | 18:03 |
| mordred | because the cred rotation and being able to make these outside of what your federated backend ar eht emost importnat things | 18:03 |
| morgan | mordred: so, lets start with no persistence beyond user lifecycle. i like everything about app-creds besides that | 18:04 |
| ayoung | mordred, the ability to have an entity with permissions beyond the lifespan of the origianl user is the ability to create a user. No matter what we call it. | 18:04 |
| morgan | rotation, etc are solid | 18:04 |
| morgan | we can look at persistence after and how to address it securely | 18:04 |
| ayoung | And that user can either have role assignemnets, which persist, or get roles via a trust | 18:04 |
| morgan | adding capabilities to an API is easy. | 18:04 |
| morgan | removing is ... lets just say not doable | 18:04 |
| mordred | morgan: awesome. I'll rev real quick | 18:04 |
| morgan | perfect | 18:04 |
| mordred | morgan: I'm going to leave a future-looking note about the use-case desire | 18:05 |
| morgan | perfect | 18:05 |
| mordred | similar to the one about api exclusions | 18:05 |
| lbragstad | ++ | 18:05 |
| morgan | cool. | 18:05 |
| cmurphy | yay | 18:05 |
| morgan | and if needed we can implement something that clearly bundles in the app-creds to a common place or whatever within a project if it needs to persist | 18:05 |
| mordred | morgan: should we also add "explicit user_id at creation time"? | 18:05 |
| morgan | mordred: i personally like that | 18:06 |
| mordred | (optional) | 18:06 |
| mordred | cool - will do | 18:06 |
| morgan | but i wont make it a sticking point either way | 18:06 |
| lbragstad | doesn't that come from the request? | 18:06 |
| morgan | lbragstad: he's offering a "hey i am admin X and want to create this for user Y" | 18:06 |
| lbragstad | why would you want to specify that, i feel like that should come from the token being used to create the application cred | 18:06 |
| lbragstad | oh | 18:06 |
| lbragstad | it that going to be isolated as an admin only thing? | 18:07 |
| morgan | that should be | 18:07 |
| lbragstad | ok - that seems like the right thing to do if we end up supporting that | 18:07 |
| morgan | it could (in theory) solve the issue of long-lived creds, service user-wise. | 18:07 |
| morgan | but it should be tightly controlled. | 18:08 |
| morgan | if it is not specified it comes from the request (default behavior) | 18:09 |
| lbragstad | yeah - only an admin should be able to specify a user id | 18:09 |
| lbragstad | and if an admin isn't making that request it should come from the token used to create the app cred | 18:09 |
| morgan | anyway. i think we unblocked the spec. | 18:09 |
| lbragstad | so - | 18:09 |
| lbragstad | to recap | 18:09 |
| morgan | we narrowed the scope a little, but in the name of security | 18:10 |
| lbragstad | we not including api access lists | 18:10 |
| morgan | ++ that is dependant on future code | 18:10 |
| lbragstad | and we not making it so app creds can outlive the user that created them | 18:10 |
| morgan | correct | 18:10 |
| morgan | that discussion will come as a followup once the base feature is implemented | 18:11 |
| lbragstad | so - the current proposal will still provide better rotation of passwords | 18:11 |
| morgan | "can we do it securely, and how do we do that" | 18:11 |
| lbragstad | and no password conventions in configuration files | 18:11 |
| morgan | no standard user-password | 18:11 |
| lbragstad | yep | 18:11 |
| morgan | correct. | 18:11 |
| lbragstad | cmurphy: ayoung mordred how do you all feel about it? | 18:12 |
| * mordred reads | 18:12 | |
| ayoung | feel about what? | 18:12 |
| lbragstad | the summary I just posted & | 18:12 |
| lbragstad | ^ | 18:12 |
| ayoung | heh | 18:12 |
| ayoung | just processing... | 18:12 |
| lbragstad | loading... loading... loading | 18:13 |
| mordred | yah. wfm | 18:13 |
| morgan | mordred: sorry to throw a monkey wrench in it. but some things are big flags. | 18:13 |
| ayoung | lbragstad, what do you mean by " if an admin isn't making that request it should come from the token used to create the app cred" I assume you mean that it is tied to the lifespan of the user that requested it | 18:14 |
| morgan | ayoung: mordred is looking to add a "if admin, can make an app cred on the behalf of another user" | 18:14 |
| lbragstad | yeah - i don't want another user that isn't an admin creating app creds tied to my user account | 18:14 |
| lbragstad | that seems like a privileged case that should be available to everyone | 18:15 |
| lbragstad | shouldn't* | 18:15 |
| morgan | ayoung: if !admin or !not_user_id_in_request, it pulls from the token | 18:15 |
| morgan | (the requesting user) | 18:15 |
| lbragstad | morgan: more like if !admin and user not in request, pull from the token | 18:15 |
| ayoung | ok...so you guys are giving me PTSD to the trust discussion | 18:15 |
| morgan | lol | 18:15 |
| lbragstad | wait... | 18:16 |
| ayoung | so back to what I said before: | 18:16 |
| lbragstad | wouldn't that be a separate api call/policy check based on the things in the payload of the request? | 18:16 |
| ayoung | an app cred is a light weight user | 18:16 |
| morgan | sure we could. | 18:16 |
| morgan | mordred: hey, cna we drop the user_id specification too | 18:16 |
| morgan | before you push the rev | 18:17 |
| morgan | lets circle up on that later as well | 18:17 |
| morgan | just to avoid wedging the spec | 18:17 |
| ayoung | we provide a flage which will be used to determine if that app cred is persistant (maps to a role assignemdn) or tied to a user (maps to a trust) | 18:17 |
| morgan | ^ ayoung, lbragstad | 18:17 |
| morgan | again, adding to an API is easy. | 18:17 |
| morgan | so to begin with, it should always be the requesting user | 18:17 |
| ayoung | an admin creating an app cred tied to a user other than himself is like an admin creating a trust for another user. | 18:18 |
| morgan | we will explore specifying a different user and/or persisting beyond user lifecycle after the base functionality is done. | 18:18 |
| morgan | lets just nix that for now and discuss specifics independently | 18:18 |
| morgan | ayoung: ^ | 18:18 |
| ayoung | not something I particularly like, but we see Heat do that all the time. Just, Heat uses the token that the user gave to Heat to create the trust | 18:18 |
| morgan | i don't wnat to wedge this over a detail like that right now | 18:18 |
| openstackgerrit | Monty Taylor proposed openstack/keystone-specs master: Application Credentials for application authn https://review.openstack.org/450415 | 18:18 |
| mordred | morgan: oh - sorry - didn't see that- yes, I can re-remove it | 18:19 |
| morgan | mordred: sorry, was trying to save you re-revving it | 18:19 |
| ayoung | https://review.openstack.org/#/c/450415/19..20/specs/keystone/pike/application-credentials.rst | 18:19 |
| lbragstad | the thing that worries me is that the policy/api changes based on the user calling it and the body of the request | 18:19 |
| morgan | mordred: np, just to isolate that bit (we can add that in a followup that is not tied to base functionality) | 18:19 |
| morgan | mordred: or create a new API if it is easier. | 18:20 |
| morgan | mordred: just trying to make sure we can easily +2/land this spec | 18:20 |
| samueldmq | cmurphy: mordred: I just left a couple of comments/questions on PS19 | 18:20 |
| samueldmq | (mordred was too quick and submitted PS20) | 18:20 |
| ayoung | lbragstad, I don't love that either ,but it is the same kind of thing we have to deal with the actions API. We know how to do that | 18:20 |
| morgan | annnnyway | 18:26 |
| morgan | i think we unblocked the major sticking points ayoung | 18:26 |
| ayoung | WFM | 18:26 |
| morgan | we can follow up in not-this-release with addtional capabilities and spend time makiung sure they are right | 18:26 |
| morgan | but the core of rotaable, limited scope "creds" | 18:27 |
| morgan | that is good. | 18:27 |
| cmurphy | ++ | 18:27 |
| mordred | ok. I've gota few more updates based on samueldmq's questions (mostly just adding clarifying sentences) | 18:34 |
| openstackgerrit | Monty Taylor proposed openstack/keystone-specs master: Application Credentials for application authn https://review.openstack.org/450415 | 18:35 |
| samueldmq | aha so I had good questions | 18:35 |
| morgan | mordred: nice | 18:39 |
| ayoung | lbragstad, so, on RBAC in middleware, if the spec is not approved, can the implementation get merged tagged as experimental? | 18:39 |
| lbragstad | ayoung: i had comments on the specs - not sure if they are still there though | 18:39 |
| ayoung | lbragstad, regardless. I am assuming we are not going to resolve those before spec freeze | 18:40 |
| ayoung | I'd rather get the implemenation out there for people to use, but disabled by default, experiemantal, etc | 18:40 |
| ayoung | and all the caveats of "we are going to break this, don't cry when we do" | 18:40 |
| lbragstad | ayoung: what about a feature branch? | 18:40 |
| ayoung | lbragstad, nope | 18:41 |
| lbragstad | morgan: have we ever used a feature branch before? | 18:41 |
| ayoung | lbragstad, does not fall in line with any of the workflows I use | 18:41 |
| lbragstad | ayoung: it would get you what you want, right? | 18:43 |
| morgan | feature branches were used for fernet airi | 18:46 |
| morgan | but otherwise not really | 18:46 |
| lbragstad | yeah - that was a branch of my keystone fork - but similar concept | 18:46 |
| *** ducttape_ has joined #openstack-keystone | 18:51 | |
| samueldmq | mordred: final questions in the spec | 18:53 |
| samueldmq | thanks for the answers on my previous questions | 18:53 |
| morgan | mordred: commented inline | 18:59 |
| morgan | the only real question (and could be a followup) do we want to make the POST return {"application_credential": { ... }, "application_credential_secret": <secret> }, instead of embedding secret in "application_credential", so "app_cred" mirrors what is given in a GET. | 19:00 |
| morgan | mordred: still +2 | 19:00 |
| *** rderose has quit IRC | 19:03 | |
| *** aojea has quit IRC | 19:05 | |
| *** dikonoor has quit IRC | 19:13 | |
| mordred | morgan: I'd be fine with that | 19:13 |
| morgan | mordred: i left a comment, but +2'd the spec | 19:14 |
| morgan | it can be done in a follow up | 19:14 |
| morgan | if folks like it better | 19:14 |
| lbragstad | stable backport reviews https://review.openstack.org/#/c/469069/ | 19:14 |
| lbragstad | and stable newton but i'm not sure it's applicable https://review.openstack.org/#/c/469514/ | 19:15 |
| *** aojea has joined #openstack-keystone | 19:20 | |
| openstackgerrit | Merged openstack/keystone-specs master: Application Credentials for application authn https://review.openstack.org/450415 | 19:22 |
| samueldmq | mordred: ^ well done :) | 19:22 |
| cmurphy | \o/ | 19:23 |
| *** aojea has quit IRC | 19:25 | |
| openstackgerrit | Monty Taylor proposed openstack/keystone-specs master: Update a few nits in the application credentials spec https://review.openstack.org/472783 | 19:25 |
| mordred | samueldmq, cmurphy, morgan, lbragstad, ayoung: yay thanks!!!! | 19:26 |
| *** nishaYadav has quit IRC | 19:29 | |
| cmurphy | anyone want to review https://review.openstack.org/#/c/471283/ and https://review.openstack.org/#/c/471284/ for me? (and also please add keystone-tempest-plugin to your watchlists) | 19:47 |
| lbragstad | https://bugs.launchpad.net/keystone/+bug/1696308 would be a good bug to fix in case anyone is looking for one to work on | 19:49 |
| openstack | Launchpad bug 1696308 in OpenStack Identity (keystone) "list revoked tokens API returns 500 InternalServerError" [High,Triaged] | 19:49 |
| breton | lbragstad: i thought this error is due to pki_setup not being run | 19:53 |
| lbragstad | breton: it is - but i'm not sure we should return a 500 in the event it isn't run | 19:54 |
| lbragstad | could we make that better? | 19:54 |
| breton | lbragstad: what will fernet return if there are no keys? | 19:54 |
| *** spzala has quit IRC | 19:54 | |
| lbragstad | breton: ah - that's fair | 19:55 |
| breton | i would probably give it wishlist priority :p | 19:55 |
| breton | or even "won't fix" | 19:56 |
| breton | i think we didn't even fully delete PKI stuff because of this | 19:56 |
| lbragstad | breton: yeah - i think that was because it would have been a backwards incompatible api change | 19:57 |
| lbragstad | to rip out the api completely | 19:57 |
| lbragstad | breton: better? https://bugs.launchpad.net/keystone/+bug/1696308 | 19:58 |
| openstack | Launchpad bug 1696308 in OpenStack Identity (keystone) "list revoked tokens API returns 500 InternalServerError" [Wishlist,Triaged] | 19:58 |
| samueldmq | cmurphy: neat, approved | 20:05 |
| cmurphy | ty samueldmq gagehugo lbragstad | 20:05 |
| cmurphy | samueldmq: re lxml it looks like the unit tests needs it | 20:09 |
| *** ducttap__ has joined #openstack-keystone | 20:10 | |
| samueldmq | cmurphy: ah okay :( | 20:11 |
| samueldmq | actually :) it's good we test things in our unit tests too | 20:11 |
| cmurphy | lol yes | 20:12 |
| *** ducttape_ has quit IRC | 20:13 | |
| *** thorst_afk has quit IRC | 20:18 | |
| *** thorst_afk has joined #openstack-keystone | 20:20 | |
| *** aojea has joined #openstack-keystone | 20:21 | |
| *** thorst_afk has quit IRC | 20:25 | |
| *** ducttap__ has quit IRC | 20:27 | |
| *** spzala has joined #openstack-keystone | 20:28 | |
| *** edmondsw has quit IRC | 20:28 | |
| *** phalmos has quit IRC | 20:30 | |
| *** ducttape_ has joined #openstack-keystone | 20:34 | |
| openstackgerrit | Merged openstack/keystone-tempest-plugin master: Cleanup cookiecutter defaults https://review.openstack.org/471283 | 20:37 |
| openstackgerrit | Merged openstack/keystone-tempest-plugin master: Add lxml to requirements.txt https://review.openstack.org/471284 | 20:37 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements https://review.openstack.org/472807 | 20:39 |
| *** thorst_afk has joined #openstack-keystone | 20:39 | |
| *** thorst_afk has quit IRC | 20:43 | |
| *** spilla has quit IRC | 20:47 | |
| *** edmondsw has joined #openstack-keystone | 21:35 | |
| *** raildo has quit IRC | 21:39 | |
| *** edmondsw has quit IRC | 21:40 | |
| *** chlong has quit IRC | 21:58 | |
| *** dave-mccowan has quit IRC | 22:06 | |
| *** dave-mccowan has joined #openstack-keystone | 22:07 | |
| *** rcernin has quit IRC | 22:19 | |
| *** ducttape_ has quit IRC | 22:21 | |
| *** davechen has quit IRC | 22:23 | |
| *** davechen has joined #openstack-keystone | 22:23 | |
| *** gagehugo has quit IRC | 22:25 | |
| lbragstad | morgan: i'm getting a failure locally with the keystone tests saying the bcrypt needs to be installed | 22:26 |
| lbragstad | morgan: how is that not failing in the gate? | 22:27 |
| *** ducttape_ has joined #openstack-keystone | 22:27 | |
| morgan | lbragstad: uhm. | 22:27 |
| morgan | lbragstad: old venv? | 22:27 |
| lbragstad | i just rebuilt it | 22:27 |
| morgan | it's part of rquirements now, or should be iirc | 22:27 |
| morgan | weird. | 22:27 |
| lbragstad | morgan: ++ yeah, it's part of requirements | 22:27 |
| lbragstad | but i'm wondering if it needs to be in https://github.com/openstack/keystone/blob/master/test-requirements.txt ? | 22:28 |
| morgan | https://github.com/openstack/keystone/blob/master/requirements.txt#L22 | 22:28 |
| morgan | nah | 22:28 |
| morgan | both are installe | 22:28 |
| morgan | d | 22:28 |
| morgan | did you rebuild your venv then cvheckout master? | 22:28 |
| lbragstad | maybe? let me try again | 22:29 |
| lbragstad | it's friday - my fingers are on auto-pilot | 22:29 |
| lbragstad | so that *is* a possibility | 22:29 |
| *** ducttape_ has quit IRC | 22:32 | |
| lbragstad | because both requirements and test-requirements get installed for tests, right? | 22:33 |
| *** aojea has quit IRC | 22:33 | |
| *** aojea has joined #openstack-keystone | 22:34 | |
| *** r-daneel has quit IRC | 22:34 | |
| *** piliman974 has quit IRC | 22:39 | |
| *** aojea has quit IRC | 22:39 | |
| *** piliman974 has joined #openstack-keystone | 22:40 | |
| *** pnavarro has quit IRC | 22:42 | |
| *** catintheroof has quit IRC | 22:42 | |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Flag GET APIs that need corresponding HEAD API https://review.openstack.org/471919 | 22:56 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Add HEAD APIs to federated API https://review.openstack.org/472858 | 22:56 |
| *** dougshelley66 has joined #openstack-keystone | 22:59 | |
| morgan | lbragstad: yes | 23:06 |
| *** piliman974 has quit IRC | 23:07 | |
| *** aojea has joined #openstack-keystone | 23:35 | |
| *** aojea has quit IRC | 23:40 | |
| *** piliman974 has joined #openstack-keystone | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!