| *** spilla has quit IRC | 00:01 | |
| *** masterjcool has joined #openstack-keystone | 00:01 | |
| *** jlopezgu_ has quit IRC | 00:02 | |
| *** thorst has joined #openstack-keystone | 00:02 | |
| *** gsilvis has joined #openstack-keystone | 00:02 | |
| *** thorst has quit IRC | 00:07 | |
| *** dikonoor has joined #openstack-keystone | 00:15 | |
| *** agrebennikov has quit IRC | 00:34 | |
| *** thorst has joined #openstack-keystone | 00:34 | |
| *** lucasxu has joined #openstack-keystone | 00:36 | |
| *** thorst has quit IRC | 00:38 | |
| *** lucasxu has quit IRC | 00:40 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: Replace usages of SHA1 with SHA256 https://review.openstack.org/453357 | 00:43 |
|---|---|---|
| openstackgerrit | D G Lee proposed openstack/keystonemiddleware master: Remove log translations https://review.openstack.org/447841 | 00:44 |
| *** zhurong has joined #openstack-keystone | 00:45 | |
| *** hoonetorg has quit IRC | 01:02 | |
| *** liujiong has joined #openstack-keystone | 01:18 | |
| *** dikonoor has quit IRC | 01:21 | |
| openstackgerrit | Emilien Macchi proposed openstack/keystone master: Add sem-ver flag so pbr generates correct version https://review.openstack.org/453404 | 01:27 |
| *** zhangjl has joined #openstack-keystone | 01:30 | |
| openstackgerrit | Emilien Macchi proposed openstack/keystone master: Add sem-ver flag so pbr generates correct version https://review.openstack.org/453420 | 01:33 |
| *** thorst has joined #openstack-keystone | 01:38 | |
| *** edmondsw has joined #openstack-keystone | 01:41 | |
| *** thorst has quit IRC | 01:43 | |
| *** edmondsw has quit IRC | 01:46 | |
| *** Brent_ has joined #openstack-keystone | 01:52 | |
| *** zhurong has quit IRC | 01:52 | |
| *** Brent_ has quit IRC | 01:56 | |
| *** yulijie has quit IRC | 01:56 | |
| *** zhurong has joined #openstack-keystone | 01:57 | |
| *** masber has quit IRC | 01:57 | |
| *** jamielennox is now known as jamielennox|away | 02:07 | |
| *** jamielennox|away is now known as jamielennox | 02:21 | |
| *** zhurong has quit IRC | 02:38 | |
| *** thorst has joined #openstack-keystone | 02:40 | |
| *** ravelar has quit IRC | 02:49 | |
| *** Shunli has joined #openstack-keystone | 02:56 | |
| *** KarolynC has joined #openstack-keystone | 02:58 | |
| *** thorst has quit IRC | 02:58 | |
| *** brenttang has joined #openstack-keystone | 03:00 | |
| *** KarolynC has left #openstack-keystone | 03:02 | |
| *** zhurong has joined #openstack-keystone | 03:12 | |
| *** links has joined #openstack-keystone | 03:16 | |
| *** nicolasbock has quit IRC | 03:20 | |
| *** knangia has quit IRC | 03:21 | |
| *** adriant has joined #openstack-keystone | 03:30 | |
| *** edmondsw has joined #openstack-keystone | 03:30 | |
| *** brenttang has quit IRC | 03:33 | |
| *** edmondsw has quit IRC | 03:34 | |
| *** stingaci has joined #openstack-keystone | 03:35 | |
| openstackgerrit | Merged openstack/keystone master: Move credential policies to DocumentedRuleDefault https://review.openstack.org/449233 | 03:36 |
| *** stingaci has quit IRC | 03:39 | |
| *** namnh has joined #openstack-keystone | 03:46 | |
| *** rderose has quit IRC | 03:47 | |
| *** stingaci has joined #openstack-keystone | 03:47 | |
| *** masber has joined #openstack-keystone | 03:56 | |
| *** dave-mccowan has quit IRC | 04:05 | |
| *** rcernin has joined #openstack-keystone | 04:06 | |
| *** stradling has joined #openstack-keystone | 04:09 | |
| *** zhurong has quit IRC | 04:12 | |
| *** rcernin has quit IRC | 04:13 | |
| *** dikonoor has joined #openstack-keystone | 04:27 | |
| *** zhurong has joined #openstack-keystone | 04:35 | |
| *** richm has quit IRC | 04:36 | |
| *** richm has joined #openstack-keystone | 04:41 | |
| *** MarkMielke has joined #openstack-keystone | 04:43 | |
| *** chlong has quit IRC | 04:49 | |
| *** Shunli has quit IRC | 04:52 | |
| *** knangia has joined #openstack-keystone | 04:53 | |
| *** thorst has joined #openstack-keystone | 04:55 | |
| *** thorst has quit IRC | 05:00 | |
| *** lamt has joined #openstack-keystone | 05:03 | |
| *** jaosorior_away is now known as jaosorior | 05:11 | |
| *** aojea has joined #openstack-keystone | 05:21 | |
| *** tonyb_ is now known as tonyb | 05:25 | |
| *** Shunli has joined #openstack-keystone | 05:29 | |
| *** aojea has quit IRC | 05:30 | |
| *** hoonetorg has joined #openstack-keystone | 05:33 | |
| *** stradling has quit IRC | 05:36 | |
| *** lamt has quit IRC | 05:40 | |
| *** richm has quit IRC | 05:44 | |
| *** toabctl has joined #openstack-keystone | 05:52 | |
| toabctl | could somebody have a look at https://review.openstack.org/#/c/453245/ please? the tests for keystonemiddleware are failing due to a oslo.messaging update | 05:53 |
| *** Shunli has quit IRC | 05:53 | |
| *** stingaci has quit IRC | 05:53 | |
| toabctl | ayoung, ^^ | 05:54 |
| *** Shunli has joined #openstack-keystone | 05:54 | |
| *** thorst has joined #openstack-keystone | 05:56 | |
| *** thorst has quit IRC | 06:01 | |
| *** pcaruana has joined #openstack-keystone | 06:08 | |
| *** hoonetorg has quit IRC | 06:29 | |
| *** rcernin has joined #openstack-keystone | 06:31 | |
| *** voelzmo has joined #openstack-keystone | 06:40 | |
| *** hoonetorg has joined #openstack-keystone | 06:42 | |
| *** voelzmo has quit IRC | 06:45 | |
| *** voelzmo has joined #openstack-keystone | 06:45 | |
| *** tesseract has joined #openstack-keystone | 06:52 | |
| *** voelzmo has quit IRC | 06:55 | |
| *** voelzmo has joined #openstack-keystone | 06:56 | |
| *** thorst has joined #openstack-keystone | 06:57 | |
| *** knangia has quit IRC | 07:01 | |
| *** thorst has quit IRC | 07:01 | |
| *** zsli_ has joined #openstack-keystone | 07:02 | |
| *** zsli_ has quit IRC | 07:03 | |
| *** zsli_ has joined #openstack-keystone | 07:03 | |
| *** zsli_ has quit IRC | 07:04 | |
| *** zsli_ has joined #openstack-keystone | 07:04 | |
| *** zsli_ has quit IRC | 07:05 | |
| *** voelzmo has quit IRC | 07:16 | |
| *** aojea has joined #openstack-keystone | 07:24 | |
| *** voelzmo has joined #openstack-keystone | 07:26 | |
| *** Shunli has quit IRC | 07:28 | |
| *** Shunli has joined #openstack-keystone | 07:28 | |
| *** Shunli has quit IRC | 07:28 | |
| *** Shunli has joined #openstack-keystone | 07:28 | |
| *** voelzmo has quit IRC | 07:35 | |
| *** Aqsa has joined #openstack-keystone | 07:50 | |
| *** thorst has joined #openstack-keystone | 07:57 | |
| *** zzzeek has quit IRC | 08:00 | |
| *** zzzeek has joined #openstack-keystone | 08:00 | |
| *** aojea_ has joined #openstack-keystone | 08:01 | |
| *** aojea has quit IRC | 08:04 | |
| *** thorst has quit IRC | 08:17 | |
| *** voelzmo has joined #openstack-keystone | 08:21 | |
| *** voelzmo has quit IRC | 08:26 | |
| *** jaosorior is now known as jaosorior_lunch | 08:31 | |
| *** henrynash has joined #openstack-keystone | 08:38 | |
| *** namnh has quit IRC | 08:41 | |
| *** bjornar_ has joined #openstack-keystone | 08:41 | |
| *** thorst has joined #openstack-keystone | 09:14 | |
| *** thorst has quit IRC | 09:18 | |
| *** zsli_ has joined #openstack-keystone | 09:29 | |
| *** Shunli has quit IRC | 09:32 | |
| *** zsli_ has quit IRC | 09:36 | |
| *** liujiong has quit IRC | 09:55 | |
| *** mvk has quit IRC | 10:00 | |
| *** nicolasbock has joined #openstack-keystone | 10:07 | |
| *** voelzmo has joined #openstack-keystone | 10:10 | |
| *** richm has joined #openstack-keystone | 10:13 | |
| *** voelzmo has quit IRC | 10:14 | |
| *** henrynash has quit IRC | 10:18 | |
| *** pcaruana|afk| has joined #openstack-keystone | 10:21 | |
| *** pcaruana|afk| has quit IRC | 10:23 | |
| *** pcaruana has quit IRC | 10:24 | |
| *** pcaruana has joined #openstack-keystone | 10:25 | |
| *** zhurong has quit IRC | 10:30 | |
| *** jaosorior_lunch is now known as jaosorior | 10:31 | |
| *** mvk has joined #openstack-keystone | 10:32 | |
| *** voelzmo has joined #openstack-keystone | 10:38 | |
| *** adriant has quit IRC | 10:51 | |
| *** stingaci has joined #openstack-keystone | 10:55 | |
| *** zhangjl has quit IRC | 10:57 | |
| *** stingaci has quit IRC | 10:59 | |
| *** dave-mccowan has joined #openstack-keystone | 11:07 | |
| samueldmq | toabctl: done | 11:13 |
| samueldmq | morning keystone | 11:13 |
| *** thorst has joined #openstack-keystone | 11:15 | |
| *** thorst has quit IRC | 11:19 | |
| *** cristicalin has joined #openstack-keystone | 11:22 | |
| ayoung | toabctl, loooking | 11:23 |
| * ayoung shrugs | 11:25 | |
| *** stradling has joined #openstack-keystone | 11:30 | |
| *** thorst has joined #openstack-keystone | 11:41 | |
| samueldmq | ayoung: dstanek: lbragstad: I'd appreciate your view on bug 1680040 | 11:48 |
| openstack | bug 1680040 in OpenStack Identity (keystone) "Not all GET should have a correspondent HEAD, and vice-versa" [Undecided,New] https://launchpad.net/bugs/1680040 | 11:48 |
| samueldmq | ayoung: dstanek: lbragstad: it became more obvious to me when reviewing antwash's docs on the available APIs for policies | 11:49 |
| *** cristicalin has quit IRC | 11:52 | |
| ayoung | samueldmq, not worth the effort, and the logic is suspect | 11:52 |
| ayoung | samueldmq, checking an endpoint exisitence should be fine | 11:53 |
| ayoung | HEAD on the lists is dumb, as you point out | 11:53 |
| ayoung | as there will always be a list object , just it might be empty | 11:53 |
| samueldmq | ayoung: it's not checking endpoint's existence, just the existence of the relation project/endpoint | 11:53 |
| samueldmq | ayoung: that can be accomplished with the HEAD | 11:54 |
| ayoung | samueldmq, GET /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id} | 11:54 |
| ayoung | Yeah, but I'm not sure I agree with removing that, or if we should fill in the body with something sane | 11:54 |
| ayoung | like at least the link to the service object | 11:55 |
| ayoung | probably the latter | 11:55 |
| samueldmq | ayoung: yes, the point is that we don't have a representation for that body | 11:55 |
| samueldmq | and we don't need to | 11:55 |
| ayoung | why not? | 11:55 |
| samueldmq | there is no entity for relations in keystone | 11:55 |
| ayoung | just because current clients don't use it does not mean it should not be there | 11:55 |
| samueldmq | they can't use because it does not exist | 11:56 |
| samueldmq | I don't think GET /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id} | 11:56 |
| samueldmq | returning {'project_id': ID, 'endpoint_id': ID} is any useful | 11:56 |
| ayoung | I understand, but it should actually return the same value as GET /catalog/endpoints/{endpoint_id} | 11:56 |
| ayoung | or a pointer to it | 11:56 |
| ayoung | it is pretty useless as is | 11:57 |
| samueldmq | ayoung: agreed. I don't see the point of returning anything in an operation that is designed to check | 11:57 |
| ayoung | but, not worth the time to remove things we've documented | 11:58 |
| samueldmq | ayoung: the endpoint could be GET directly, I'd vote for only keep HEAD when we need to check | 11:58 |
| ayoung | just to "clean up" | 11:58 |
| samueldmq | ayoung: but that's a reasonable alternative, yes | 11:58 |
| ayoung | don't remove. | 11:58 |
| ayoung | you don't know who decided to use a documented API, and who it would break | 11:58 |
| samueldmq | ayoung: we're only starting to document that now afaik in the policy docs effort | 11:58 |
| samueldmq | someone out there could be using one of those APIs though, even if it's not documented in our API docs | 12:00 |
| ayoung | samueldmq, if you really care about REST compliance, there are far more important aspectes we are missing. HATEOAS | 12:00 |
| samueldmq | ayoung: example ? | 12:01 |
| ayoung | samueldmq, discoverability | 12:01 |
| ayoung | samueldmq, if we had implemented Keystone as a Web UI it would be obvious | 12:01 |
| *** raildo has joined #openstack-keystone | 12:01 | |
| ayoung | from htpps://servername:35357 you can find /v3 | 12:01 |
| ayoung | from /v3 you cannot find anything | 12:01 |
| ayoung | from /v3/users you cannot find the data that tells you how to add a new user | 12:02 |
| ayoung | etc etc etc | 12:02 |
| samueldmq | ayoung: like discovering what's in the next level, and so on | 12:02 |
| ayoung | yep | 12:02 |
| samueldmq | ayoung: from /v3/users you could return the json schema representation for a user entity, for example ? | 12:03 |
| ayoung | samueldmq, or figuring out how to return "here is the role you need to execute this api..." | 12:03 |
| samueldmq | ayoung: yes | 12:03 |
| *** rmascena has quit IRC | 12:03 | |
| ayoung | samueldmq, so review my patch, please | 12:03 |
| ayoung | and my spec on it | 12:04 |
| samueldmq | ayoung: API discoverability is important to app developers I think, seeing what's available and how it's structured/represented | 12:04 |
| samueldmq | ayoung: 'roles for APIs' might be specially useful for users/admins to give permissions to those users | 12:04 |
| samueldmq | ayoung: https://review.openstack.org/#/c/401808/ ? | 12:05 |
| openstackgerrit | ayoung proposed openstack/keystone-specs master: Commit to RBAC in middleware in Pike release https://review.openstack.org/452198 | 12:05 |
| samueldmq | ayoung: and this is the spec ^ ? | 12:06 |
| *** edmondsw has joined #openstack-keystone | 12:10 | |
| openstackgerrit | Merged openstack/keystonemiddleware master: Remove deprecated oslo.messaging aliases parameter https://review.openstack.org/453245 | 12:23 |
| ayoung | samueldmq, yep | 12:25 |
| *** thiagolib has joined #openstack-keystone | 12:28 | |
| *** shuyingy_ has joined #openstack-keystone | 12:31 | |
| cmurphy | samueldmq: i think notmorgan may have thoughts on GET/HEAD requests as he originally filed https://bugs.launchpad.net/keystone/+bug/1370335 | 12:32 |
| openstack | Launchpad bug 1370335 in OpenStack Identity (keystone) "Keystone should support HEAD requests for all GET /v3/* actions" [Wishlist,Fix released] - Assigned to Colleen Murphy (krinkle) | 12:32 |
| *** shuyingy_ has quit IRC | 12:33 | |
| samueldmq | cmurphy: nice catch, thanks for the heads up | 12:33 |
| cmurphy | np | 12:34 |
| samueldmq | notmorgan: bug 1680040 | 12:34 |
| openstack | bug 1680040 in OpenStack Identity (keystone) "Not all GET should have a correspondent HEAD, and vice-versa" [Undecided,New] https://launchpad.net/bugs/1680040 | 12:34 |
| *** lamt has joined #openstack-keystone | 12:40 | |
| *** henrynash has joined #openstack-keystone | 12:41 | |
| samueldmq | ayoung: done, commented on the spec | 12:44 |
| -openstackstatus- NOTICE: The Gerrit service on http://review.openstack.org is being restarted to address hung remote replication tasks, and should return to an operable state momentarily | 12:51 | |
| dstanek | samueldmq: we need to keep HEAD requests. | 12:52 |
| dstanek | samueldmq: do we specifically implement HEAD requests that are not just a GET without the body? | 12:52 |
| dstanek | actually...we do and that's no a great thing | 12:55 |
| *** markvoelker has joined #openstack-keystone | 12:55 | |
| openstackgerrit | Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585 | 12:59 |
| samueldmq | dstanek: yes, as per the examples I have put in the bug description | 13:03 |
| *** spilla has joined #openstack-keystone | 13:04 | |
| *** shuyingya has joined #openstack-keystone | 13:06 | |
| dstanek | samueldmq: i commented on the bug. not sure if we should remove them | 13:06 |
| samueldmq | dstanek I agree with you that HEAD is important, but when it makes sense | 13:08 |
| dstanek | samueldmq: in what case does it not make sense? | 13:08 |
| samueldmq | HEAD /role_assignments does not make sense at all for example | 13:08 |
| samueldmq | dstanek: ^ | 13:08 |
| samueldmq | it's not checking the existence of anything | 13:08 |
| *** links has quit IRC | 13:08 | |
| dstanek | samueldmq: a cache check | 13:08 |
| *** smccully has joined #openstack-keystone | 13:08 | |
| samueldmq | it's not referencing to the existence of an entity | 13:08 |
| samueldmq | dstanek: what is a cache check ? | 13:09 |
| dstanek | if we implement cache control headers, (or even not in some cases) this is how you would check to see if you needed to download the resource again | 13:10 |
| *** catintheroof has joined #openstack-keystone | 13:10 | |
| *** catintheroof has quit IRC | 13:10 | |
| *** shuyingya has quit IRC | 13:11 | |
| *** catintheroof has joined #openstack-keystone | 13:11 | |
| samueldmq | dstanek: but you'd need to provide something to the server. correct? | 13:12 |
| samueldmq | dstanek: such as the timestamp of the response you have in hands | 13:12 |
| smccully | HI there, I submitted a Bug a couple of Days Ago. I am wondering if I could get some feedback. I added a few reviewers, based on previous Reviews I saw on gerrit | 13:13 |
| smccully | https://bugs.launchpad.net/keystoneauth/+bug/1678686 | 13:13 |
| openstack | Launchpad bug 1678686 in keystoneauth "keystoneauth doesn't use a default cafile" [Undecided,In progress] - Assigned to Sean McCully (sean-mccully) | 13:13 |
| smccully | https://review.openstack.org/#/c/452585/ | 13:14 |
| smccully | Not entirely sure on the current scope of the issue, but I think some of what I've would be a positive addition to the current codebase | 13:14 |
| smccully | If there's a better time to bring this up, lmk as well | 13:14 |
| *** henrynash_ has joined #openstack-keystone | 13:15 | |
| dstanek | samueldmq: nope, the server should respond with cache headers and that should be enough (cache-control, last-modified, etag, etc.) | 13:15 |
| dstanek | samueldmq: the client could send if-*, age, etc. | 13:16 |
| *** chlong has joined #openstack-keystone | 13:17 | |
| *** henrynash has quit IRC | 13:17 | |
| *** henrynash_ is now known as henrynash | 13:17 | |
| dstanek | smccully: if i'm reading correctly, this fixes an issue with how the cert path is found in older versions of 2.7? | 13:18 |
| samueldmq | dstanek: ok, that'd be useful in that case, but we don't do that :( | 13:18 |
| samueldmq | dstanek: also, what about the other case where a GET does not make sense and the HEAD does? | 13:18 |
| *** henrynash_ has joined #openstack-keystone | 13:19 | |
| smccully | @stanek, No this fixes an issue where your possibly using a selfsigned CA, or Cert and not all services let you pass CA Cert to Keystone Auth | 13:19 |
| samueldmq | I don't see a reason for supporting those now, as they are not useful at all :( | 13:19 |
| samueldmq | unless we do have plans to support the cache control HEADs | 13:19 |
| smccully | So you can update your local CA Chains, but Keystone Auth will not nessecarily use your System CA Bundle | 13:19 |
| dr_gogeta86 | hi guys | 13:19 |
| smccully | if you dont explicitly point it to the right path | 13:19 |
| *** henrynash__ has joined #openstack-keystone | 13:20 | |
| dr_gogeta86 | who can help me to find why keystone doesn't allow admin even with admin_token | 13:20 |
| dr_gogeta86 | ? | 13:20 |
| smccully | sorry, @dstanek ^^ | 13:20 |
| dstanek | samueldmq: we already have some caching support now. we just need to grow it | 13:21 |
| dstanek | samueldmq: i can't think of a case there that actually makes sense | 13:21 |
| smccully | @dstanek, The problem is KeystoneAuth is throwing SSL Verfication Exceptions, even though the CA has been added to the System OpenSSL CA Bundle | 13:21 |
| * samueldmq nods | 13:22 | |
| dstanek | dr_gogeta86: what error are you getting? | 13:22 |
| smccully | Most services allow you to define a "os-cacert" for use in verifcation HTTPS connection, but under all circumstances | 13:22 |
| dr_gogeta86 | 401 | 13:22 |
| smccully | this is very problematic | 13:22 |
| samueldmq | dstanek: let's see what other folks think about it too, thank you for your comment there | 13:22 |
| *** henrynash has quit IRC | 13:22 | |
| dstanek | smccully: ah, i see. ok - i can take a look today | 13:22 |
| smccully | but NOT under all cicrumstances | 13:22 |
| samueldmq | dstanek: I agree with you in the HEAD case if we have plans to grow our cache control support | 13:22 |
| *** henrynash has joined #openstack-keystone | 13:23 | |
| dstanek | samueldmq: i have plans to do it :-) i submitted patches to us and client code in the past, but didn't get a ton of bites....maybe i'll un-abandon and polish them off | 13:23 |
| *** henrynash_ has quit IRC | 13:23 | |
| samueldmq | dstanek: nice! | 13:24 |
| dstanek | samueldmq: we do lots of things like the vary header alrdady that only help the caching cause | 13:24 |
| dstanek | dr_gogeta86: what is in your logs? | 13:24 |
| dr_gogeta86 | nothing just the 401 thin | 13:24 |
| dr_gogeta86 | nothing just the 401 thing | 13:24 |
| dr_gogeta86 | but nova and other services are ok | 13:24 |
| samueldmq | dstanek: glad to hear. that might be a lot of effort, but is something great to have | 13:24 |
| dr_gogeta86 | just for the admin user | 13:24 |
| samueldmq | thanks for taking that | 13:24 |
| dr_gogeta86 | and is strange | 13:24 |
| *** henrynash__ has quit IRC | 13:24 | |
| *** knangia has joined #openstack-keystone | 13:25 | |
| dr_gogeta86 | dstanek, any hint ? | 13:26 |
| dstanek | dr_gogeta86: the only thing i can think of is that you are using incorrect credentials | 13:26 |
| dr_gogeta86 | ok | 13:27 |
| dstanek | dr_gogeta86: are you able to auth and get a token at all? | 13:27 |
| dr_gogeta86 | no | 13:27 |
| dr_gogeta86 | 401 | 13:27 |
| dr_gogeta86 | even with admin_token | 13:27 |
| dstanek | dr_gogeta86: well, the admin token might be a different problem. do you have the middleware enabled? | 13:27 |
| dr_gogeta86 | how to check | 13:27 |
| dr_gogeta86 | ? | 13:27 |
| notmorgan | samueldmq: please do not remove HEAD calls | 13:30 |
| dstanek | dr_gogeta86: it would be in your paste.ini file | 13:31 |
| dr_gogeta86 | one moment | 13:32 |
| dstanek | notmorgan: we are trying super hard to move away from RESTful APIs :-( | 13:32 |
| samueldmq | notmorgan: same argument as dstanek's ? i.e cache control | 13:32 |
| dr_gogeta86 | i think so | 13:32 |
| notmorgan | dstanek: clearly | 13:33 |
| notmorgan | samueldmq: yes and any number of things. It costs us 0 to support it | 13:34 |
| notmorgan | the code is "do the same request, set headers, drop body data, send on wire" | 13:34 |
| samueldmq | notmorgan: but at least it needs to make sense to support something | 13:34 |
| samueldmq | and be useful to something | 13:34 |
| notmorgan | no, it doesn't | 13:34 |
| samueldmq | not just because costs 0 correct | 13:34 |
| notmorgan | we should adhere to REST and HTTP specs | 13:34 |
| notmorgan | HEAD is... look i am way before coffee atm | 13:35 |
| samueldmq | from an entity point of view, HEAD /collection does not make any sense to me | 13:35 |
| samueldmq | you're not asserting the existence of anything at all | 13:35 |
| notmorgan | HEAD is a basic function of HTTP | 13:35 |
| samueldmq | would make sense for cache-control maybe | 13:35 |
| dstanek | notmorgan: to be fair samueldmq is talking about a few cases where we have additional methods for HEAD requests | 13:35 |
| notmorgan | dstanek: and in those cases we are doing it... well wrong | 13:35 |
| notmorgan | dstanek: we should support HEAD and GET equally everywhere | 13:36 |
| dstanek | notmorgan: maybe...or maybe not | 13:36 |
| notmorgan | for simplicity sake. | 13:36 |
| dstanek | samueldmq: there is no reason why checking the existeance of a colletion would be wrong | 13:36 |
| notmorgan | samueldmq: content length, cache-control, etc. all valid reasons to use HEAD even if you don't look at the content itself | 13:36 |
| samueldmq | dstanek: checking there is not an empty set of role_assingments for example ? | 13:36 |
| notmorgan | all useful | 13:37 |
| samueldmq | that could be okay, but not useful ? | 13:37 |
| notmorgan | remember, content-length needs to be the same with GET and HEAD (and if it's not, we broke something) | 13:37 |
| samueldmq | notmorgan: exactly, that's what dstanek pointed out | 13:37 |
| notmorgan | so an empty collection is [] | 13:37 |
| notmorgan | very small content length | 13:37 |
| notmorgan | that *can* be useful | 13:37 |
| dstanek | samueldmq: so some of you issue stems from not fulling understanding HATEOAS | 13:37 |
| dstanek | samueldmq: you might legit need to see if that resource is even a thing anymore | 13:38 |
| notmorgan | ftr: I want to go a step further and implement IMS for *everything* in keystone | 13:38 |
| samueldmq | notmorgan: IMS? | 13:38 |
| notmorgan | but we don't have all the backend data for that | 13:38 |
| notmorgan | if-modified-since | 13:38 |
| notmorgan | specifically for caching | 13:39 |
| samueldmq | dstanek: seeing if that resource is a thing could be done with GEt anyways, correct? | 13:39 |
| notmorgan | "has X resource been modified since Y" | 13:39 |
| dstanek | notmorgan: etag is easier. that was one of the keystone patches i threw together | 13:39 |
| samueldmq | notmorgan: yes that'd make it easier to understand why it makes sense | 13:39 |
| notmorgan | dstanek: both are useful, but IMS has less data on the wire, it's like head | 13:39 |
| dstanek | samueldmq: i don't understand the question | 13:39 |
| notmorgan | dstanek: and both can be implemented at the same time | 13:40 |
| samueldmq | dstanek: "samueldmq: you might legit need to see if that resource is even a thing anymore" | 13:40 |
| dstanek | notmorgan: less data? | 13:40 |
| samueldmq | dstanek: that could be accomplished by trying a GET on the colelction ? | 13:40 |
| notmorgan | dstanek: IMS responds with very little data (not the whole resource) if nothing has changed. | 13:40 |
| notmorgan | dstanek: and is useful outside of etags | 13:40 |
| notmorgan | dstanek: so you can do active validation of resource being the same. | 13:41 |
| dstanek | samueldmq: well no. typically you post to a collection to add to it...if you want to see if it's still there you would HEAD it and not pull down the entire collection | 13:41 |
| notmorgan | anyway.... not relavent for this | 13:41 |
| notmorgan | dstanek: ++ | 13:41 |
| dstanek | notmorgan: the same is true of etage | 13:41 |
| samueldmq | dstanek: exactly, but you do HEAD /collection/<id> | 13:41 |
| samueldmq | not HEAD /collection | 13:41 |
| dstanek | samueldmq: no, i want to know i the collection still exists | 13:41 |
| dstanek | samueldmq: so let's step back... | 13:42 |
| samueldmq | dstanek: like HEAD /role_assignments?user_id=<usre_id> | 13:42 |
| notmorgan | dstanek: about the same amount of work (though etags are a LOT more processing) | 13:42 |
| samueldmq | to make sure that collection still exists ? i.e there is any role assingment for that user | 13:42 |
| notmorgan | for us. | 13:42 |
| dstanek | samueldmq: my philosophy (which keystone doesn't share or understand) of API design is that the *only* URL you ever know for sure is a single entry point. every other URL is discovered through relationships. | 13:42 |
| samueldmq | dstanek: ok, so for example from /v3/ you should be able to discover everything | 13:43 |
| dstanek | samueldmq: so sometimes you cache things. for an examle, a user is cached. in that user data there if a reference to an attributes collection. some smart apps may user HEAD to verify that is still the collectiona dn if not fetch the user again (even though it is cached) | 13:44 |
| dstanek | samueldmq: yes | 13:44 |
| notmorgan | samueldmq: All general-purpose servers MUST support the methods GET and HEAD (RFC 7231), while we're not "General purpose", we are running under a general purpose service. we should let people consume HEAD | 13:44 |
| notmorgan | in all cases. | 13:44 |
| notmorgan | it costs us nothing to do so, really. | 13:44 |
| notmorgan | don't assume you know better than the end user. | 13:44 |
| dstanek | samueldmq: we do a terrible thing by documenting our routes in the API docs | 13:44 |
| notmorgan | for basic protocol level things. | 13:45 |
| *** lamt has quit IRC | 13:45 | |
| dstanek | samueldmq: and were heading straight into a ditch with using URL for policy (ditch meaning that REST is dead) | 13:45 |
| samueldmq | notmorgan: yes, my point was that we're not making it useful, because we don't even support cache-control properly today | 13:45 |
| notmorgan | then fix cache-control | 13:45 |
| samueldmq | notmorgan: but if we do have plans to (as dstanek said), that's nice | 13:45 |
| notmorgan | don't remove head | 13:45 |
| dstanek | samueldmq: even if we never implement we need to keep it | 13:46 |
| *** agrebennikov has joined #openstack-keystone | 13:46 | |
| samueldmq | ok, I am convinced in that case | 13:46 |
| dstanek | existence check all the things | 13:46 |
| samueldmq | but what about the other? GET /users/<uid>/groups/<gid> | 13:46 |
| samueldmq | ^ | 13:46 |
| samueldmq | that's basically checking a user is in a group, that's a HEAD for me | 13:47 |
| notmorgan | a GET can result in no data | 13:47 |
| notmorgan | and it's fine if GET response the same way | 13:47 |
| samueldmq | but what is that GET useful for ? | 13:47 |
| notmorgan | and can be used for existence | 13:47 |
| notmorgan | GET and HEAD are always interchangable, with the difference being HEAD is identical to GET without content | 13:47 |
| notmorgan | if GET has no content, it's still a gET request | 13:48 |
| samueldmq | ok, I thought HEAD was the one intended for checking existence | 13:48 |
| samueldmq | but seems like GET can be too | 13:48 |
| notmorgan | yes. | 13:48 |
| *** shuyingya has joined #openstack-keystone | 13:48 | |
| notmorgan | GET can always be used for existence as well | 13:48 |
| notmorgan | both are 100% valid to use. | 13:48 |
| dstanek | samueldmq: maybe your api grows data in the GET case | 13:48 |
| samueldmq | maybe not | 13:48 |
| samueldmq | gotcha | 13:49 |
| dstanek | samueldmq: when it was added, by whom, whatever | 13:49 |
| dstanek | notmorgan: what do you think of the RBAC by URL idea? | 13:50 |
| samueldmq | ok I am convinced that bug is not valid | 13:51 |
| samueldmq | thanks dstanek and notmorgan | 13:51 |
| dstanek | samueldmq: my pleasure | 13:51 |
| samueldmq | dstanek: notmorgan: is there a best-practice doc/book you use for designing rest apis ? | 13:51 |
| lbragstad | samueldmq i use dstanek | 13:51 |
| dstanek | lbragstad: lol | 13:52 |
| *** henrynash has quit IRC | 13:52 | |
| dstanek | samueldmq: the original thesis is a good place for theory and background | 13:52 |
| lbragstad | samueldmq " dstanek: the definitive guide to doing it better with REST" | 13:52 |
| samueldmq | lbragstad: ++ lol | 13:52 |
| dstanek | samueldmq: i found a reference when i was finding proof of my opinion on another REST bug....looking | 13:54 |
| dstanek | samueldmq: http://whatisrest.com/ | 13:54 |
| *** henrynash has joined #openstack-keystone | 13:55 | |
| dstanek | samueldmq: word of warning...i've only read a few paragraphs on that entire site to make sure their view of a particular topic matched mine | 13:55 |
| *** ravelar has joined #openstack-keystone | 13:59 | |
| * samueldmq nod | 14:01 | |
| samueldmq | dstanek: thanks for the link, I will have a look | 14:01 |
| *** henrynash has quit IRC | 14:04 | |
| *** jistr is now known as jistr|mtg | 14:07 | |
| knikolla | o/ | 14:09 |
| samueldmq | knikolla: o/ | 14:15 |
| *** mdavidson has quit IRC | 14:18 | |
| *** chris_hultin|AWA is now known as chris_hultin | 14:20 | |
| *** chris_hultin is now known as chris_hultin|AWA | 14:28 | |
| *** chris_hultin|AWA is now known as chris_hultin | 14:29 | |
| *** dikonoor has quit IRC | 14:45 | |
| *** stingaci has joined #openstack-keystone | 14:57 | |
| lbragstad | ping antwash, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, ravelar, morgan, raj_singh, johnthetubaguy, knikolla | 14:59 |
| lbragstad | pre policy meeting ping | 14:59 |
| edmondsw | lbragstad hour early again? | 14:59 |
| lbragstad | ahhhh!!! | 15:00 |
| *** bjornar_ has quit IRC | 15:00 | |
| edmondsw | :) | 15:00 |
| dstanek | lbragstad: an hour from now is when we have our rackspace team meeting | 15:01 |
| *** stingaci has quit IRC | 15:01 | |
| * lbragstad feels like he just used the @here feature of slack | 15:01 | |
| lbragstad | dstanek yeah | 15:01 |
| *** voelzmo has quit IRC | 15:01 | |
| edmondsw | someone needs to update their calendar :) | 15:01 |
| dstanek | lbragstad: so i won't be paying attention in policy for the first half :-) | 15:01 |
| lbragstad | edmondsw i know - i even have that meeting time set to UTC and i don't get the reminder for another half hour | 15:02 |
| *** chlong has quit IRC | 15:03 | |
| *** chlong has joined #openstack-keystone | 15:04 | |
| dstanek | lbragstad: you need to change you notification to match the time you want to notify chat :-) | 15:04 |
| *** rderose has joined #openstack-keystone | 15:04 | |
| lbragstad | dstanek yeah - that's a good idea | 15:04 |
| dstanek | stupid mac. have to reboot again | 15:06 |
| dolphm | dstanek: mine is at the apple store. repeatedly failed to boot after the last OS update. repeatedly failed to reinstall the OS via recovery mode. | 15:14 |
| *** shuyingya has quit IRC | 15:15 | |
| lbragstad | dolphm that sucks | 15:16 |
| lbragstad | would anyone be interested in running the policy meeting today? | 15:16 |
| EmilienM | lbragstad: hey, can we have https://review.openstack.org/#/c/453420/ merged asap please? It would help us to test upgrades in tripleo ci | 15:18 |
| breton | EmilienM: the commit looks empty to me | 15:20 |
| EmilienM | everyone asks me that :D | 15:21 |
| *** lamt has joined #openstack-keystone | 15:21 | |
| *** chlong has quit IRC | 15:21 | |
| EmilienM | breton: please look the commit message and https://docs.openstack.org/developer/pbr/#version | 15:21 |
| breton | EmilienM: you should tell about it in commit message :) | 15:22 |
| breton | i see the link | 15:22 |
| dolphm | breton: the important bit is the Sem-Ver footer in the commit message | 15:22 |
| breton | but it should say "the commit is not empty, to understand what it doesn look at <link>" | 15:23 |
| EmilienM | breton: sorry | 15:23 |
| ayoung | EmilienM, looking | 15:23 |
| ayoung | EmilienM, done | 15:24 |
| EmilienM | thx | 15:27 |
| ayoung | EmilienM, its a complex patch. I hope it passes CI. | 15:29 |
| ayoung | :) | 15:29 |
| EmilienM | lol | 15:29 |
| *** shuyingya has joined #openstack-keystone | 15:33 | |
| *** chlong has joined #openstack-keystone | 15:35 | |
| lbragstad | ayoung johnthetubaguy dstanek edmondsw heads up, i won't be able to attend the policy meeting today | 15:35 |
| *** shuyingya has quit IRC | 15:38 | |
| *** jistr|mtg is now known as jistr | 15:40 | |
| *** jlopezgu_ has joined #openstack-keystone | 15:43 | |
| edmondsw | lbragstad should we just cancel the meeting today? | 15:46 |
| lbragstad | edmondsw we can - but i want to make sure folks have the opportunity to visit amongst themselves if needed | 15:46 |
| lbragstad | at the same time - we have a bunch of specs in review that we can provide feedback on so we can have discussions around it next week | 15:48 |
| *** aojea_ has quit IRC | 15:49 | |
| toabctl | lbragstad, hey. I triggered a new keystonemiddleware release to be compatible with the latest oslo.messaging release. See https://review.openstack.org/#/c/453719/ . could you add your +1 as a PTL please? | 15:49 |
| EmilienM | ayoung: you rocks, thanks | 15:49 |
| ayoung | EmilienM, less Rock, more Swing | 15:49 |
| *** ravelar has quit IRC | 15:50 | |
| *** ravelar has joined #openstack-keystone | 16:01 | |
| ayoung | lbragstad, did you tag someone else to run it? | 16:10 |
| *** agrebennikov has quit IRC | 16:20 | |
| *** itisha has joined #openstack-keystone | 16:21 | |
| openstackgerrit | John Garbutt proposed openstack/keystone-specs master: WIP: Course Policy check in middelware https://review.openstack.org/453739 | 16:24 |
| johnthetubaguy | lbragstad: ayoung: tried to write up what I was describing I liked in the middleware checks ^ | 16:27 |
| *** chris_hultin is now known as chris_hultin|AWA | 16:38 | |
| lbragstad | johnthetubaguy awesome, thanks! | 16:39 |
| *** chris_hultin|AWA is now known as chris_hultin | 16:41 | |
| *** chris_hultin is now known as chultin | 16:43 | |
| *** tesseract has quit IRC | 16:43 | |
| *** chultin is now known as chris_hultin | 16:47 | |
| *** stingaci has joined #openstack-keystone | 16:55 | |
| ayoung | johnthetubaguy, no. please. | 17:02 |
| ayoung | johnthetubaguy, you are just going to give the illusion that things are fixable. They are not | 17:03 |
| ayoung | not that way | 17:03 |
| johnthetubaguy | ayoung: I am not saying that fixes everything, just that seems a way to stop some bleeding quickly | 17:03 |
| ayoung | johnthetubaguy, the switch needs to be in the auth_token section of the middleware, or it is not implementable | 17:04 |
| ayoung | johnthetubaguy, you don't put a band aid on a sucking chest wound | 17:04 |
| *** gus has quit IRC | 17:04 | |
| *** jamielennox has quit IRC | 17:04 | |
| ayoung | that will actually do more damage. Just help me get the RBAC in middleware approach in | 17:04 |
| ayoung | anything else is a distraction, and will hurt things | 17:04 |
| johnthetubaguy | but I don't think the current RBAC in middleware is workable from the operator point of view, because it leaves too many policy checks still in the code and its all very messy | 17:05 |
| *** gus has joined #openstack-keystone | 17:05 | |
| ayoung | irrelevant | 17:06 |
| ayoung | johnthetubaguy, think it through, please | 17:06 |
| johnthetubaguy | I guess I just don't understand the problems you are trying to fix yet | 17:06 |
| ayoung | assume that the projects are not going to change | 17:06 |
| ayoung | this is Keystones job to coordinate | 17:06 |
| johnthetubaguy | ayoung: for me the operability of this is king, and projects can and will change if even good reason too | 17:06 |
| ayoung | johnthetubaguy, have you ever tried to make a change across all the projects? | 17:07 |
| ayoung | heh | 17:07 |
| ayoung | no | 17:07 |
| ayoung | johnthetubaguy, this is what keystone does | 17:07 |
| ayoung | cinder does block storage | 17:07 |
| *** jamielennox has joined #openstack-keystone | 17:07 | |
| ayoung | neutron does networking | 17:07 |
| johnthetubaguy | the config changes have been fairly cross project | 17:07 |
| ayoung | keystone does access control | 17:07 |
| ayoung | johnthetubaguy, there is no guaranetee that even the Member role exists or is in use | 17:08 |
| johnthetubaguy | ayoung: agreed | 17:08 |
| *** jaosorior is now known as jaosorior_away | 17:08 | |
| ayoung | you add that in there, and you risk breaking people in deployment | 17:08 |
| johnthetubaguy | member role is not assumed | 17:08 |
| ayoung | so no changes to RBAC in the policy files can be added without breakage | 17:08 |
| ayoung | we do this in middleware, the operators can role it out | 17:09 |
| ayoung | we do it in middleware, it is available to all services when the middleware is updated | 17:09 |
| johnthetubaguy | ayoung: you can add changes without breaks, see the proposal in the Nova specs | 17:09 |
| ayoung | johnthetubaguy, heh | 17:09 |
| ayoung | that breaks everything | 17:10 |
| ayoung | Nova can't write a spec that is goin to then affect Neutron | 17:10 |
| ayoung | they need a neutron spec for that. And CInder | 17:10 |
| ayoung | and glance | 17:10 |
| ayoung | and keystone | 17:10 |
| ayoung | and any other service out there | 17:10 |
| johnthetubaguy | I still don't get the breaks everything thing | 17:10 |
| ayoung | this is not Nova's problem to solve, any more than Keystone can solve the per-instance ownership | 17:10 |
| ayoung | johnthetubaguy, you need to change the default policy in every.single.project | 17:11 |
| ayoung | including ones that use Keystone that are not uinder the big tent | 17:11 |
| johnthetubaguy | I still don't see why | 17:11 |
| johnthetubaguy | today any user has access across all the project by default, I don't change that | 17:12 |
| johnthetubaguy | its just that use has less access in Nova | 17:12 |
| ayoung | johnthetubaguy, this is why I am signed up to give a presentation on it at the summit | 17:12 |
| ayoung | I've explained this, individually, to many many people | 17:12 |
| ayoung | johnthetubaguy, but then you grant that access to new people, to people you might not have granted it to in the future | 17:13 |
| ayoung | and instead of them getting read only access, they have full access | 17:13 |
| ayoung | its not Nova's problem to solve | 17:13 |
| ayoung | read only, across the cluster, is a cluster admin decision, not a nova-core decision | 17:13 |
| ayoung | same for any other service out there, including keystone | 17:13 |
| ayoung | with the exception that Keystone is not yet doing its job in providind a mechanism to enforce, or even check, access | 17:14 |
| ayoung | johnthetubaguy, and, the moment Nova starts coding Role decisions into its policy files, it has effectively locked the entire body of projects in to allowing for that role to exist | 17:15 |
| ayoung | johnthetubaguy, what do you work on? What has been your focus? | 17:16 |
| johnthetubaguy | the focus is on our operators request the ability to have this fine grained roles to give a user read access only with Nova | 17:18 |
| johnthetubaguy | its really just putting into the source tree what operators are having to do by hand today | 17:18 |
| ayoung | johnthetubaguy, not just nova damnit | 17:18 |
| johnthetubaguy | we do in upstream, so each one of our users that wants this doesn't need to go through the pain, and upgrade it per release | 17:18 |
| ayoung | nova is not the only project that needs read only | 17:18 |
| johnthetubaguy | sure, agreed | 17:19 |
| ayoung | so until you can enforce "all existing users are Member" or whatever default role, across the board, you don't have a solution | 17:19 |
| johnthetubaguy | the roles we are adding are nova specific, like compute_observer (minus the obvious issue they get you write access using the defaults in other projects) | 17:19 |
| ayoung | nom, they are not | 17:19 |
| ayoung | we went through this | 17:20 |
| ayoung | I could not find the spec | 17:20 |
| ayoung | dolphm, and jamielennox wrote up a cross project spec fro this a year+ ago... | 17:20 |
| ayoung | I wish I could find the damn thing | 17:20 |
| ayoung | but the mechanism in the RBAC-middleware spec grew out of that process | 17:20 |
| johnthetubaguy | right, I am saying they should be service specific, so you can hand out read access to only Nova, eventually | 17:20 |
| johnthetubaguy | implied roles would then join up the read roles across different services as needed, I thought | 17:21 |
| ayoung | johnthetubaguy, sure you could (and probably should) use implied roles that way | 17:21 |
| ayoung | let me see ionce again is I can find their spec | 17:22 |
| ayoung | I don't even know what project they filed it under | 17:22 |
| *** mvk has quit IRC | 17:22 | |
| ayoung | johnthetubaguy, if you want that read only stuff to work, please support me on this | 17:22 |
| johnthetubaguy | it was openstack-specs I think | 17:22 |
| ayoung | it is one of the driving use cases... | 17:22 |
| ayoung | ok, let me look again | 17:22 |
| johnthetubaguy | I just don't see how it works for operators | 17:22 |
| johnthetubaguy | I added commens on the spec to ask the questions I have about your approach | 17:23 |
| ayoung | https://review.openstack.org/#/c/245629/ | 17:23 |
| lbragstad | i followed up with dolphm a while ago on ^ | 17:24 |
| lbragstad | i specifically asked why it failed | 17:24 |
| ayoung | lbragstad, one main reason was the inability to add a new role without opening up all the other services | 17:25 |
| lbragstad | I understood his explanation as, it was hard to get traction on various roles suggestions in openstack while several of the policies within openstack conflict | 17:25 |
| lbragstad | (i.e. we have a messy house, let's clean our house) | 17:25 |
| johnthetubaguy | the transition is always the hard bit | 17:26 |
| lbragstad | at the time, keystone was *trying* to support two different policy files, one of which didn't even work by default | 17:26 |
| johnthetubaguy | till someone tries it, its hard to know how hard it is, largely | 17:26 |
| johnthetubaguy | the deprecated_default rule approach in oslo.policy I think would help us with the transition | 17:27 |
| johnthetubaguy | its a bit nuts, but I think it helps smoother the rougher edges | 17:27 |
| lbragstad | johnthetubaguy did that just go into oslo.policy? | 17:27 |
| ayoung | Or, keystone could just do its damned job | 17:27 |
| johnthetubaguy | lbragstad: I don't think its implemented yet | 17:27 |
| lbragstad | for RuleDefault and DocumentedRuleDefault classes? | 17:27 |
| lbragstad | oh | 17:27 |
| johnthetubaguy | ah, no its an extra bit | 17:27 |
| ayoung | if we can't even handle RBAC we should just shutter the project | 17:27 |
| ayoung | its more an impedement than a benefit at this point | 17:28 |
| johnthetubaguy | I mean I agree getting RBAC working for operators is crazy important, but I would say keystone fixes a big set of useful issues for folks as it is | 17:28 |
| johnthetubaguy | lbragstad: basically, its where you log warnings if a user doesn't have the required role yet | 17:29 |
| lbragstad | johnthetubaguy sure - that'd be nice to have | 17:29 |
| johnthetubaguy | lbragstad: so you get a soft roll out of requiring a role | 17:29 |
| ayoung | johnthetubaguy, not really. There are much better tools for identity management out there. But we are not going that way | 17:29 |
| lbragstad | johnthetubaguy wasn't that staged for pike? | 17:29 |
| johnthetubaguy | lbragstad: we can't do any additional roles without it, AFAIK | 17:29 |
| johnthetubaguy | lbragstad: its kinda stuck in the Nova spec review at this point, not sure if its gone any further | 17:30 |
| lbragstad | ah | 17:30 |
| ayoung | johnthetubaguy, why are you tryin to undermine the RBAC in middleware approach? Is it because you don't understand it, or you think it is fundamentally flawed? | 17:30 |
| ayoung | And role enforce in policy,json is going to make life harder, not easier, to solve the problem. | 17:30 |
| * dolphm grabs the popcorn. | 17:30 | |
| ayoung | And-> any | 17:30 |
| lbragstad | i find the usability of the rbac in middleware approach to be more trouble for operators than it's worth | 17:30 |
| ayoung | dolphm, same ole same ole | 17:30 |
| ayoung | lbragstad, that is not an answer | 17:31 |
| johnthetubaguy | ayoung: its because of the reasons I added on the spec review, largely operability, and I don't quite understand what extra it gives us from the other more iterative approach that the deployers seems to prefer | 17:31 |
| ayoung | lbragstad, that is "I don't really understand it." | 17:31 |
| lbragstad | duplicating the role -> URL pattern -> operation mapping across openstack is going to be a maintenance nightmare | 17:31 |
| ayoung | lbragstad, nope | 17:31 |
| lbragstad | ayoung ok | 17:31 |
| lbragstad | ayoung walk me through an upgrade | 17:31 |
| ayoung | lbragstad, it solves a problem due to the way we do role to policy mapping, too | 17:31 |
| johnthetubaguy | ayoung: it a I don't think this works for operators, for the reasons I put on the spec review I spend two hours doing this morning | 17:32 |
| ayoung | but adding in a default is the primary thing there | 17:32 |
| lbragstad | we have default | 17:32 |
| lbragstad | they are in the project | 17:32 |
| ayoung | the fact that policy is not mapped to an URL means that to figure out what role you need, you have to read the code | 17:32 |
| ayoung | that is not an solution | 17:32 |
| johnthetubaguy | ayoung: thats not my main problem, just one of them | 17:32 |
| ayoung | johnthetubaguy, if I give in on this, it will stay broken | 17:33 |
| johnthetubaguy | ayoung: I think my main worry is the approach just doesn't fit peoples current deploy models and pipelines | 17:33 |
| ayoung | you will not get a soluytion, just more discussion | 17:33 |
| lbragstad | ayoung if i'm not understanding things, please walk me though what an upgrade looks like | 17:33 |
| ayoung | lbragstad, sure | 17:33 |
| johnthetubaguy | ayoung: I am not asking you to give in, I am trying to work out if the approach could be tweaked to deal with the issues I mention in the review | 17:34 |
| lbragstad | johnthetubaguy ++ | 17:34 |
| ayoung | OK, the assumption we have had thus far is that RBAC belonds in policy.json | 17:34 |
| ayoung | and a lot of things have come up to challenge that assumption | 17:34 |
| ayoung | we've based that assumption on the fact that it was the only tool available to customize access contrl | 17:35 |
| ayoung | so, we looked in to doing policy management via json, and a couple things became clear | 17:36 |
| ayoung | 1. the scope enforcement was something that people should not touch | 17:36 |
| dolphm | "RBAC belongs in policy.json" says nothing of how it's enforced, where it's enforced, or how it's managed | 17:36 |
| ayoung | all they can do is break it | 17:36 |
| ayoung | so, one of the early goal was to make it clearer where we were doing RBAC and where we were doing scope checks | 17:37 |
| johnthetubaguy | for me scope issues are more an interoperability problem, we have some folks using it too well right now, to work around not having hierarchical quotas (long story) | 17:37 |
| ayoung | dolphm, do you want me to address that? | 17:37 |
| dolphm | ayoung: not necessarily, i thought you were done -- continue first! | 17:37 |
| ayoung | dolphm, thanks | 17:37 |
| ayoung | arround 30 or so summits ago, David Lyl.e asked me how we could figure out (for horizon) what operations a user can do based on their roles | 17:38 |
| ayoung | at the time, it seemed like we could comb through the policy.json files to answer that question, too | 17:38 |
| ayoung | but we really can't. | 17:38 |
| ayoung | We can;t map from policy.json to operation | 17:39 |
| ayoung | its buried in code, in project specific ways | 17:39 |
| johnthetubaguy | you can't map from policy file to operation being available either, hence the capabilities API discussions | 17:39 |
| ayoung | then, we had people asking for standard roles | 17:39 |
| ayoung | johnthetubaguy, it may be. But they really are two different things | 17:40 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Remove unnecessary processing when deleting grant. https://review.openstack.org/450938 | 17:40 |
| ayoung | one is "can anyone do this" | 17:40 |
| ayoung | tjhe opther is "can I do this" | 17:40 |
| ayoung | very different questions, very different ways of getting to the answer | 17:40 |
| lbragstad | i thought the latter was the one david-lyle asked for | 17:40 |
| ayoung | lbragstad, nope | 17:40 |
| ayoung | lbragstad, he wanted to customize the set of operations a user could do based on their role | 17:40 |
| ayoung | I'm sure they wanted the other, too, but they didn't ask me for it | 17:41 |
| dolphm | customize the horizon UI * | 17:41 |
| ayoung | dolphm, yep | 17:41 |
| johnthetubaguy | but thats not what the API user wants to know, they want to know "will this API work for me (given my token) on this cloud/type of resource/resource?", but thats a whole different conversation | 17:41 |
| ayoung | dolphm, better if I had said: | 17:41 |
| ayoung | lbragstad, he wanted to customize the set of operations a user see in Horizon based on her role | 17:41 |
| dolphm | johnthetubaguy: that's about the same question that david-lyle presented | 17:41 |
| lbragstad | ayoung right - that makes sense | 17:42 |
| lbragstad | so based on a token, present me with a UI that makes sense for my scope and role | 17:42 |
| lbragstad | don't show me things I can't do | 17:42 |
| ayoung | lbragstad, right, and it is important for more than just Horizon | 17:43 |
| ayoung | specifically, in delegation agreements, like Trusts used in Heat, you want to figure out what role you need to delegate to a remote user so it can operate on your behalf | 17:43 |
| lbragstad | right - imo that sounds like "given this token what can I do?" not "given this operation, who can do it?" | 17:43 |
| ayoung | if I need something that can only reboot a VM, I don't want it to upload a snapshot or create a new image or some other operation | 17:44 |
| dolphm | lbragstad: the only context i've heard that second question in is auditing | 17:44 |
| johnthetubaguy | its often about a specific VM, FWIW | 17:44 |
| ayoung | so, the implied roles effort grew out of that: make it possible to break a big role down into smaller roles | 17:44 |
| lbragstad | dolphm ok - that makes sense | 17:44 |
| ayoung | but the discoverability part requires a mapping | 17:44 |
| ayoung | I'll try to stay focused | 17:45 |
| ayoung | there were a few efforts that went in parallel, but, I think your question is primarily why do I not think the operator experience is going to be negatively impacted? | 17:46 |
| ayoung | So, I started looking in to the mapping from policy to URLs/operations | 17:46 |
| ayoung | and I found out that very little policy does a role check today | 17:46 |
| ayoung | a couple in keystone, and then the ubiquitous 'admin' checks | 17:47 |
| ayoung | and admin, it turns out, is only sometimes scoped to a proejct | 17:47 |
| ayoung | it really is a global role in many operations | 17:47 |
| ayoung | so, we have to grandfather in 'admin' | 17:47 |
| ayoung | for the rest of the operations, what we really need is just a good default | 17:48 |
| *** agrebennikov has joined #openstack-keystone | 17:48 | |
| ayoung | ie. Member | 17:48 |
| ayoung | but how do we enforce it? | 17:48 |
| dstanek | dolphm: auditing in the sense that you are checking the see that the security policy really is what you think it is? | 17:48 |
| ayoung | so...look at the complexity of the cloudsample policy file once henrynash started trying to make it enforce domain policies | 17:49 |
| ayoung | its hard to understand | 17:49 |
| ayoung | when what we really want for a default is like this: | 17:49 |
| ayoung | service=compute all-verbs, all-urls, require: Member | 17:50 |
| ayoung | and use that rule unless there is something more explicit | 17:50 |
| ayoung | does it matter that it is a URL or a policy rule like compute:reboot_server? | 17:50 |
| dstanek | ayoung: to me yes | 17:50 |
| ayoung | Well, the second is only useful if you know in the code that you are doing the operation there and only there | 17:51 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Remove unnecessary processing when deleting grant. https://review.openstack.org/450938 | 17:51 |
| ayoung | dstanek, "me" meaning you as an operator? | 17:51 |
| dolphm | dstanek: yes, basically | 17:51 |
| ayoung | or you as a python developer? | 17:51 |
| dstanek | ayoung: i only have a direct perspective as a python dev...so that for sure. i still don't understand how we screwed up so bad that operators need to understand URL structures | 17:52 |
| ayoung | dstanek, the URL structure is our public contract | 17:53 |
| ayoung | dstanek, I was not around in the days when they designed the nova APIs | 17:54 |
| dstanek | ayoung: that's fundamentally bad and we shouldn't push that idea | 17:54 |
| ayoung | I can't speak to that. But I do recall the arguments dolphm put forth for the v3 apis | 17:54 |
| johnthetubaguy | it was just made to be backwards compatible with rackspace slicehost, AFAIK | 17:54 |
| ayoung | johnthetubaguy, Programming is like sex. Make one mistake and support it for the rest of your life. | 17:55 |
| dstanek | if we want to claim REST then we should at least *try* to do the right things...and then we'd get the design benefits associated with it | 17:55 |
| ayoung | dstanek, so, I looked in to that | 17:55 |
| ayoung | it turns out, there is no way in REST/HTTP to say "here is the role you need to perform that operation" | 17:55 |
| ayoung | all HTTP gives you is 401/403 | 17:56 |
| ayoung | HTTP confuses authentication with authorization in its responses | 17:56 |
| johnthetubaguy | I really don't see why end users need to know about policy | 17:56 |
| dstanek | ayoung: that's not the issue i'm arguing | 17:56 |
| ayoung | johnthetubaguy, really? | 17:56 |
| johnthetubaguy | well 401 is bad token, 403 is token not good enough I thought | 17:56 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Remove unnecessary processing when deleting grant. https://review.openstack.org/450938 | 17:57 |
| ayoung | dstanek, it was one of the design considerations, though | 17:57 |
| johnthetubaguy | ayoung: see comments on your spec, tried to describe why I think that | 17:57 |
| ayoung | johnthetubaguy, delegation | 17:57 |
| ayoung | that is what we don't do now | 17:57 |
| ayoung | let me give you a scenario | 17:57 |
| johnthetubaguy | so its 7pm here now | 17:57 |
| ayoung | say some group at my company is hosting a Trove server | 17:57 |
| ayoung | johnthetubaguy, and I have to get kids in 10 minutes | 17:58 |
| ayoung | I'm almost done | 17:58 |
| ayoung | say some group at my company is hosting a Trove server | 17:58 |
| johnthetubaguy | I get the delgation case | 17:58 |
| ayoung | and you, as the cloud admin, want to use it | 17:58 |
| johnthetubaguy | I just see it as an operator concern | 17:58 |
| ayoung | nope | 17:58 |
| ayoung | operator may not be around | 17:58 |
| ayoung | it is a third party resource | 17:58 |
| ayoung | just like when we go to launchpad prior to hitting gerrit | 17:58 |
| ayoung | the Ubuntu operators are not part of the mix there | 17:59 |
| ayoung | same deal here | 17:59 |
| ayoung | oauth kindof nods at the way to do this | 17:59 |
| dstanek | ayoung: we can talk more about authz and rest....but i really don't like doing this stuff based on the URL | 18:00 |
| ayoung | I want access to a remote service. I go to that service, and it kicks back an oauth response that says "you need to delegate X,T,Q, and P to do that" | 18:00 |
| *** mvk has joined #openstack-keystone | 18:00 | |
| ayoung | dstanek, same response I give anyone: give me a better alternative | 18:00 |
| ayoung | I'm 100% willing to change my mind to back something better | 18:00 |
| dstanek | ayoung: why not operation...like we do now...or like aws does in policy | 18:00 |
| johnthetubaguy | dstanek: I am fine with using URLs really, I just think either way it needs to be described to the operators | 18:00 |
| johnthetubaguy | dstanek: azure does like AD style URLs for similar things, which is another theme and variation I get | 18:01 |
| johnthetubaguy | to me its just a name with a meaning | 18:01 |
| johnthetubaguy | url is a structure name that helps people guess better if they know the API, but meh, its a name | 18:01 |
| dstanek | as soon as you commit to url then you'll have to make sure urls don't do multiple operations or educate operators on exactly how things are implemented | 18:01 |
| dstanek | seems like a waste | 18:01 |
| johnthetubaguy | dstanek: my main worry about URLs is alias points and things, again I added comments on the spec about some of the limitations that need to be defined, it seems workable though | 18:02 |
| ayoung | dstanek, don't just say "no" you have to say "instead do this..." | 18:03 |
| dolphm | and multiple API versions inherently require multiple rules? | 18:03 |
| johnthetubaguy | ayoung: he said stick with abstract defined names like we have today | 18:03 |
| dstanek | hypothetical....if a call to backup a DB can optionally push that backup to swift. do you have to have crazy rules? | 18:03 |
| lbragstad | dolphm yeah | 18:03 |
| dstanek | dolphm: i think the current proposal is yes | 18:03 |
| ayoung | johnthetubaguy, those are useless as I pointed out | 18:03 |
| johnthetubaguy | ayoung: so I was expecting to use capabilities to do delegation I think | 18:03 |
| lbragstad | or even if the same api version supports two ways to do something | 18:04 |
| dolphm | ayoung: from a user perspective, if I get a 401 with "you didn't match a policy rule called compute:boot_vm, even though you have roles X, Y, and Z in project ABC" then that would give me enough to "debug" the situation | 18:04 |
| dstanek | lbragstad: right. operators have to know the implementation details now | 18:04 |
| johnthetubaguy | ayoung: so are URLs really, you need to enumerate the options and special codes, and what they all mean | 18:04 |
| ayoung | dolphm, you should not have to perform a destructive operation to figure that out | 18:04 |
| johnthetubaguy | dstanek: you seen how this is looking now? https://docs.openstack.org/developer/nova/sample_policy.html | 18:04 |
| ayoung | what if you don't want to delete the VM, just figure out how to do that later? | 18:05 |
| ayoung | or image | 18:05 |
| ayoung | or whatever | 18:05 |
| lbragstad | again - that seems like auditing | 18:05 |
| lbragstad | to a certain extent | 18:05 |
| dstanek | johnthetubaguy: yeah, we've been moving that way in keystone too. definitely not a fan. | 18:05 |
| johnthetubaguy | dstanek: its just stopping folks from having to read the code though right? | 18:06 |
| lbragstad | johnthetubaguy i think it is | 18:06 |
| lbragstad | johnthetubaguy the operators i've visited with were asking for that kind of information | 18:06 |
| johnthetubaguy | dstanek: doesn't change we have codes for each check point | 18:06 |
| dstanek | johnthetubaguy: i think, but it starts to officially propogate the need to understand URLs | 18:06 |
| dolphm | ayoung: sorry, a destructive operation? like delete VM? (what are you destroying?) | 18:06 |
| ayoung | dolphm, anything that changes state | 18:07 |
| ayoung | update | 18:07 |
| ayoung | delete | 18:07 |
| lbragstad | dolphm using the an operation to determine *if* you can do something | 18:07 |
| dstanek | dolphm: i think he is saying that he wants something to query to see if you can do it without trying | 18:07 |
| ayoung | If I want to create a delegation agreement, or if Horizon wants to tell me I can delete somehing, it should not have to call DELETE (thing) to find out that I can | 18:07 |
| dstanek | that's what i thought the capabilities API was going to be | 18:07 |
| lbragstad | (when you might not actually want to do it, just know if you can do it) is ayoung's case | 18:07 |
| dolphm | oh, sure. i'm just saying we could be providing more user feedback today without risking security | 18:07 |
| johnthetubaguy | dstanek: so you have to understand the REST API to work out how to understand what you need to restrict, so I was having understand the REST API (or knowing the URL of the api-ref) as required for any operator working with policy | 18:07 |
| dolphm | i'd like to be able to have JSON-Home respect by authorization, as well | 18:08 |
| dstanek | first a way to see all the things and then grow into using policy to tell you if you can perform some action on some resource | 18:08 |
| johnthetubaguy | dstanek: right capabilities is what I see as the end user thing, not the policy rules | 18:08 |
| dstanek | johnthetubaguy: why is that the case. that's what i don't understand. | 18:08 |
| johnthetubaguy | you would do delegation on the capabilities, I assumed, I think I assumed that | 18:08 |
| lbragstad | yeah - because service configuration needs to get worked into that answer as well... it's not strictly RBAC | 18:08 |
| dstanek | johnthetubaguy: when i make policy for AWS I have no idea what the URLs are. | 18:09 |
| dstanek | johnthetubaguy: for desktop software i can't tell you what C function is called and what DLL/SO it comes from | 18:09 |
| ayoung | dstanek, URLs are the main tools of REST. We can make something on top of that to improve the user expereince | 18:09 |
| ayoung | the CLI and the clients know what URLS they are going to call | 18:09 |
| ayoung | it does not have to show up as an URL to the end user, just that is the remote contract | 18:10 |
| dstanek | ayoung: sorta....but nobody should know about all of the URLs. that is not REST. that's just a HTTP API | 18:10 |
| johnthetubaguy | dstanek: thats why we included the text descriptions, the URLs are just extra help if you know the URLs from reading the logs, etc | 18:10 |
| dstanek | a REST client should only have 1 or a small few entrypoints into an API... the rest must be discovery | 18:10 |
| ayoung | dstanek, as I said, there is not really a RESTful way to do this | 18:10 |
| dstanek | we are soooo close on a lot of it | 18:10 |
| ayoung | there is not a verb for "show me what I can do" | 18:11 |
| ayoung | HEAD might be the closest | 18:11 |
| dstanek | ayoung: i don't see why not | 18:11 |
| ayoung | dstanek, take it up with Sir Berniers-Lee | 18:11 |
| dstanek | ayoung: i don't understand what you can't do. | 18:12 |
| ayoung | dstanek, I can't discover what Roles I need in order to perform an operation prior to performing it | 18:12 |
| dstanek | so you get a 4XX. we can put what you need to access it in the body if we want. we can provide an api to query for capabilities | 18:12 |
| dolphm | ayoung: Accept: "application/json-home" | 18:12 |
| dstanek | ayoung: only because we haven't made the API for that yet | 18:13 |
| *** stradling has quit IRC | 18:13 | |
| dolphm | dstanek: we have it, it's just not dynamic | 18:13 |
| dstanek | dolphm: ++ | 18:13 |
| ayoung | dstanek, please don't ask me to boil the ocean. All I want is a cup of coffee | 18:13 |
| johnthetubaguy | so I need to go eat and sleep... seems capabilities and delegation is the sticking point in the wider discussion here | 18:14 |
| lbragstad | dolphm dstanek which api is that? | 18:14 |
| ayoung | dstanek, in FreeIPA, I had a wonderful API for finding all this stuff out, down to the ability to read/write/list individual properties of objects. But it was not standard LDAP, either | 18:14 |
| dolphm | lbragstad: GET / ... Accept: application/json-home | 18:15 |
| dolphm | lbragstad: returns you the list of available API operations | 18:15 |
| dstanek | ayoung: there are lots of was to do this that are not terribly hard and sticks to a REST api | 18:15 |
| lbragstad | oh - got it | 18:15 |
| dolphm | all it has to do is respect policy | 18:15 |
| ayoung | dstanek, now go and implement them all, evenly, across all of the openstack services, including ones that use keystone but are not under the big tent | 18:16 |
| ayoung | dolphm, wy dont' we have that on /v3? | 18:17 |
| dstanek | ayoung: to me that's not an argument to move away from our design principles. | 18:17 |
| ayoung | dstanek, 5 years with a broken system is my argument | 18:17 |
| ayoung | I can't solve it otherwise. | 18:17 |
| ayoung | and no one else seems to be trying | 18:17 |
| dolphm | ayoung: i believe you can query / /v2.0/ or /v3/ | 18:17 |
| dstanek | ayoung: there has been progress in uniformly wanting a capabilities API | 18:17 |
| ayoung | dolphm, right, but/v4 does not have links to, say /v3/user /v3/groups etc | 18:18 |
| dolphm | dstanek: what's the difference between a capabilities API and json-home? | 18:18 |
| *** lucasxu has joined #openstack-keystone | 18:18 | |
| dolphm | ayoung: i hope not | 18:18 |
| ayoung | json-home is not very restful either | 18:18 |
| ayoung | dolphm why not? | 18:18 |
| dstanek | ayoung: why is json home not restful? | 18:18 |
| ayoung | dolphm, why doesn't v3 tell us the links to the objects further down in the the tree | 18:19 |
| dolphm | ayoung: if I ask a specific API version what it's capable of, then i would not expect an index of API operations on a different version | 18:19 |
| ayoung | dstanek, from / how do I get to json home? | 18:19 |
| dstanek | dolphm: i think primarily in adding the ability to narrow down capabilies or query for specific capabilites | 18:19 |
| dstanek | "can i delete VM 12345" | 18:19 |
| dolphm | ayoung: GET / "Accept: application/json-home" | 18:19 |
| ayoung | dolphm, no, I mean /v3/users | 18:19 |
| dstanek | ayoung: we need to use relationships and add links to things | 18:19 |
| lbragstad | IMO capabilities also factor in deployment configuration | 18:19 |
| dolphm | dstanek: wouldn't you be able to parse the json-home response for that information? | 18:19 |
| *** Aqsa has quit IRC | 18:20 | |
| dolphm | lbragstad: which json-home should do as well. if a piece of middleware is not loaded, it won't appear | 18:20 |
| ayoung | OK...so lets ignore the fact that all of us know keystone and could make *a* way to do this in Keystone | 18:20 |
| johnthetubaguy | dolphm: FWIW, nova ended up ditching json-home (and swagger) as it wouldn't let us express our API, mostly because of the very non-REST-ful bits of our API | 18:20 |
| dstanek | dolphm: i doubt that you would put all of that detail in the response everytime | 18:20 |
| lbragstad | so - i think a list of capabilities could possibly be a a subset of json-home information | 18:20 |
| ayoung | johnthetubaguy, like actions, right? | 18:20 |
| dolphm | johnthetubaguy: sounds like a problem you should be able to microversion your way out of, if microversions work :P | 18:20 |
| johnthetubaguy | ayoung: yep, all and all the other things we want to kill but can't | 18:20 |
| ayoung | POST server/{id}/actions is about as JSON RPC as you can get without actually doing JSON RPC | 18:21 |
| johnthetubaguy | dolphm: we could, but it would drive a bus over our usrs | 18:21 |
| ayoung | johnthetubaguy, so.. I didn't have an answer for that at first, but I think in a follow on spec, we could add support for a jq type path query. I posted that in m,y latest fversion of the spec | 18:21 |
| dstanek | johnthetubaguy: i thought that's what microversions did... | 18:21 |
| dolphm | johnthetubaguy: what are microversions for if not running over users? | 18:21 |
| lbragstad | closed; microversions are working as intended | 18:22 |
| lbragstad | :) | 18:22 |
| ayoung | johnthetubaguy, see the follow on work section here https://review.openstack.org/#/c/452198/4/specs/keystone/pike/role-check-from-middleware.rst | 18:22 |
| ayoung | OK, gotta ruin | 18:22 |
| ayoung | run | 18:22 |
| ayoung | ruin | 18:22 |
| ayoung | rune | 18:22 |
| *** ayoung is now known as ayoung_dadmode | 18:22 | |
| dstanek | the endorsements for microversion would look like "I still can't feel my toes" | 18:22 |
| johnthetubaguy | ayoung_dadmode: thats not a big worry for me, the big worries are in the comments | 18:23 |
| *** ayoung_dadmode has quit IRC | 18:23 | |
| johnthetubaguy | points at this blog: https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/ | 18:26 |
| * johnthetubaguy runs for food | 18:26 | |
| *** harlowja has quit IRC | 18:33 | |
| *** stradling has joined #openstack-keystone | 18:38 | |
| *** hoonetorg has quit IRC | 18:51 | |
| *** stradling has quit IRC | 19:10 | |
| *** pid1 has joined #openstack-keystone | 19:13 | |
| *** pid1 has left #openstack-keystone | 19:13 | |
| *** voelzmo has joined #openstack-keystone | 19:25 | |
| openstackgerrit | Gage Hugo proposed openstack/python-keystoneclient master: Remove pbr warnerrors in favor of sphinx check https://review.openstack.org/441468 | 19:33 |
| *** shuyingya has joined #openstack-keystone | 19:40 | |
| *** stradling has joined #openstack-keystone | 19:41 | |
| *** shuyingya has quit IRC | 19:45 | |
| *** aunnam has joined #openstack-keystone | 19:50 | |
| *** aunnam has left #openstack-keystone | 19:52 | |
| *** voelzmo has quit IRC | 19:53 | |
| *** harlowja has joined #openstack-keystone | 19:58 | |
| *** pcaruana has quit IRC | 20:01 | |
| *** aojea has joined #openstack-keystone | 20:11 | |
| *** jamielennox is now known as jamielennox|away | 20:12 | |
| smccully | @dstanek, were you able to take a look --> https://review.openstack.org/#/c/452585 | 20:22 |
| dstanek | smccully: no, but i can now | 20:25 |
| smccully | ok, thanks | 20:27 |
| antwash | samueldmq : replied to your question https://review.openstack.org/#/c/450938/ | 20:30 |
| openstackgerrit | Merged openstack/python-keystoneclient master: Updated from global requirements https://review.openstack.org/439355 | 20:30 |
| dstanek | smccully: so what currently happens if verify is True? no verification? | 20:34 |
| dstanek | or some builtin thing? | 20:35 |
| smccully | Currently when verify is True, Requests verifies the SSL Certificate against (apparently i learned this) some internal Requests CA Bundle | 20:37 |
| smccully | By explicitly setting the verify to a specefic CABundle.pem or CABundle Path containing the default OpenSSL system bundle, then the actual system bundle CA(s) are used to verify the SSL certificate | 20:38 |
| smccully | Using the system CABundle is at least in my opinion highly preferable, it was noted by @cmurphy that the Distro(s) actually patch python requests to use the System Bundle which works around this error when requests is installed from source or via pip | 20:40 |
| smccully | The problem as noted in the Bug report is that while perhaps even the overhwelming majority of the uses of keystoneauth the os-cacert option is explicitly read from configuration and passed, there are multiple points where it doesn't | 20:42 |
| smccully | The CLI commands being perhaps the most notable | 20:43 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystonemiddleware master: Updated from global requirements https://review.openstack.org/439318 | 20:45 |
| *** rcernin has quit IRC | 20:45 | |
| dstanek | smccully: ah, right i remember now | 20:46 |
| *** stradling has quit IRC | 20:47 | |
| *** thorst has quit IRC | 20:50 | |
| *** thorst has joined #openstack-keystone | 20:51 | |
| *** hoonetorg has joined #openstack-keystone | 20:53 | |
| *** thorst has quit IRC | 20:55 | |
| *** itisha has quit IRC | 21:12 | |
| *** thorst has joined #openstack-keystone | 21:18 | |
| dstanek | smccully: i'm only about halfway through that requests thread | 21:19 |
| dstanek | smccully: so how many projects don't properly allow a cert to be passed? | 21:22 |
| *** thorst has quit IRC | 21:22 | |
| *** spilla has quit IRC | 21:23 | |
| *** thorst has joined #openstack-keystone | 21:53 | |
| *** aojea has quit IRC | 21:53 | |
| *** catintheroof has quit IRC | 21:54 | |
| *** chris_hultin is now known as chris_hultin|AWA | 22:01 | |
| *** chlong has quit IRC | 22:02 | |
| smccully | @dstanek, I think its more of in certain cases, and I am not aware of all them I am sure. But the bug i submitted was Nova attaching a volume i.e. calling cinder | 22:04 |
| *** harlowja has quit IRC | 22:05 | |
| lbragstad | jamielennox|away would you be interested in giving https://review.openstack.org/#/c/452652/ a gander whenever you're available to do so? | 22:11 |
| *** thorst has quit IRC | 22:12 | |
| *** jamielennox|away is now known as jamielennox | 22:13 | |
| *** lucasxu has quit IRC | 22:15 | |
| *** edmondsw has quit IRC | 22:22 | |
| *** edmondsw has joined #openstack-keystone | 22:24 | |
| *** edmondsw has quit IRC | 22:29 | |
| *** agrebennikov has quit IRC | 22:41 | |
| samueldmq | antwash: hi | 22:48 |
| samueldmq | antwash: yes, I got that, but why did the exception changed ? | 22:48 |
| samueldmq | change* | 22:48 |
| *** RajPatel has joined #openstack-keystone | 22:57 | |
| *** thorst has joined #openstack-keystone | 22:59 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone-specs master: Access Keys https://review.openstack.org/450415 | 23:03 |
| *** thorst has quit IRC | 23:04 | |
| openstackgerrit | Ron De Rose proposed openstack/keystone-specs master: Access Keys https://review.openstack.org/450415 | 23:05 |
| *** adriant has joined #openstack-keystone | 23:06 | |
| antwash | samueldmq : since we're checking the role first, we never get a chance to make it to this method https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L85 -- which throws the RoleAssignmentNotFound exception | 23:06 |
| samueldmq | antwash: makes sense, thanks for clarifying | 23:06 |
| antwash | samueldmq : you're welcome sam | 23:07 |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Validate rolling upgrade is run in order https://review.openstack.org/437441 | 23:13 |
| openstackgerrit | Merged openstack/keystone master: Refactor test_revoke to call check_token directly https://review.openstack.org/451874 | 23:15 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move project endpoint to DocumentedRuleDefault https://review.openstack.org/449276 | 23:19 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move region policies to DocumentedRuleDefault https://review.openstack.org/449213 | 23:22 |
| *** lamt has quit IRC | 23:23 | |
| *** lamt has joined #openstack-keystone | 23:24 | |
| *** lamt has quit IRC | 23:24 | |
| *** RajPatel has quit IRC | 23:25 | |
| *** harlowja has joined #openstack-keystone | 23:25 | |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move trust to DocumentedRuleDefault https://review.openstack.org/449278 | 23:26 |
| openstackgerrit | Merged openstack/keystone master: Move and refactor test_by_domain_user https://review.openstack.org/452783 | 23:29 |
| openstackgerrit | Merged openstack/keystone master: Move and refactor test_by_domain_project https://review.openstack.org/452788 | 23:29 |
| openstackgerrit | Merged openstack/keystone master: Remove unnecessary processing when deleting grant. https://review.openstack.org/450938 | 23:29 |
| openstackgerrit | Merged openstack/keystone master: Move protocol to DocumentedRuleDefault https://review.openstack.org/449345 | 23:29 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move user policies to DocumentedRuleDefault https://review.openstack.org/449240 | 23:30 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move user policies to DocumentedRuleDefault https://review.openstack.org/449240 | 23:30 |
| openstackgerrit | Merged openstack/keystone master: Remove unused method _sample_data in test_revoke https://review.openstack.org/452772 | 23:30 |
| openstackgerrit | Merged openstack/keystone master: Add sem-ver flag so pbr generates correct version https://review.openstack.org/453420 | 23:30 |
| antwash | samueldmq: after the conversation earlier with morgan and stanek could you change this? https://review.openstack.org/#/c/449237/ | 23:34 |
| *** thorst has joined #openstack-keystone | 23:34 | |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move role assignment to DocumentedRuleDefault https://review.openstack.org/449253 | 23:35 |
| samueldmq | antwash: is the failure unrelated ? | 23:36 |
| samueldmq | antwash: I am taking another look just to make sure | 23:37 |
| antwash | samueldmq: not sure two 'Timeouts' and 1 'SnapshotNotFoundException' | 23:37 |
| antwash | samueldmq: I'll do a recheck and see what happens after you look | 23:38 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move mapping to DocumentedRuleDefault https://review.openstack.org/449341 | 23:40 |
| *** gagehugo has quit IRC | 23:42 | |
| *** jamielennox is now known as jamielennox|away | 23:42 | |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move access token to DocumentedRuleDefault https://review.openstack.org/449265 | 23:43 |
| *** gagehugo has joined #openstack-keystone | 23:43 | |
| samueldmq | antwash: couple more comments on https://review.openstack.org/#/c/449237 | 23:44 |
| *** jamielennox|away is now known as jamielennox | 23:45 | |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move consumer to DocumentedRuleDefault https://review.openstack.org/449269 | 23:46 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move consumer to DocumentedRuleDefault https://review.openstack.org/449269 | 23:46 |
| *** thorst has quit IRC | 23:49 | |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move endpoint group to DocumentedRuleDefault https://review.openstack.org/449273 | 23:54 |
| lbragstad | looks like the next PTG will be in Denver - http://lists.openstack.org/pipermail/openstack-dev/2017-April/115046.html | 23:56 |
| openstackgerrit | Anthony Washington proposed openstack/keystone master: Move role policies to DocumentedRuleDefault https://review.openstack.org/449251 | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!