Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-03-12
15:54:05 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: WIP Split OpenStackCloud into reasonable pieces https://review.openstack.org/642218
16:30:00 openstackgerrit Glenn Van de Water proposed openstack/python-openstackclient master: Fix service discovery in functional tests https://review.openstack.org/642074
17:30:43 mordred gtema: no - there will be no git:// protocol support from opendev - so if you wanna try it out, cloning over https:// is the way to go (it'll also be the only way to go in the future)
20:54:44 adriant mordred: for context, in cases where you are doing multi-project actions, or writing tools for them, you don't really need to know ahead of time what projects you have. So you can auth, get a list, and then create an SDK per project (per region), and do your actions.
20:56:04 adriant the solution I've helped someone go with is to use keystone auth to get a session, get the token from that, then use raw requests against the auth url (and correct user_projects path) to then get their project list, and then use that to further make their SDKs per project.
20:56:40 adriant It's not a terrible solution, but the need to actually go directly to the endpoint and handle the json yourself is lacking a bit of elegance
20:57:02 adriant although... I wonder
20:57:12 adriant kmalloc: can you list your projects via KeystoneAuth?
20:58:46 mordred adriant: cause if I don't have a project id when I get the token, I don't get a catalog, right? thus the "re-use the auth_url as the identity_url" piece, yeah?
20:58:57 adriant yep
20:59:02 adriant you have an empty catalog
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.

Earlier   Later