| *** itlinux has joined #openstack-keystone | 00:03 | |
| ayoung | jamielennox, lets see, the ones I override are mostly keystone specific values that should not be used for policy on other services | 00:07 |
|---|---|---|
| ayoung | I'm cool with follow on work that cleans this up, though | 00:07 |
| ayoung | I want to get rid of common/authorization.py now, but in another patch | 00:07 |
| *** sticker_ is now known as sticker | 00:08 | |
| ayoung | On the Deprecated Values, I am guessing that I can append new values as opposed to passing them in the constructor, so, yeah, that should be cleaner | 00:08 |
| ayoung | jamielennox, for you next question... | 00:09 |
| ayoung | "Can't we create the context first and then just add the stuff we need after.?" I'd be fine with that | 00:09 |
| ayoung | it seems like that stuff is supposed to be passed in to the constructor, but I really Don't care. I do want to get that whole logic extracted out into a seperate function that we can test, as a replacement for authorization.py's token_to_auth_context | 00:10 |
| ayoung | But, this change allowed me to get this one to finally pass Tempest: https://review.openstack.org/#/c/257636/41 and that is what I really care about | 00:11 |
| *** thorst has joined #openstack-keystone | 00:16 | |
| *** thorst has quit IRC | 00:21 | |
| *** mancdaz has joined #openstack-keystone | 00:22 | |
| jamielennox | that's cool on the tempest front, i've no idea why it changes anything because it should be the same | 00:27 |
| jamielennox | so there's no reason things have to be passed to constructor, it's just built like that because from_environ works that way and everyone used to pass things to constructor | 00:28 |
| jamielennox | it's just an object you can set whatever you like, and i don't feel like there should need to be any switching logic on the constructor side, just add the values to the object that you need | 00:28 |
| jamielennox | re override, there shouldn't be anything we _override_ differently to what is already there - there's definitely stuff we need to add, but i just mean to reuse as much as the underlying as possible as it makes keystone less special | 00:29 |
| *** david-lyle has joined #openstack-keystone | 00:30 | |
| *** david-lyle has quit IRC | 00:31 | |
| *** david-lyle has joined #openstack-keystone | 00:31 | |
| ayoung | jamielennox, how about this: | 00:31 |
| ayoung | http://paste.openstack.org/show/628034/ | 00:32 |
| ayoung | On tempest, it defaults the is_admin_projects values. Which is what I want tested. But you are right, I could get it to pass without that. I had to pass an additioanl value to get tempest to pass: | 00:33 |
| ayoung | https://review.openstack.org/#/c/257636/42/keystone/middleware/auth.py | 00:33 |
| ayoung | and thati s just, I think, to keep from opening up a security hold | 00:34 |
| ayoung | hole | 00:34 |
| ayoung | as for the values handled by __init__ I'd like to minimize this patch, and clean up existing behaviour in a future patch, if that is OK. Trying to keep this reviewable, and already it asks for some deep understanding on the part of the reviewer | 00:36 |
| *** jmlowe has joined #openstack-keystone | 00:47 | |
| *** thorst has joined #openstack-keystone | 00:52 | |
| jamielennox | ayoung: i am fine with keep it small | 00:54 |
| ayoung | ++ | 00:55 |
| jamielennox | strange that is_domain_scoped is a problem, why isn't is just a @property self.domain_id != None | 00:56 |
| *** thorst has quit IRC | 00:57 | |
| ayoung | jamielennox, so, the problem was origianally that the tempest tests used admin scoped to the default domain. I changed the Keystone policy to grandfather this in...but with out is_domain_scoped set, it will match any token's domain_id value, not just domain scoped. Perhaps I am being paranoid | 01:05 |
| ayoung | I know that at that point, it should be project_domain_id | 01:05 |
| openstackgerrit | ayoung proposed openstack/keystone master: Use oslo-context https://review.openstack.org/523650 | 01:08 |
| ayoung | jamielennox, how's that | 01:08 |
| jamielennox | lol where'd this come from: | 01:09 |
| jamielennox | self.user_id = kwargs.pop('user_id ', None) | 01:09 |
| jamielennox | self.project_id = kwargs.pop('project_id ', None) | 01:09 |
| jamielennox | self.user_domain_id = kwargs.pop('user_domain_id ', None) | 01:09 |
| jamielennox | self.project_domain_id = kwargs.pop('project_domain_id ', None) | 01:09 |
| jamielennox | there are spaces in those strings | 01:09 |
| jamielennox | (wasn't you) | 01:10 |
| jamielennox | but all that can just be removed | 01:10 |
| ayoung | Yep, And I acutally got messed up by that | 01:16 |
| ayoung | I think I git blamed it and found out it was you | 01:16 |
| ayoung | Nope, stanek | 01:17 |
| ayoung | so my patch is gonna fail... | 01:18 |
| ayoung | if I try to drop the group_ids thing | 01:18 |
| *** edmondsw has joined #openstack-keystone | 01:19 | |
| *** edmondsw has quit IRC | 01:24 | |
| *** annp has quit IRC | 01:27 | |
| *** thorst has joined #openstack-keystone | 01:27 | |
| *** thorst has quit IRC | 01:28 | |
| *** thorst has joined #openstack-keystone | 01:29 | |
| *** thorst has quit IRC | 01:30 | |
| *** jmlowe has quit IRC | 01:44 | |
| openstackgerrit | ayoung proposed openstack/keystone master: Use oslo-context https://review.openstack.org/523650 | 01:49 |
| *** gmann_afk is now known as gmann | 01:54 | |
| *** thorst has joined #openstack-keystone | 02:01 | |
| *** thorst has quit IRC | 02:06 | |
| *** thorst has joined #openstack-keystone | 02:10 | |
| *** thorst has quit IRC | 02:14 | |
| openstackgerrit | ayoung proposed openstack/keystone master: Use oslo-context https://review.openstack.org/523650 | 02:19 |
| openstackgerrit | ayoung proposed openstack/keystone master: Add is_admin_project check to policy for non scoped operations https://review.openstack.org/257636 | 02:19 |
| openstackgerrit | ayoung proposed openstack/keystone master: Add is_admin_project check to policy for token validations https://review.openstack.org/520845 | 02:27 |
| *** daidv has joined #openstack-keystone | 02:28 | |
| openstackgerrit | Adrian Turjak proposed openstack/keystone master: Make name fields a consistent size of 255 https://review.openstack.org/440941 | 02:45 |
| *** edmondsw has joined #openstack-keystone | 03:07 | |
| *** edmondsw has quit IRC | 03:12 | |
| *** prashkre has joined #openstack-keystone | 03:15 | |
| *** thorst has joined #openstack-keystone | 03:17 | |
| *** thorst has quit IRC | 03:22 | |
| *** itlinux has quit IRC | 03:32 | |
| *** edmondsw has joined #openstack-keystone | 03:32 | |
| *** edmondsw has quit IRC | 03:36 | |
| *** thorst has joined #openstack-keystone | 03:57 | |
| *** thorst has quit IRC | 04:02 | |
| *** annp has joined #openstack-keystone | 04:10 | |
| *** links has joined #openstack-keystone | 04:13 | |
| *** jmlowe has joined #openstack-keystone | 04:17 | |
| openstackgerrit | Adrian Turjak proposed openstack/keystone master: Make name fields a consistent size of 255 https://review.openstack.org/440941 | 04:19 |
| *** ricolin has joined #openstack-keystone | 04:21 | |
| *** swain has joined #openstack-keystone | 04:23 | |
| openstackgerrit | Adrian Turjak proposed openstack/keystone master: Make name fields a consistent size of 255 https://review.openstack.org/440941 | 04:26 |
| *** thorst has joined #openstack-keystone | 04:37 | |
| *** itlinux has joined #openstack-keystone | 04:39 | |
| *** thorst has quit IRC | 04:41 | |
| *** edmondsw has joined #openstack-keystone | 04:58 | |
| *** jmlowe has quit IRC | 05:02 | |
| *** edmondsw has quit IRC | 05:03 | |
| *** thorst has joined #openstack-keystone | 05:10 | |
| *** thorst has quit IRC | 05:15 | |
| *** prashkre has quit IRC | 05:15 | |
| *** jaosorior has joined #openstack-keystone | 05:16 | |
| *** jmlowe has joined #openstack-keystone | 05:24 | |
| *** itlinux has quit IRC | 05:28 | |
| *** jmlowe has quit IRC | 05:28 | |
| *** zhurong has joined #openstack-keystone | 05:31 | |
| *** andymccr has quit IRC | 05:32 | |
| *** andymccr has joined #openstack-keystone | 05:33 | |
| *** cloudnull has quit IRC | 05:33 | |
| *** thorst has joined #openstack-keystone | 05:37 | |
| *** cloudnull has joined #openstack-keystone | 05:41 | |
| *** thorst has quit IRC | 05:42 | |
| *** thorst has joined #openstack-keystone | 05:45 | |
| *** thorst has quit IRC | 05:50 | |
| *** clarkb has quit IRC | 06:02 | |
| *** sticker_ has joined #openstack-keystone | 06:10 | |
| *** sticker has quit IRC | 06:13 | |
| *** sticker_ has quit IRC | 06:14 | |
| *** thorst has joined #openstack-keystone | 06:24 | |
| *** thorst has quit IRC | 06:29 | |
| *** swain has quit IRC | 06:32 | |
| *** clarkb has joined #openstack-keystone | 06:33 | |
| *** edmondsw has joined #openstack-keystone | 06:46 | |
| *** edmondsw has quit IRC | 06:51 | |
| *** prashkre has joined #openstack-keystone | 06:55 | |
| *** thorst has joined #openstack-keystone | 06:57 | |
| *** zhurong has quit IRC | 06:57 | |
| *** thorst has quit IRC | 07:01 | |
| *** zhurong has joined #openstack-keystone | 07:20 | |
| *** thorst has joined #openstack-keystone | 07:36 | |
| *** thorst has quit IRC | 07:41 | |
| *** rcernin has quit IRC | 07:49 | |
| openstackgerrit | wangxiyuan proposed openstack/keystone master: Correct error message for request token https://review.openstack.org/525088 | 08:04 |
| *** tesseract has joined #openstack-keystone | 08:13 | |
| *** prashkre has quit IRC | 08:13 | |
| *** AlexeyAbashkin has joined #openstack-keystone | 08:16 | |
| *** zhurong has quit IRC | 08:20 | |
| *** pcaruana has joined #openstack-keystone | 08:23 | |
| *** prashkre has joined #openstack-keystone | 08:30 | |
| *** magicboiz has joined #openstack-keystone | 08:33 | |
| *** edmondsw has joined #openstack-keystone | 08:35 | |
| *** rcernin has joined #openstack-keystone | 08:35 | |
| *** magicboiz has quit IRC | 08:37 | |
| *** edmondsw has quit IRC | 08:40 | |
| *** magicboiz has joined #openstack-keystone | 08:42 | |
| *** magicboiz has quit IRC | 08:47 | |
| *** magicboiz has joined #openstack-keystone | 08:47 | |
| *** zhurong has joined #openstack-keystone | 09:03 | |
| *** mvk has joined #openstack-keystone | 09:05 | |
| *** Guest13268 is now known as zigo | 09:09 | |
| *** aloga has quit IRC | 09:21 | |
| *** aloga has joined #openstack-keystone | 09:22 | |
| openstackgerrit | Merged openstack/ldappool master: Avoid tox_install.sh for constraints support https://review.openstack.org/524797 | 09:44 |
| *** zhurong has quit IRC | 10:26 | |
| *** annp has quit IRC | 10:33 | |
| *** mvk has quit IRC | 10:40 | |
| *** gmann is now known as gmann_afk | 10:52 | |
| *** mvk has joined #openstack-keystone | 11:09 | |
| *** prashkre has quit IRC | 11:49 | |
| *** raildo has joined #openstack-keystone | 11:51 | |
| *** edmondsw has joined #openstack-keystone | 12:11 | |
| *** avi_ has quit IRC | 12:13 | |
| *** edmondsw has quit IRC | 12:16 | |
| *** rcernin has quit IRC | 12:31 | |
| *** links has quit IRC | 12:54 | |
| *** edmondsw has joined #openstack-keystone | 13:23 | |
| *** links has joined #openstack-keystone | 13:31 | |
| *** edmondsw has quit IRC | 13:43 | |
| *** panbalag has joined #openstack-keystone | 13:48 | |
| *** itlinux has joined #openstack-keystone | 13:50 | |
| *** thorst has joined #openstack-keystone | 13:59 | |
| *** jmccarthy has joined #openstack-keystone | 14:12 | |
| jmccarthy | Any suggestions to help determine why I seem to have this issue with a missing endpoint ? http://paste.openstack.org/show/628081/ | 14:13 |
| *** spilla has joined #openstack-keystone | 14:30 | |
| lbragstad | hrybacki: not sure if you've seen this yet - http://postfacto-shutdown.helpscoutdocs.com/ | 14:35 |
| *** thorst has quit IRC | 14:46 | |
| *** thorst has joined #openstack-keystone | 14:48 | |
| *** thorst has quit IRC | 15:03 | |
| *** links has quit IRC | 15:10 | |
| *** jsheeren has joined #openstack-keystone | 15:12 | |
| *** phalmos has joined #openstack-keystone | 15:12 | |
| jsheeren | hi all, what's the easiest way to configure keystone to accept requests on eg openstack.com AND openstack.net | 15:12 |
| *** edmondsw has joined #openstack-keystone | 15:13 | |
| *** jmccarthy has left #openstack-keystone | 15:17 | |
| *** edmondsw has quit IRC | 15:18 | |
| *** AlexeyAbashkin has quit IRC | 15:20 | |
| *** phalmos has quit IRC | 15:22 | |
| *** thorst has joined #openstack-keystone | 15:24 | |
| *** itlinux has quit IRC | 15:26 | |
| openstackgerrit | ayoung proposed openstack/keystone master: Enforce policy on oslo-context https://review.openstack.org/523650 | 15:28 |
| *** thorst has quit IRC | 15:29 | |
| hrybacki | lbragstad: ack, we knew it was coming fortunately | 15:31 |
| lbragstad | hrybacki: last we talked, did we want to use trello? | 15:32 |
| lbragstad | hrybacki: also - do we want to go through the existing board before it goes away? | 15:32 |
| hrybacki | lbragstad: ack. Use Trello until we switch to story board | 15:32 |
| lbragstad | ok | 15:32 |
| hrybacki | lbragstad: yes, we should do that tomorrow if you have time? | 15:33 |
| lbragstad | damn - https://postfacto.io/retros/openstack-keystone | 15:33 |
| lbragstad | they already turned the lights off | 15:33 |
| hrybacki | Ah hmm. Well, we did a good job of making sure we didn't drop anything from the ptg retro which was the most important so far | 15:34 |
| cmurphy | jsheeren: it depends on what you mean, if I interpret your question correctly you can just point your DNS A or CNAME records to wherever your keystone is, but that's not really a keystone question so maybe you mean something else | 15:36 |
| jsheeren | cmurphy, yes, i meam something else. the catalog points to openstack.com; how can i make it that when a user requests the catalog at openstack.net it shows the endpoints on openstack.net and not openstack.com | 15:40 |
| jsheeren | dns is all good and such, but if the endpoints configured in keystone still refer to openstack.com .. | 15:41 |
| *** phalmos has joined #openstack-keystone | 15:43 | |
| jsheeren | maybe i need to look into something like this? http://serverascode.com/2017/08/28/clean-keystone-urls.html | 15:46 |
| breton | jsheeren: so you have 2 domains pointing to the same keystone and you want keystone to return different urls depending on which domain you make a query to? | 15:51 |
| jsheeren | breton, yes, thank you for rephrasing my question to something that's better :) | 15:52 |
| jsheeren | is it possible though? | 15:52 |
| breton | jsheeren: The urls in the catalog are static and cannot be computed | 15:53 |
| breton | jsheeren: so without magic i think no | 15:55 |
| jsheeren | ah :( | 15:55 |
| jsheeren | thanks anyway! i'll look into magic then :) | 15:55 |
| *** jsheeren has quit IRC | 15:55 | |
| breton | jsheeren: theoretically you can invent some magic with 2 instances of keystone | 15:56 |
| breton | but... | 15:56 |
| breton | i wanted to describe the magic | 15:56 |
| breton | but he quit | 15:56 |
| breton | :( | 15:56 |
| *** david-lyle has quit IRC | 15:58 | |
| *** david-lyle has joined #openstack-keystone | 15:59 | |
| mordred | cmurphy: "Could we do the same thing for keystonemiddleware?" ... absolutely - and certainly shold | 16:23 |
| cmurphy | mordred: cool | 16:26 |
| *** edmondsw has joined #openstack-keystone | 16:26 | |
| *** thorst has joined #openstack-keystone | 16:28 | |
| *** itlinux has joined #openstack-keystone | 16:31 | |
| *** thorst has quit IRC | 16:33 | |
| lbragstad | keystone retrospective board is up and ready for input | 16:37 |
| lbragstad | https://trello.com/b/jrpmDKtf/keystone-retrospective | 16:37 |
| lbragstad | if you don't have the ability to add things, please ping me and i'll send you an invite | 16:37 |
| lbragstad | (it should be open to the public to view) | 16:37 |
| *** gyee has joined #openstack-keystone | 16:43 | |
| * cmurphy wonders where kmalloc is | 16:43 | |
| cmurphy | i want his eyes on https://review.openstack.org/#/c/440941/ | 16:43 |
| *** mvk has quit IRC | 16:44 | |
| *** itlinux has quit IRC | 16:46 | |
| lbragstad | cmurphy: responded | 16:48 |
| lbragstad | i remember talking about that in sydney | 16:48 |
| cmurphy | lbragstad: hmm interesting | 16:49 |
| *** itlinux has joined #openstack-keystone | 16:50 | |
| *** ricolin has quit IRC | 16:53 | |
| knikolla | o/ | 16:59 |
| *** kmalloc has joined #openstack-keystone | 17:01 | |
| *** panbalag has quit IRC | 17:02 | |
| *** thorst has joined #openstack-keystone | 17:02 | |
| * kmalloc yawns | 17:08 | |
| cmurphy | kmalloc: hi o/ | 17:08 |
| cmurphy | kmalloc: i was hoping you could look at https://review.openstack.org/#/c/440941/ I think it breaks the api :/ | 17:09 |
| kmalloc | looking | 17:10 |
| kmalloc | so, this does break our api contract, in so much as that someone who was relying on some names being 64 (lets say for CRM integrations) could potentially now fail | 17:12 |
| kmalloc | not that anyone should rely on names | 17:12 |
| kmalloc | but... | 17:12 |
| kmalloc | This one is not as big a break as some, but it changes API behavior and therefore breaks the contract. | 17:12 |
| kmalloc | second, it could really break anyone who has custom identity backends | 17:13 |
| kmalloc | since they may not support > 64 characters (bytes?) for these fields. | 17:13 |
| kmalloc | i'm going to -2 it. until lbragstad or more cores say we need this. | 17:13 |
| cmurphy | on the identity backends do we explicitly guarantee non-breakage? we removed all that driver version stuff and we've definitely had interface changes in those since then | 17:15 |
| kmalloc | cmurphy: we do not, but we also typically do not change column sizes because of E_NO_DOWNTIME_UPGRADES | 17:17 |
| kmalloc | we typically add new columns, which could be much easier to deal with from a custom backend standpoint | 17:17 |
| kmalloc | since you're not "changing a data type" | 17:17 |
| *** panbalag has joined #openstack-keystone | 17:17 | |
| cmurphy | right | 17:17 |
| cmurphy | well adriant ^ i wonder if there's something else we could do to solve your use case | 17:19 |
| kmalloc | added my comment re no-downtime upgrades as well to my -2. | 17:20 |
| kmalloc | i am 100% ok reversing course on the -2 if cores/ptl say we need this. | 17:20 |
| *** tesseract has quit IRC | 17:20 | |
| cmurphy | i was on the fence about it which is why i asked you :) | 17:21 |
| kmalloc | cmurphy: :) I appreciate being asked - it's always better to get extra eyes on something if you're on the fence ^_^ | 17:23 |
| kmalloc | i need to revisit: https://review.openstack.org/#/c/499703/ | 17:23 |
| kmalloc | it would make our code SO much easier to read/ | 17:23 |
| *** magicboiz has quit IRC | 17:24 | |
| kmalloc | hmm. where did I stick that laptop. i can't write this on the desktop atm. it's being ... wonky. | 17:27 |
| *** mvk has joined #openstack-keystone | 17:30 | |
| openstackgerrit | ayoung proposed openstack/keystone master: Add is_admin_project check to policy for non scoped operations https://review.openstack.org/257636 | 17:34 |
| *** magicboiz has joined #openstack-keystone | 17:36 | |
| *** thorst_ has joined #openstack-keystone | 17:41 | |
| *** notmyname has joined #openstack-keystone | 17:41 | |
| notmyname | I though you should see this ;-) | 17:42 |
| notmyname | https://twitter.com/THEREALMRSAZON/status/934134558865453056 | 17:42 |
| kmalloc | LOL | 17:42 |
| kmalloc | oh man. | 17:44 |
| *** thorst has quit IRC | 17:44 | |
| kmalloc | that's good :P | 17:44 |
| *** magicboiz has quit IRC | 17:44 | |
| notmyname | I'm not even exactly sure how to comment on it | 17:44 |
| notmyname | but I'm sure it includes the illuminati, flat earth, and particular metal headwear | 17:44 |
| notmyname | and, of course, keystone being at the center of it all | 17:45 |
| notmyname | :-) | 17:45 |
| kmalloc | clearly. | 17:48 |
| *** magicboiz has joined #openstack-keystone | 17:50 | |
| cmurphy | wow | 17:51 |
| *** thorst_ has quit IRC | 17:51 | |
| kmalloc | I, I kindof want to make an image of it and make that keystone's new mascot :P | 17:52 |
| *** aselius has joined #openstack-keystone | 17:55 | |
| *** thorst has joined #openstack-keystone | 18:02 | |
| lbragstad | .. what... | 18:02 |
| lbragstad | in the world.... | 18:02 |
| lbragstad | lol - we don't quite know what a CERN is, but CERN! | 18:03 |
| lbragstad | that reminds me, we should totally update our wiki page | 18:06 |
| *** thorst has quit IRC | 18:07 | |
| ayoung | cmurphy, thansk for the review on https://review.openstack.org/#/c/523650/ oslo-context. I was able to limit my changes to just the middleware file, should make it a little easier for others to review. | 18:09 |
| ayoung | And, of course, I need it for the one I really care about: https://review.openstack.org/#/c/257636/ | 18:09 |
| ayoung | lbragstad, so...assuming we can get the oslo-context fix in, and I have not broken anything in the rebase, I have a working is_admin_project fix for Keystone, finally. | 18:13 |
| ayoung | The one thing I need guidance on is how to deal with Tempest | 18:13 |
| lbragstad | i still need to review it | 18:13 |
| ayoung | right now, tempest uses a token with admin role scoped to the default domain | 18:13 |
| ayoung | I grandfathered that in | 18:13 |
| ayoung | its not ideal, but its Okish | 18:14 |
| ayoung | oslo-context patch is going to need a little follow up for code removal, too | 18:14 |
| ayoung | I think common/authorization.py can pretty much go away, with anything left merging into common/context.py | 18:15 |
| *** thorst has joined #openstack-keystone | 18:15 | |
| ayoung | so, if we could have the discussion about domain_id:default, role:admin sooner, it will let me move ahead | 18:16 |
| ayoung | kmalloc, lbragstad any preferences? | 18:16 |
| lbragstad | i think my biggest concern is keeping all the is_admin_project bits abstracted away into oslo.context or oslo.policy | 18:17 |
| lbragstad | instead of having it permeate into various policy files and whatnot | 18:18 |
| *** thorst has quit IRC | 18:20 | |
| ayoung | lbragstad, so you want a single rule that can be encapuslated in oslo policy? | 18:23 |
| ayoung | lbragstad, I kinda want that too. What would it look like? | 18:23 |
| lbragstad | ayoung: i worry about landing all this stuff and then having to re-teach people about system scope | 18:23 |
| lbragstad | if there is an opportunity to abstract that into something we can do for them, that might make that whole interaction easier | 18:24 |
| *** thorst has joined #openstack-keystone | 18:24 | |
| lbragstad | because we'll also have to think about deployments moving from is_admin_project to system scope eventually | 18:25 |
| ayoung | lbragstad, like instead of a policy rule: role:admin and is_admin_project: True (or domain_id: default and is_domain_scoped: True) we had a magic rule like oslo-context_admin:True? | 18:25 |
| lbragstad | ayoung: maybe we can make it even more generic | 18:25 |
| lbragstad | what if you just map it to 'system'? | 18:26 |
| *** panbalag has quit IRC | 18:26 | |
| ayoung | system: admin | 18:26 |
| lbragstad | technically, isn't that what is_admin_project signifies? | 18:26 |
| lbragstad | a system-level operation? | 18:26 |
| openstackgerrit | Merged openstack/keystone master: Assert default project id is not domain https://review.openstack.org/484235 | 18:26 |
| lbragstad | what if i have a reader role on the is_admin_project? | 18:28 |
| lbragstad | (it's not really an admin role, but it does let me view all system-level things in the deployment) | 18:28 |
| ayoung | lbragstad, so how about this: I modify my patch to have a single rule:systemrole_admin which calculates it. That lets me get it in to Keystone. Then, I'll modify the nova one to do the same thing. At the same time, we can start working through the oslo-context code to abstract that way. Once Oslo has it, it will be a one line change in the policy code, from rule:... to system_role: | 18:29 |
| lbragstad | system_role? | 18:30 |
| ayoung | I kindof wanted to introduct that rule in this patch anyway, so this is good justification for doing that | 18:30 |
| ayoung | systemrole:? however you want to format it. | 18:30 |
| lbragstad | we can actually do that with this - https://review.openstack.org/#/c/510222/ | 18:30 |
| lbragstad | which allows you to associate scope (e.g. system, project) to policies | 18:31 |
| lbragstad | so it shouldn't need to be in the name | 18:31 |
| lbragstad | if that makes sense | 18:31 |
| lbragstad | instead it is an immutable attribute of the policy object | 18:31 |
| lbragstad | which can be inspected at enforcement time | 18:31 |
| ayoung | lbragstad, i think I liked it better when the solution was encapuslated inside of oslo-context | 18:32 |
| ayoung | oslo.policy should really drop the role: rule, as it is the only thing that it does that is not generic | 18:32 |
| lbragstad | oslo.policy is just making the rule objects more flexible so that operations know what level they are suppose to run at | 18:33 |
| ayoung | oh, I am ok with collections, which is what role: is. We just don't need a one off there | 18:33 |
| ayoung | but policy can't deal with nesting, which is what I think makes your patch tricky | 18:34 |
| ayoung | really we want role: system.admin or role: domain.admin | 18:35 |
| lbragstad | that patch gives you the ability to say rule = policy.DocumentedRuleDefault(name='identity:create_endpoint', ..., scope_types=['system']) | 18:35 |
| lbragstad | then the only thing you need in a policy file is the role | 18:36 |
| lbragstad | it helps remove the role scope check from policy.json | 18:36 |
| lbragstad | and encodes it into the operation | 18:36 |
| ayoung | I think we are using the term scope check to mean two things, which might get confusing | 18:37 |
| *** thorst has quit IRC | 18:38 | |
| ayoung | until today, when we talked scope check, we meant "does the resourece.projectID == token.project.id" | 18:38 |
| lbragstad | yes - sorry, i'm referring to something slightly different | 18:38 |
| ayoung | but we didn't have to deal with domain vs project scoping ofr the role assignments | 18:38 |
| lbragstad | right - which is a scope check of the role assignment | 18:38 |
| * lbragstad is ultra confused now | 18:39 | |
| lbragstad | it's comparing the role assignment's scope to the intended scope of the operation being done | 18:39 |
| lbragstad | which is a bit different than the scope check we've previously talked about, and that is typically all on the service to do | 18:39 |
| lbragstad | (because it has to inspect information about the thing being acted on, and keystone don't know/shouldn't know any of that information) | 18:40 |
| *** panbalag has joined #openstack-keystone | 18:41 | |
| *** thorst has joined #openstack-keystone | 18:41 | |
| *** panbalag has left #openstack-keystone | 18:41 | |
| *** thorst has quit IRC | 18:43 | |
| ayoung | lbragstad, pretty sure you and I see things the same way, just worried about confusing people. Perhaps modify them: assignment scope versus resource scope? | 18:45 |
| lbragstad | ++ | 18:45 |
| ayoung | resource scope is almost always "do project ids match" | 18:45 |
| ayoung | except, of course in Keystone where we have some resources we manage via domain | 18:45 |
| ayoung | and now, with system scoping w have an implied resource scope match | 18:46 |
| lbragstad | assignment scope = is the role assignment made on the right target scope | 18:46 |
| ayoung | all VMs within Nova are withing the system scope, but in different projects | 18:46 |
| lbragstad | welll - i see that a bit differently | 18:46 |
| lbragstad | i view VMs as being completely project scoped | 18:46 |
| ayoung | OK, so, lets say we want to encapsulate this whole thing inside olso-context, so we don't need to go and modify every policy file every time | 18:47 |
| kmalloc | FWIW, I like the in-oslo.policy encapsulation | 18:47 |
| kmalloc | sorry, catching up on the convo now | 18:47 |
| ayoung | and, say we want to support is_admin_project today, and service_role as soon as it is ready | 18:47 |
| ayoung | kmalloc, fire away. THe sooner we have a consensus the faster we can actually fix things | 18:48 |
| ayoung | and I'm flexible, so long as the approach can be done in a reasonable amount of time | 18:48 |
| kmalloc | so | 18:49 |
| kmalloc | tl;dr, what lbragstad said. whatever we implement, as long as we don't need to re-teach system context/policies after | 18:50 |
| kmalloc | i'm behind it | 18:50 |
| ayoung | kmalloc, did you mean you want the encapsulation in oslo-context? Or did you really mean oslo-policy | 18:50 |
| kmalloc | ^^ simple answer, regardless of where it lands | 18:50 |
| openstackgerrit | Lance Bragstad proposed openstack/oslo.policy master: Add scope_types to RuleDefault objects https://review.openstack.org/510222 | 18:51 |
| lbragstad | so - IMO, it makes sense for oslo-context to maybe know about what scope the token being used in the request has | 18:53 |
| lbragstad | but it can also pass all that along to oslo.policy since oslo.policy has to know what scope the operation be made requires | 18:53 |
| ayoung | lbragstad, what would a policy fragment look like for system admin if https://review.openstack.org/#/c/510222 landed | 18:54 |
| lbragstad | ayoung: https://trello.com/c/C1INH5AI/7-define-default-roles | 18:54 |
| lbragstad | i attempted to write up what that would look like | 18:54 |
| lbragstad | the code snippets are super simple, and can be condensed, but i kept them in long form for readability | 18:55 |
| ayoung | so the scope type could never be specified in the policy file itself? | 18:55 |
| lbragstad | no | 18:55 |
| lbragstad | it should always be immutable | 18:55 |
| lbragstad | and never configurable in my opinion | 18:56 |
| lbragstad | when a service introduces a new api, they should evaluate at what layer that API interacts when the implement the policy for that API | 18:56 |
| lbragstad | (e.g. does this API operate on the system or project levels?) | 18:56 |
| lbragstad | i attempt to highlight that in the card | 18:58 |
| kmalloc | ++ | 18:58 |
| lbragstad | or specifically call it out in the examples | 18:58 |
| ayoung | lbragstad, 100% | 18:58 |
| ayoung | split the scope check from the role check | 18:58 |
| lbragstad | but also split the assignment check from the role check :) | 18:59 |
| ayoung | and make the services implement the scope check in code | 18:59 |
| ayoung | can you restate that in the terms we used above? | 18:59 |
| lbragstad | oslo.policy should be performing the role check and the assignment scope check | 18:59 |
| *** jmlowe has joined #openstack-keystone | 19:00 | |
| ayoung | sure...I'd call all of that the role check | 19:00 |
| lbragstad | yeah | 19:00 |
| lbragstad | but that should allow us to not have to have things like "nova_admin" or "nova_reader" roles | 19:00 |
| ayoung | What about overrides? Using a system scoped token to do project scoped operations? | 19:00 |
| lbragstad | that shouldn't be possible | 19:01 |
| lbragstad | (e.g. you can't create an instance with a system-scoped token) | 19:01 |
| ayoung | need to be able to do that. Its a hard requirement | 19:02 |
| lbragstad | because the system isn't really responsible for instances, projects are though | 19:02 |
| ayoung | lbragstad, I got caught on that one, too | 19:02 |
| lbragstad | that kinda defeats the whole purpose of system-scope | 19:02 |
| lbragstad | if it's for backwards compatibility | 19:02 |
| ayoung | administrators do not rescope to projects to do cross project work | 19:02 |
| ayoung | they demand a single token that will work multi-project | 19:03 |
| ayoung | I'd be OK with us dropping the role: admin for everything, and have more targetted roles: | 19:03 |
| ayoung | system: hypervisor vs system:helpdesk for example | 19:03 |
| ayoung | hypervisor can do things art rhe cell and hypervisore level, helpdesk can do project scoped operations anywhere | 19:04 |
| lbragstad | so - in that card, that is similar to the admin example i have | 19:07 |
| lbragstad | admin on the system can create new services, roll out new endpoints, etc... | 19:07 |
| lbragstad | admin on a project and manage all the instances in that projects, etc... | 19:08 |
| lbragstad | both are admin roles, but depending on what it is assigned to, you can do different things | 19:08 |
| lbragstad | s/admin roles/admin role assignments/ | 19:09 |
| ayoung | lets put a moratorium on the continued use of the role admin | 19:16 |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: Migrate jobs to zuulV3 https://review.openstack.org/523231 | 19:16 |
| ayoung | anything you are tempted to call admin, find a new name for it | 19:16 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Ensure building scope is mutually exclusive https://review.openstack.org/498091 | 19:19 |
| ayoung | lbragstad, walk me through how https://review.openstack.org/#/c/510222/ will work and I can +2 . tool | 19:32 |
| ayoung | too | 19:32 |
| ayoung | heh | 19:32 |
| lbragstad | ayoung: once that lands we will cut a new release of oslo.policy | 19:33 |
| ayoung | nah, walk me through the mechnaisms prior to that | 19:33 |
| ayoung | say we merged it today. | 19:33 |
| lbragstad | yeah | 19:34 |
| ayoung | What would that mean for Keystone and Nova | 19:34 |
| lbragstad | it would mean that we can do something like this | 19:34 |
| ayoung | The existing policy rules in common/policies would get modified? | 19:34 |
| lbragstad | http://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html#proposed-change | 19:34 |
| lbragstad | yes | 19:34 |
| ayoung | add in a polic_scope value for each one, | 19:34 |
| lbragstad | yeah | 19:34 |
| ayoung | so take my change here: | 19:34 |
| lbragstad | it's an optional attribute | 19:34 |
| ayoung | https://review.openstack.org/#/c/257636/ | 19:35 |
| ayoung | where I touched those files, those should all get policy_scope system | 19:35 |
| lbragstad | yeah | 19:35 |
| ayoung | all of the user and group ones would get policy_scope project | 19:36 |
| ayoung | what about create_domain | 19:36 |
| ayoung | er | 19:36 |
| ayoung | create_project | 19:36 |
| lbragstad | that's essentially what i have staged once we get a release of oslo.policy | 19:36 |
| ayoung | you can do that with a domain scoped token, or with a project scoped token, and it has different constraints | 19:36 |
| lbragstad | https://trello.com/c/ZjsNk84y/4-implement-scopetypes-in-oslopolicy | 19:36 |
| ayoung | is the dual scope types covered? | 19:37 |
| lbragstad | as in something can be done on the system and in a project? | 19:37 |
| lbragstad | yeah - scope_types is a list of strings | 19:38 |
| ayoung | lbragstad, domain and project in this case. Cool | 19:38 |
| ayoung | let me give it a firm once over... | 19:38 |
| lbragstad | so we can support that case | 19:38 |
| lbragstad | please do | 19:38 |
| ayoung | # If the token isn't system-scoped then we're dealing with | 19:39 |
| ayoung | # either a domain-scoped token or a project-scoped token. | 19:39 |
| ayoung | # From a policy perspective, both are "project" operations. | 19:39 |
| ayoung | # Whether or not the project is a domain depends on where | 19:39 |
| ayoung | # it sits in the hierarchy. | 19:39 |
| ayoung | token_scope = 'project' | 19:39 |
| ayoung | hmmm | 19:39 |
| ayoung | is this right? | 19:39 |
| lbragstad | to my knowledge it is | 19:39 |
| lbragstad | a domain is a project at the top of the tree, right? | 19:39 |
| ayoung | you need a domain scoped token to add a user, but a project scoped token to add projects under HMT | 19:39 |
| ayoung | I'm not really sure I care, but lets not break anything. hey kmalloc can you look at something for me? | 19:40 |
| ayoung | https://review.openstack.org/#/c/510222/8/oslo_policy/policy.py | 19:40 |
| ayoung | lbragstad, this is probably OK as is, but I would expect to be able to distinguish between project and domain scoped tokens in general | 19:40 |
| lbragstad | so - if you ignore the concept of domains and just consider everything a project | 19:41 |
| lbragstad | ugh - this would be easier with a whiteboard | 19:41 |
| ayoung | lbragstad, you are pitting me against myself...you know how badly I want that to be true | 19:41 |
| lbragstad | let's say domain-a is the root | 19:42 |
| lbragstad | it has two children, project-a and project-b | 19:42 |
| lbragstad | which would make them peers | 19:42 |
| *** thorst has joined #openstack-keystone | 19:42 | |
| ayoung | lets say domain default is the root, as that is the case today | 19:42 |
| lbragstad | ok | 19:42 |
| lbragstad | sure | 19:42 |
| lbragstad | and domain default has two children | 19:42 |
| ayoung | now, to add a new domain, I need a system scoped token | 19:42 |
| lbragstad | yes | 19:43 |
| ayoung | to add a user or group to any of those domains, today I should be using a domain scoped token | 19:43 |
| ayoung | and you are saying that we make that a project scoped token, we just check, in the operation, that the project is-a domain | 19:43 |
| ayoung | and it would be implicitly converted to a project scoped token at the policy check | 19:44 |
| ayoung | hmmm | 19:44 |
| lbragstad | i suppose that would work | 19:44 |
| ayoung | so at the p[olicy check, what oslo context is doing today won't plauy nice | 19:44 |
| lbragstad | so project-a and project-b are peers, right | 19:44 |
| ayoung | if we get a domain scoped tokne, there is no user_proejct_* value set | 19:44 |
| lbragstad | project-c is a child of project-b | 19:44 |
| kmalloc | why the hell can i not copy/paste from gerrit | 19:44 |
| ayoung | nah...say at the root | 19:44 |
| ayoung | default | 19:44 |
| ayoung | say I have a token scoped to default domain with the gawdawful role | 19:45 |
| ayoung | and to creat a user I need to have gawdawful on a project that is-a domain | 19:45 |
| *** dave-mccowan has joined #openstack-keystone | 19:45 | |
| ayoung | the project ID is not the same as the domain ID, I think, in the case of HMT. but I might be wrong | 19:45 |
| lbragstad | create user should be a 'system' level operation or a 'project' level operation | 19:46 |
| lbragstad | if i have a role on project-b that allows me to create users, i should be able to create users in project-b | 19:46 |
| ayoung | users and groups are the only entities that are currently scoped to domains, not projects...except of course, projects can be scoped to either | 19:46 |
| lbragstad | keystone should know to enforce things at the project-b level in that case | 19:46 |
| ayoung | you can't create users in a project | 19:47 |
| lbragstad | if you wanted to support the project-admin case, you could be setting the default_project_id or something like that | 19:47 |
| lbragstad | i'm using it as an example | 19:47 |
| ayoung | so, what we should have had, instead of domains owning both projects and users is that the abstraction for users should be called IdPs | 19:47 |
| ayoung | and..lets assume we made that happen. Why should we not be able to distinguish between a project scoped, a domain scoped, and and IdP scoped token? | 19:48 |
| ayoung | I'd liketo be able to theoretically have endpoint and service scoped tokens in the future | 19:48 |
| ayoung | what is the value of forcing everything not-system into a single buicket, and is that change set in stone? | 19:48 |
| ayoung | Could we adopt it today, and fix it tomorrow? | 19:48 |
| lbragstad | sure - but what you're dealing with is either a tree of projects, or a system tree | 19:49 |
| lbragstad | a domain just happens to be a specific node in the project tree | 19:49 |
| ayoung | not "just" | 19:49 |
| ayoung | it a node with specific semantics | 19:49 |
| ayoung | system is "just" a node in the tree...but with very special semantics | 19:50 |
| ayoung | lbragstad, don't get me wrong, I like this change, I just want to know the ratioanle for this specific decision, as I think this is going to break things | 19:51 |
| *** thorst has quit IRC | 19:51 | |
| lbragstad | i built a kwarg into enforce that allows for thinsg to be backwards compatible | 19:51 |
| ayoung | when we do HMT, and we make a domain act like a project, do we give it the same ID as the domain id? | 19:51 |
| ayoung | lbragstad, BTW, can you add me as a member on Trello? | 19:53 |
| ayoung | lbragstad, TYVM. Should I add a card for the oslo-context change? We didn't realize we were not using it, and it is kindof important | 19:55 |
| lbragstad | ayoung: sure - put the context in the card and i can find a place for it | 19:56 |
| ayoung | lbragstad, done. Added to "in progress" | 19:58 |
| lbragstad | cool - thanks | 19:58 |
| kmalloc | lbragstad: hmm. | 19:59 |
| kmalloc | i think my keystone checkout is broken =/ | 19:59 |
| ayoung | lbragstad, so do you think system roles will be ready soon? I can back off the is_admin_project work and skip right to using system roles. I saw that you had a slew of reviews WIP | 19:59 |
| kmalloc | lbragstad: why is TenantV2 assignment driver still in the tree? | 20:00 |
| kmalloc | lbragstad: did we miss it? | 20:00 |
| kmalloc | or did we need to wait? | 20:00 |
| lbragstad | ayoung: all the assignment bits are ready for review https://review.openstack.org/#/q/status:open+branch:master+topic:bp/system-scope | 20:00 |
| lbragstad | kmalloc: good question - i though we removed that? | 20:00 |
| lbragstad | ayoung: i'm working on a patch now to implement system-scoped tokens | 20:01 |
| *** itlinux has quit IRC | 20:01 | |
| kmalloc | https://github.com/openstack/keystone/blob/master/keystone/assignment/controllers.py#L38 | 20:01 |
| ayoung | ++ | 20:01 |
| lbragstad | that's the last bit we need to implement system scope for keystone in queens | 20:01 |
| ayoung | cool. I'll work on reviewing. | 20:01 |
| lbragstad | then it's getting the scope_types stuff done in other projects | 20:01 |
| kmalloc | i'll work around this for the moment. | 20:01 |
| kmalloc | but... we should look into why that is still there | 20:02 |
| ayoung | lbragstad, why are system assignement going into their own table and not the existing assingment table? | 20:02 |
| lbragstad | ayoung: the existing assignment table uses Enum | 20:02 |
| lbragstad | which happens to be a massive PITA | 20:02 |
| ayoung | so change that | 20:02 |
| ayoung | let me see... | 20:02 |
| lbragstad | https://review.openstack.org/#/c/501885/ | 20:03 |
| lbragstad | that's what i attempted to do first | 20:03 |
| ayoung | Did I do that? | 20:04 |
| lbragstad | but changing that while allowing for an online migration was painful | 20:04 |
| lbragstad | so we left if | 20:04 |
| *** thorst has joined #openstack-keystone | 20:04 | |
| lbragstad | and decided to keep system assignments in their own table | 20:04 |
| lbragstad | which might be more advantageous in the future if we expand system into its own tree | 20:04 |
| ayoung | I don't think so....if assignements is broken, lets fix that... | 20:04 |
| lbragstad | the assignment table isn't "broken" | 20:04 |
| lbragstad | it's just really hard to change the schema while doing an online migration | 20:05 |
| lbragstad | it's very hardcoded to the initial implementation | 20:05 |
| ayoung | add a new column | 20:05 |
| lbragstad | the type column is part of the primary key | 20:05 |
| lbragstad | so everything in that table needs to have a populated value in `type` | 20:06 |
| ayoung | You can't add a value to an enum? | 20:06 |
| lbragstad | no | 20:06 |
| lbragstad | it's a frozen set | 20:06 |
| lbragstad | which requires you to change the schema | 20:06 |
| ayoung | "An ENUM is a string object with a value chosen from a list of permitted values that are enumerated explicitly in the column specification at table creation time. " | 20:06 |
| ayoung | Joy | 20:06 |
| lbragstad | yeah - so we talked about it at the PTG | 20:07 |
| lbragstad | and figured it might be worth it to just keep system assignments as their own thing | 20:07 |
| ayoung | yeah...wow | 20:07 |
| ayoung | how about a whole new assignment table, then? | 20:07 |
| lbragstad | yep | 20:07 |
| lbragstad | one dedicated to system assignment only | 20:08 |
| lbragstad | and not as restrictive | 20:08 |
| lbragstad | so that we can elaborate on it in the future | 20:08 |
| ayoung | no, one that covers all of them, without an enum | 20:08 |
| lbragstad | then you have to do a migration | 20:08 |
| ayoung | I take it that was discussed as well, and dropped for some reason | 20:08 |
| ayoung | migration is pretty straight forward, copy from one table to the other | 20:09 |
| ayoung | not pretty, but, meh | 20:09 |
| lbragstad | adding a new table for system assignment needed to be done regardless, not copying all the data over didn't seem necessary and resulted in a lower bar | 20:09 |
| lbragstad | for me, personally, i kinda liked the fact they were separate | 20:09 |
| lbragstad | using Enum of a type when we have control of all the things from the manager and driver seemed a bit over-kill | 20:10 |
| ayoung | let me ask this, is the system assignemtn table capable of handling existing role assignments in the future? | 20:10 |
| lbragstad | existing role assignment? | 20:10 |
| ayoung | drop enum, migrate the assignments to the system assignment table? | 20:10 |
| ayoung | in, say, Tango time frame | 20:10 |
| lbragstad | i built the system_assignment table to not have Enum | 20:10 |
| ayoung | It looks to me like it is | 20:10 |
| ayoung | sure | 20:11 |
| lbragstad | which means you can come up with new assignment types in the future without requiring a data base migration | 20:11 |
| ayoung | lbragstad, so you still have a type column, just not as a nanum, right? | 20:12 |
| lbragstad | yes | 20:12 |
| lbragstad | correct | 20:12 |
| ayoung | and the primary key logic is the same | 20:12 |
| lbragstad | i also pulled a bunch of the logic to determine the assignment type into the manager | 20:12 |
| lbragstad | and made the driver moar dumb | 20:12 |
| lbragstad | yeah - primary key is still the same | 20:12 |
| ayoung | OK, lets drive on to success with this, but I think we'll want to merge into a single table in the future | 20:12 |
| ayoung | not worth holding it up over | 20:13 |
| ayoung | I'm going to rebase to make sure it works, and I'll +2 | 20:13 |
| openstackgerrit | ayoung proposed openstack/keystone master: Add a new table for system role assignments https://review.openstack.org/507993 | 20:13 |
| ayoung | assuming all is good... | 20:13 |
| ayoung | most concerned about the migration numbering | 20:13 |
| lbragstad | i don't expect any problems there, we haven't had much churn this release with migrations | 20:14 |
| ayoung | We are up to 30. Lets get this in now. | 20:14 |
| ayoung | lbragstad, +2 from me on that. | 20:15 |
| openstackgerrit | ayoung proposed openstack/keystone master: Implement backend logic for system roles https://review.openstack.org/507994 | 20:15 |
| lbragstad | cool | 20:15 |
| lbragstad | fwiw - those patches are all in a linear series | 20:16 |
| ayoung | the word "grant" is such a henrynashism | 20:16 |
| lbragstad | ayoung: also - when you start reviewing the manager logic, just a heads up | 20:16 |
| ayoung | almost there... | 20:16 |
| lbragstad | i made a bunch of specific APIs for things that are explicit, instead of having one method and a bunch of kwargs | 20:17 |
| ayoung | I get it. And I like that approach...let me see. | 20:17 |
| ayoung | driver code looks fine | 20:17 |
| lbragstad | ^ that helped make the drivers super dumb to be honest | 20:18 |
| openstackgerrit | ayoung proposed openstack/keystone master: Implement manager logic for user+system roles https://review.openstack.org/512468 | 20:18 |
| ayoung | looks fine. lbragstad you mean like how you hid inherited and type? | 20:19 |
| lbragstad | type should be set in the manager | 20:19 |
| lbragstad | and just passed to the backend | 20:19 |
| lbragstad | i don't think the backend should be making those types of decisions anyway, that seems like business logic | 20:20 |
| ayoung | ++ | 20:20 |
| ayoung | exactly the split we shouild be pushing. COntroll is just web level, business logic in the manager, driver is data layer | 20:20 |
| lbragstad | right | 20:20 |
| openstackgerrit | ayoung proposed openstack/keystone master: Implement manager logic for group+system roles https://review.openstack.org/512641 | 20:21 |
| openstackgerrit | ayoung proposed openstack/keystone master: Add user system grant policies https://review.openstack.org/514471 | 20:22 |
| ayoung | lbragstad, let me redo my is_admin_project patch so that we have a new rule name, and we can swap out that rule when this stuff gets merged. Even id we hold off on my patch, we can rebase it on the system, role stuff when required | 20:24 |
| lbragstad | ok - i'm going to get my patch up for system scoped tokens | 20:26 |
| lbragstad | trying to get that done by EOD | 20:26 |
| ayoung | lbragstad, the one change I'd like to make is to have the policy for system assignments tightened up ahead of time | 20:28 |
| ayoung | instead of admin_required, lets get a rule ion place for system roles, and use that | 20:29 |
| lbragstad | ayoung: let's get the scope_types stuff merged too then? | 20:29 |
| ayoung | ++ | 20:29 |
| ayoung | lbragstad, I'm going to go out on a limb here and +2 that one. Irealluy don't like that domain is collapsed into project, but I'll defer on this. I think it will break things, but maybe it will break things in a good way. | 20:31 |
| ayoung | damnit, he downgraded his +2 to a +1 | 20:31 |
| lbragstad | ayoung: let's get another set of eyes on it then? | 20:31 |
| ayoung | one sec | 20:31 |
| ayoung | maybe we can get doug to go back up | 20:31 |
| ayoung | lbragstad, can we get the types into an actual array as opposed to a comma separated string? | 20:32 |
| adriant | kmalloc, cmurphy: thanks for the review! Just about to run to the office, but will be around on IRC in a few mins if you want to follow up, but I've added comments to the review that should clarify | 20:32 |
| lbragstad | ayoung: it is an array | 20:33 |
| lbragstad | it's an array of strings | 20:33 |
| ayoung | lbragstad, so what about his comment? | 20:33 |
| adriant | cmurphy, lbragstad: lance was right, I need it for project namespaces (see email thread link in the review) | 20:33 |
| lbragstad | ayoung: https://review.openstack.org/#/c/510222/8/oslo_policy/policy.py@998 | 20:33 |
| lbragstad | ayoung: it's when rendering the documentation | 20:34 |
| lbragstad | default.scope_types was being rendered as 'systemproject' when scope_types = ['system', 'project] | 20:34 |
| lbragstad | instead of 'system, project' | 20:34 |
| ayoung | lbragstad,so is there something to fix there? | 20:34 |
| ayoung | ah, you got that in the next revision | 20:35 |
| lbragstad | i pushed a new patch set that uses .join() | 20:35 |
| ayoung | why did he downgrade then? | 20:35 |
| lbragstad | ayoung: he probably just wanted to make sure concerns were addressed before someone came through and kicked it in | 20:35 |
| ayoung | would it be presumtuous of me to +@a it then? | 20:36 |
| ayoung | I think I'm the only policy core here | 20:36 |
| lbragstad | ayoung: let's just double check with him quick | 20:36 |
| lbragstad | or dims | 20:36 |
| ayoung | lbragstad, consider my +2 sticky unless something goes radically different, or call me and I'll re-review. | 20:37 |
| lbragstad | ack | 20:37 |
| ayoung | I'm focused on an internal project for the next 3 days, which is why the current flurry of activity | 20:37 |
| ayoung | I'll be back engaged on Friday | 20:37 |
| lbragstad | cool - i should have a bunch of stuff ready by then | 20:38 |
| lbragstad | with the system-scope stuff | 20:38 |
| openstackgerrit | ayoung proposed openstack/keystone master: Add is_admin_project check to policy for non scoped operations https://review.openstack.org/257636 | 20:43 |
| ayoung | lbragstad, lbragstad OK so ^^ has it down to a single rule. When we get oslo-context support, we can change that rule: it will be a one line change for policy | 20:44 |
| lbragstad | ok | 20:44 |
| lbragstad | i can take a look | 20:44 |
| ayoung | figure out what you want oslo-context to look like, and let me know. I can work on that. I'll sync with jamielennox, too | 20:45 |
| ayoung | https://review.openstack.org/#/admin/groups/556,members | 20:50 |
| ayoung | kmalloc, care to kick that one on through? | 20:50 |
| *** jdennis has quit IRC | 20:50 | |
| kmalloc | ayoung: sec. | 20:50 |
| ayoung | that list might need some updating | 20:50 |
| ayoung | dims got it already | 20:51 |
| kmalloc | ayoung: making a stab and removing @dependency.provides/requires | 20:51 |
| *** jaosorior has quit IRC | 20:51 | |
| ayoung | oooh | 20:51 |
| kmalloc | oh to hell with some of these docstring pep8 things. D400... REALLY?! | 20:54 |
| kmalloc | "must end with a '.' | 20:54 |
| kmalloc | "first line should be in the imperative, "thi" not "this" | 20:55 |
| kmalloc | wow. just wow | 20:55 |
| kmalloc | worthless docstring linting ftw! | 20:55 |
| kmalloc | totally worthless | 20:55 |
| *** thorst has quit IRC | 20:56 | |
| lbragstad | lol | 20:57 |
| ayoung | Pedantry, thy name is Guido. | 20:57 |
| kmalloc | ok lets see how bad i screwed it all up with this change. | 21:02 |
| * kmalloc runs tox -epy27 | 21:02 | |
| kmalloc | it's passing pep8 fwiw | 21:02 |
| *** thorst has joined #openstack-keystone | 21:02 | |
| ayoung | schweeet | 21:02 |
| *** McClymontS has joined #openstack-keystone | 21:03 | |
| *** McClymontS has quit IRC | 21:03 | |
| kmalloc | wow our tests are bad and assume a lot of things. | 21:04 |
| *** itlinux has joined #openstack-keystone | 21:05 | |
| lbragstad | kmalloc: we shouldn't need https://github.com/openstack/keystone/blob/51d5b63a083450468cec474b9b6400df5d977091/keystone/token/providers/fernet/core.py#L156-L169 anymore should we? | 21:06 |
| *** itlinux has quit IRC | 21:06 | |
| *** thorst has quit IRC | 21:07 | |
| lbragstad | technically, that's only there to authenticate and validate v2.0 tokens, which we removed... | 21:07 |
| lbragstad | and we're not providing any v2.0 token validation compatibility from pike -> queens, right? | 21:08 |
| lbragstad | because... that wouldn't make sense? | 21:08 |
| kmalloc | in theory we should't | 21:09 |
| lbragstad | we should support that case? | 21:09 |
| lbragstad | shouldn't* | 21:10 |
| *** thorst has joined #openstack-keystone | 21:17 | |
| ayoung | KILL IT DEEEEAD! | 21:17 |
| *** nicolasbock has joined #openstack-keystone | 21:19 | |
| *** jdennis has joined #openstack-keystone | 21:19 | |
| SamYaple | i dont want to give people false hope... i say we `sed -i '/v2/d' *` | 21:19 |
| *** thorst has quit IRC | 21:20 | |
| *** thorst has joined #openstack-keystone | 21:21 | |
| openstackgerrit | ayoung proposed openstack/keystone master: Remove dead code for auth_context https://review.openstack.org/525325 | 21:33 |
| cmurphy | adriant: responded on the patch, thanks for elaborating but i don't have a better suggestion at the moment :/ | 21:33 |
| *** thorst has quit IRC | 21:36 | |
| adriant | cmurphy: that's right we kind of call the vew API additons as versions (3.9 is the current one), but it isn't really microversions. | 21:38 |
| adriant | few* | 21:38 |
| ayoung | the first path is +52, -39 but the second is +0, -264 | 21:38 |
| ayoung | that is still a net -251 which I consider a win | 21:39 |
| ayoung | we at 3.9? Next wone should be 4.0 | 21:39 |
| ayoung | 3.10 is weird | 21:39 |
| *** pcaruana has quit IRC | 21:39 | |
| adriant | ayoung: but that will sound confusion since it isn't a true v4 :P | 21:40 |
| adriant | ... | 21:40 |
| adriant | jesus I can't english today | 21:40 |
| adriant | confusing | 21:40 |
| adriant | cmurphy: yeah, I don't know what to do. I think kmalloc is right, it is a breaking change since we don't know what/who it might affect, but it's mildly frustrating regardless. :( | 21:43 |
| cmurphy | adriant: yeah :( | 21:43 |
| adriant | since we are getting rid of v2, can we do v4 now? :P | 21:43 |
| * adriant is only joking | 21:43 | |
| cmurphy | we should start making a list of everything we want to break for v4 | 21:44 |
| lbragstad | ayoung: SamYaple ack - removing it | 21:45 |
| adriant | cmurphy: would be an interesting list to see | 21:46 |
| *** raildo has quit IRC | 21:47 | |
| SamYaple | cmurphy: we should get rid of domains in v4 | 21:47 |
| adriant | SamYaple: nah, domains are useful. We'd need a different but similar concept instead then. | 21:48 |
| SamYaple | same-same, but different | 21:48 |
| SamYaple | agreed | 21:48 |
| cmurphy | lol | 21:48 |
| SamYaple | i just wish there was a way to cleanly correct weird apis inconsistencies *without* carrying the broken old inconsistent way along with the new consistent way | 21:50 |
| *** thorst has joined #openstack-keystone | 21:50 | |
| SamYaple | but i think thats called a time machine | 21:50 |
| adriant | pretty much | 21:50 |
| adriant | right now I'd love to know why someone thought users should have names of 255 but projects only 64 | 21:51 |
| SamYaple | my legal name is longer than 64 characters | 21:51 |
| lbragstad | imo, a domain should be a root level project, but not called a domain | 21:51 |
| SamYaple | lbragstad: agreed. andi thought there was work towardthat back in mitaka.... | 21:52 |
| adriant | lbragstad: so you'd set auth/federated user source on a root project? | 21:52 |
| cmurphy | from the thread it seems like they would have preferred everything be 64 but had to make usernames longer because ldap | 21:52 |
| SamYaple | isnt there an is_domain field in the project table? | 21:52 |
| lbragstad | yeah | 21:52 |
| adriant | domains are projects! But we still have to keep the domain api. | 21:52 |
| SamYaple | yea :/ | 21:53 |
| SamYaple | well v4! good luck selling that one lol | 21:53 |
| adriant | that api is gone in v4, so you are right, domains go away :P | 21:53 |
| lbragstad | well - before we even get to that point, i think we should do kmalloc's idea of decoupling auth and making it versionless | 21:53 |
| *** thorst has quit IRC | 21:54 | |
| SamYaple | lbragstad: as in, support what we call v2.0 and v3 and potentially "v4" auth in the same way? | 21:54 |
| lbragstad | SamYaple: just don't have v3 in the url path | 21:54 |
| lbragstad | or a version in the url path | 21:55 |
| lbragstad | instead, it could be discoverable | 21:55 |
| adriant | but how does that work when your source of users is in part defined by the underlying data model that is related to a given version? | 21:55 |
| adriant | domain/root project/etc bound to sql or federated source | 21:55 |
| SamYaple | ah i see. i thought auth was already discoverable. but maybe thats just middleware abstraction | 21:55 |
| lbragstad | adriant: i'm not sure i understand the question | 21:56 |
| adriant | lbragstad: sorry, lemme try and elaborate. | 21:57 |
| openstackgerrit | Merged openstack/oslo.policy master: Add scope_types to RuleDefault objects https://review.openstack.org/510222 | 21:58 |
| adriant | lbragstad: how you authenticate, is based on the underlying models. If the backend is sql, it has certain requirements, if it's a a federated source, then it has others, and to control where you authenticate from is also managed by the underlying data models that wouldn't be able to be versionless per say. | 21:58 |
| ayoung | adriant, domains die. FOr projects, we make projects strictly hierarchical. FOr users and groups, we use IdP | 21:59 |
| adriant | I could be entirely wrong, or asking the wrong question. | 21:59 |
| ayoung | nah, you are right on | 22:00 |
| adriant | ayoung: but that assumes we entirely from the iDP like elements from keystone, which we can't really do | 22:00 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove private methods for v2.0 and v3 tokens https://review.openstack.org/525329 | 22:00 |
| openstackgerrit | Lance Bragstad proposed openstack/keystone master: Teach TokenFormatter how to handle system scope https://review.openstack.org/525330 | 22:00 |
| ayoung | adriant, ah, but yes we can | 22:00 |
| ayoung | we call all local domains IdPs | 22:00 |
| ayoung | and remote Idps get protocols | 22:00 |
| adriant | ayoung: so we would make a mini idp as part of keystone and just that 'remotely' like any other? | 22:02 |
| adriant | and just use* that | 22:02 |
| ayoung | adriant, yep | 22:03 |
| ayoung | adriant, which, in essence, we already have | 22:03 |
| adriant | ayoung: expect without the duplication of keystone idp users and a linked shadow user for the authorisation component. | 22:04 |
| adriant | but yeah, I get what you mean | 22:05 |
| *** rcernin has joined #openstack-keystone | 22:07 | |
| adriant | ugh, I still need to find time to write up and submit a spec for some MFA bits. lbragstad, spec freeze for keystone just happened or is about to? | 22:08 |
| adriant | https://releases.openstack.org/queens/schedule.html says Dec 04 - Dec 08 so I potentially still have a couple of days :P | 22:10 |
| *** thorst has joined #openstack-keystone | 22:10 | |
| lbragstad | adriant: yep - it happens this week | 22:11 |
| cmurphy | proposal freeze was Oct 20 though :P | 22:12 |
| adriant | cmurphy: blast! | 22:12 |
| adriant | Well, I'll write it up anyway and start prototyping code. If I can convince you potentially otherwise I shall, otherwise we can approve/merge stuff first thing after queens :) | 22:13 |
| lbragstad | cmurphy: aha - yes.. good call | 22:14 |
| *** thorst has quit IRC | 22:14 | |
| *** spilla has quit IRC | 22:16 | |
| *** phalmos has quit IRC | 22:22 | |
| *** ayoung has quit IRC | 22:53 | |
| *** thorst has joined #openstack-keystone | 22:53 | |
| *** thorst has quit IRC | 22:58 | |
| *** ayoung has joined #openstack-keystone | 23:03 | |
| openstackgerrit | Gage Hugo proposed openstack/keystone master: WIP - Make fernet config and utils generic https://review.openstack.org/523200 | 23:27 |
| *** gmann_afk is now known as gmann | 23:27 | |
| *** thorst has joined #openstack-keystone | 23:33 | |
| *** thorst has quit IRC | 23:33 | |
| *** notmyname has left #openstack-keystone | 23:41 | |
| *** efried is now known as efried_cya_wed | 23:41 | |
| *** thorst has joined #openstack-keystone | 23:45 | |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: WIP Add application credentials driver https://review.openstack.org/524928 | 23:48 |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: WIP Add Application Credentials manager https://review.openstack.org/524747 | 23:48 |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: WIP Add Application Credentials controller https://review.openstack.org/524423 | 23:48 |
| openstackgerrit | Colleen Murphy proposed openstack/keystone master: WIP Add application credential auth plugin https://review.openstack.org/525346 | 23:48 |
| kmalloc | ayoung: oh man i think i have this patchset ready | 23:48 |
| kmalloc | ayoung: running tests now. need to fix a couple things still, but... it's way better | 23:49 |
| *** thorst has quit IRC | 23:49 | |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: WIP: Remove Dependency Injection https://review.openstack.org/499703 | 23:50 |
| *** thorst has joined #openstack-keystone | 23:51 | |
| kmalloc | lbragstad, ayoung: ^ this is way way way way better. it wont past tests (i think 2-3 are failing) | 23:53 |
| kmalloc | but it is the right direction. | 23:54 |
| *** jmlowe has quit IRC | 23:55 | |
| *** thorst has quit IRC | 23:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!