| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-03-12 | |||
| 20:59:10 | adriant | so it need to do discovery | |
| 20:59:16 | adriant | i want a way to bypass that step | |
| 20:59:27 | adriant | "use this custom catalog instead" potentially | |
| 20:59:29 | mordred | adriant: so - if you set identity_endpoint_override to the auth_url - it'll skip discovery | |
| 20:59:40 | adriant | ah! | |
| 20:59:43 | adriant | perfect | |
| 21:00:09 | adriant | so "<service_type>_endpoint_override" works? | |
| 21:00:18 | mordred | let me know if that works - if it does, I think it might be nice to figure out how to make conn.identity.list_projects - or at least conn.list_projects be able to do this without the user needing to know that specific piece of magic | |
| 21:00:18 | adriant | for all services? | |
| 21:00:21 | mordred | adriant: yes! | |
| 21:00:31 | adriant | cool | |
| 21:00:53 | adriant | and yeah, ideally having the unscoped actions able to natively reuse the auth_url for identity could be cool | |
| 21:01:09 | adriant | but that could also be a pain | |
| 21:01:21 | mordred | yeah. the biggest hurdle would be getting conn.identity to not fall over when it gets created | |
| 21:01:43 | mordred | which is why this one might be better up at the Connection layer so we can bypass that stuff | |
| 21:04:23 | adriant | identity_endpoint_override seems to work | |
| 21:06:03 | mordred | \o/ | |
| 21:06:25 | mordred | cool. then I think we should definitely update Connection.list_projects to do the right thing | |
| 21:07:29 | mordred | that said - I wonder if we can make the proxy creation smarter if service_type is identity - and to look at the auth stuff, look for project info, and if it's not there go ahead and set the endpoint_override ... | |
| 21:09:20 | adriant | mordred: specifically the endpoint I'm actually after for this use case is conn.identity.user_projects() which is the non-admin one | |
| 21:09:40 | adriant | one* | |
| 21:09:54 | mordred | hrm. we might not have that one in the cloud layer ... but that's a really good point | |
| 21:10:07 | mordred | I think it's worth making conn.identity work without project info then | |
| 21:10:07 | adriant | if one exists in the connection layer for listing a user's own projects then that would work too | |
| 21:10:35 | mordred | it shouldn't be too hard - just need to inspect the auth args a smidge :) | |
| 21:10:58 | adriant | although it could end up a lot of work, might be worth investigating if other projects have any unscope APIs :/ | |
| 21:11:11 | mordred | it's a good question | |
| 21:11:31 | mordred | kmalloc, cmurphy: ^^ ? do we know if non-keystone use unscoped apis? | |
| 21:11:33 | adriant | I have a feeling probably not many | |
| 21:11:55 | mordred | yeah - seems more like a thing that's needed for keystone and doesn't make a TON of sense elsewhere | |
| 21:12:12 | mordred | maybe the nova calls that deal with hosts and hypervisors? | |
| 21:12:20 | adriant | those would be system scope | |
| 21:13:13 | adriant | Yeah, i think there probably aren't many. | |
| 21:13:34 | cmurphy | mordred: adriant no, only keystone uses unscoped tokens, it's only useful for getting a scoped token | |
| 21:14:18 | adriant | although some of the Keystone APIs don't need scope: list (user) projects, change password, etc? | |
| 21:15:45 | cmurphy | you can list your own projects with an unscoped token, change password i'm not 100% sure though it would make sense | |
| 21:16:51 | cmurphy | oh change password doesn't require a token at all | |
| 21:20:06 | adriant | yeah, that's right, you just need your old password | |
| 21:41:01 | kmalloc | mordred: what cmurphy said | |
| 21:41:20 | kmalloc | unscoped tokens should die IMO | |
| 21:41:25 | kmalloc | but we can't make them go away | |
| 21:41:56 | kmalloc | I *think* someone was originally trying to use unscoped tokens like we use systemscope going forward, but that might require asking folks that no longer work on OpenStack | |
| 21:52:16 | mordred | kmalloc: so - you and adriant have both mentioned this "system" scoped token | |
| 21:52:30 | mordred | how does one get one of those? are we missing anything to use those with sdk? | |
| 21:59:08 | adriant | kmalloc: I don't think unscoped tokens can go away really if you need to query which project you want to scope to first | |
| 22:01:22 | adriant | for things like Horizon (or any GUI) you won't ever provide a project as part of auth. So some auth flow that includes: "here are your projects" and then allows you to scope into one will always be needed | |
| 22:01:49 | adriant | we even have some cli tools that only ask for password and username, and then provide you with a list of project options to scope to | |
| 22:03:00 | kmalloc | mordred: system scope is new, as in as of Stein. It's done just like scope: {project_id: xxx} | |
| 22:03:15 | cmurphy | mordred: it's supported in ksa so it should be transparent to openstacksdk, instead of setting project-id in clouds.yaml you set system-scope | |
| 22:03:31 | kmalloc | mordred: ^ what cmurphy said, she's faster at typing than I am clearly | |
| 22:03:34 | mordred | neat! | |
| 22:03:46 | mordred | it's almost like building these things on top of each other is worth-while! | |
| 22:03:52 | kmalloc | right?! | |
| 22:03:53 | kmalloc | :) | |
| 22:04:06 | kmalloc | some APIs will become system, this is to solve the "Admin" problem | |
| 22:04:19 | kmalloc | meaning you wont need an "admin project" for things that are clearly not project/domain scoped | |
| 22:04:24 | mordred | \o/ | |
| 22:04:48 | adriant | I'm far too happy about that | |
| 22:05:03 | adriant | the whole admin-ness problem was such pain | |
| 22:05:37 | cmurphy | there is some documentation on system scope https://docs.openstack.org/keystone/latest/contributor/services.html#system-scope and lbragstad wrote some more documentation https://review.openstack.org/#/c/638563/9/doc/source/contributor/services.rst | |
| 22:26:47 | mordred | cmurphy, kmalloc: so - in the scrollback I was talking about making sdk know how to make an adapter without the catalog being present if the service-type is identity and there is no project (or I guess system-scope) info in the auth dict ... does that sound like a something we should push down into ksa instead? | |
| 22:27:42 | mordred | (the current sdk workaround for working with unscoped tokens is to set identity_endpoint_override=$auth_url which will cause the adapter to be made without trying to look up identity in the catalog) | |
| 22:28:06 | mordred | that SEEMS generic enough - but maybe it's only generic enough in sdk and in ksa it would be a tragedy | |
| 22:52:53 | kmalloc | that is generic enough | |
| 22:53:05 | kmalloc | but that sounds like a SDK thing | |
| 22:53:08 | kmalloc | less KSA | |
| 22:53:28 | kmalloc | i think... | |
| 22:53:33 | kmalloc | let me poinder a few more minutes | |
| 22:53:50 | mordred | kmalloc: yeah - I'm 99% sure I agree :) | |
| 22:54:08 | kmalloc | though i *think* KSA should work in that mode without jumping through hoops | |
| 22:54:26 | kmalloc | so a little of ksa fixing and SDK is smart enough to know how to do things | |
| 22:54:44 | kmalloc | unscoped tokens suck =/ | |
| 23:15:24 | mordred | kmalloc: ++ | |
| 23:15:46 | mordred | kmalloc: and yeah - I think it's possible that the only issue here is how sdk is creating ksa objects | |
| 23:16:04 | mordred | rather than a ksa deficiency itself - but if there is a deficiency, hopefully it's an easy enough one to fix | |
| #openstack-sdks - 2019-03-13 | |||
| 07:49:51 | kailun | amotoki: hi | |
| 07:49:59 | amotoki | kailun: hi | |
| 07:51:34 | kailun | amotoki: regarding L193 in review 624798, there is another case, that is --shared, --private and --project are all not specified | |
| 07:52:27 | kailun | amotoki: in this situation, we should consider the created range to be a "shared" one, which means "project_id" should not be populated into the attr | |
| 07:53:14 | amotoki | kailun: before digging into the detail, let me sort out which patterns are possible. | |
| 07:53:55 | kailun | amotoki: based on the current logic, this'll goto L205 which populates attrs w/ the current project_id, this is not expected | |
| 07:54:41 | kailun | amotoki: sure | |
| 07:55:22 | amotoki | kailun: possible patterns are (a) none of --shared, --private and --project are specified (b) --shared only (c) --private only (d) --private and --project | |
| 07:55:24 | kailun | amotoki: we should have 6 patterns I guess? | |
| 07:55:41 | amotoki | kailun: the above are valid, right? | |
| 07:56:05 | amotoki | kailun: (e) --project only and (f) --project and --shared are invalid. | |
| 07:56:36 | kailun | amotoki: right | |
| 07:57:16 | amotoki | kailun: regarding L.193, I think the previous logic looks enough. | |
| 07:58:00 | amotoki | it is because "if not parsed_args.private and parsed_args.project" (L.171) catches (e) and (f) cases. | |
| 07:58:02 | amotoki | right? | |
| 07:58:11 | kailun | amotoki: yes, I agree | |
| 07:58:26 | kailun | amotoki: L205 is needed | |
| 07:58:46 | amotoki | kailun: looking at L.205 now | |
| 08:00:29 | amotoki | kailun: L.182-186 ensures attrs['shared'] is False only when --private is specified, so "elif not attrs['shared']" at L.205 looks enough. | |
| 08:00:50 | amotoki | kailun: I mean "and not parsed_args.shared" looks unnecessary at L.205. | |
| 08:01:37 | kailun | amotoki: agree | |
| 08:02:07 | amotoki | kailun: thanks for clarification. I try to simplify the logic for easy maintenance. | |
| 08:02:45 | amotoki | kailun: I will add a note to the review based on this discussion. | |
| 08:03:10 | kailun | amotoki: I kind of know that some conditions are necessary when I write that patch, I just want to make it easier from a semantic level | |
| 08:03:37 | kailun | amotoki: anyway, great thanks for your review, make sense to me | |