Earlier  
Posted Nick Remark
#openstack-sdks - 2019-08-29
09:59:12 gtema interesting. Was not seeing this.
10:00:32 gtema are you stuck with an old version?
10:01:05 gtema can you please also show the trace itself?
10:12:44 ITD27M01 gtema: I am stuck with an older version shipped with RHEL 7 rpms, the full traceback: https://gist.github.com/ITD27M01/07632e02a736cbacbb37a63dc58f039d
10:17:22 Kl4us1912 can openstacksdk get a Connection.get_project_by_id method (similar to get_user and get_user_by_id).
10:17:51 Kl4us1912 use case is querying one's own project without having the list projects permission
10:19:01 Kl4us1912 i implemented a workaround by copying and slightly modifying get_user_by_id
10:19:54 gtema itd27m01: actually you should use not the unscoped, but domain scoped token. Then it is expected, that service catalog is properly populated
10:20:36 ITD27M01 gtema: How I can change my clouds.yaml for this?
10:21:08 gtema you remove project_name/id and set domain_id/name=user_domain_id/name (so really both)
10:21:57 gtema for me it is defining user_domain_name AND domain_name with same values
10:25:23 ITD27M01 gtema: With domain_name + user_domain_name I get the 401 Error. But only user_domain_name works. Is it policy caveat?
10:25:41 gtema probably yes
10:26:35 gtema it's a funny case how you configure, so that libs get domain scoped token. And normally it is absence of project and presence of domain data
10:27:02 gtema user_domain_name is used kind of for authorization agains cloud at all, but domain - to get a domain token
10:27:45 gtema if you get 401 maybe you are missing privs. But then the question why it works with newer SDK
10:28:12 gtema there were tons of changes, so figuring out what is different will be a challenge
10:30:19 gtema can you trace newer SDK to understand which token is retrieved? I do not believe you can get list of projects with unscoped token
10:31:28 ITD27M01 gtema: The purpose of my code is to provide to users the list of their projects. If I understand this correctly the domain scoped token only available for admins but unscoped token available for everyone authenticated.
10:31:43 gtema yes
10:32:33 ITD27M01 gtema: I see that service_catalog is empty for newer SDK too. But the method connection.identity.user_projects(user=user_id) works
10:33:12 gtema can you compare the endpoints for requests?
10:33:34 gtema or maybe the problem is not the SDK, but keysoneauth1?
10:33:47 gtema if you stuck with older versions it might be a problem
10:34:55 gtema in this case you might try hardcoding endpoint (for single region cloud should be normally not a problem)
10:34:56 ITD27M01 gtema: In virtualenv the keystoneauth1 is the same
10:35:32 ITD27M01 gtema: In the long term I want to build rpm for new releases of openstacksdk. Perhaps there is already such a repository?
10:36:25 gtema eeh, this is a problem for everyone. I myself build RPMs for our cloud in OpensuseBuild
10:36:44 gtema but you can look for RDO packages
10:39:36 ITD27M01 gtema: For stein the 0.27.0 is available I will check it
10:40:18 ITD27M01 gtema: BTW by tracing the call I need to find the source of the identity url?
10:40:29 gtema if nothing works you can try doing conn.identity.get('YOUR_KEYSTONE_URL/v3/user_id/projects')
10:40:49 gtema you can see this in the project_scoped token response
10:41:24 gtema it's only that this https://docs.openstack.org/api-ref/identity/v3/?expanded=list-projects-for-user-detail#list-projects-for-user API need to be allowed for the user
10:42:25 gtema alternatively /v3/auth/projects
10:43:21 gtema this last might be available with unscoped token
10:45:15 ITD27M01 gtema: conn.identity.get('{}/v3/user_id/projects'.format(conn.auth['auth_url'])) ?
10:46:20 gtema almost - {}/v3/users/REQUESTED_USER_ID/projects
10:48:35 gtema or really conn.identity.get('users/{}/projects')
10:52:03 gtema res = conn.identity.get('users/%s/projects' % conn.current_user_id)
10:55:05 ITD27M01 gtema: projects = connection.identity.get('{auth_url}/v3/users/{user_id}/projects'.format(auth_url=str(connection.auth['auth_url']), user_id=str(user_id))) - this works for me. But without auth_url this return the same catalog is empty
10:55:32 ITD27M01 gtema: Thank you
10:55:39 gtema and if you connect as default project?
10:56:49 ITD27M01 gtema: Hm, what is default project? The project defined in clouds?
10:57:13 gtema yeah, in your domain there is root project
10:57:37 gtema i will try something in 10 minutes
11:14:00 ITD27M01 gtema: I am checking now and found that simple call (connection.identity.user_projects(user=user_id)) works in at least 0.28.0. In 0.27.0 it does not work yet
11:14:28 gtema_ well, if this works - cool. I can't actually connect to the my cloud without specifying project or domain
11:18:19 ITD27M01 gtema: Ok, thank you
11:18:25 gtema_ welcome
11:21:08 gtema_ btw: conn.session.get('{auth_url}/auth/projects'.format(auth_url=str(conn.auth['auth_url']))) might be a 'cleaner' solution
11:22:29 gtema_ or including /v3 - depending what is your case
12:53:37 ITD27M01 gtema: I got it! https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/config/cloud_region.py#L466
12:54:10 ITD27M01 gtema: The auth_url is used for identity service in the case of unscoped token
12:54:15 gtema_ aah, yeah
12:54:19 gtema_ cool
12:54:41 ITD27M01 gtema: https://opendev.org/openstack/openstacksdk/commit/72504d7f5b4be4a49a0e380b36a5c208ca11611d
12:54:46 ITD27M01 this change
12:55:26 gtema_ cool
16:00:27 elmiko API SIG office hours now starting, grab yer popcorn!
16:00:42 openstackgerrit Matt Riedemann proposed openstack/python-openstackclient master: Microversion 2.77: Support Specifying AZ to unshelve https://review.opendev.org/665336
16:00:50 edleafe I was waiting for you to type something :)
16:00:58 gtema_ oh, yeah. It's again happy hour
16:01:00 elmiko haha, i kinda felt so after about 10 seconds
16:01:32 elmiko this hour brought to you by our undying love for edleafe =)
16:01:45 gtema_ :)
16:01:55 edleafe Oh, that's rich!
16:02:00 elmiko haha
16:05:01 elmiko is dtantsur around?
16:05:07 dtantsur who?
16:05:18 elmiko i kinda wnat to talk about the suggestions that came up on the ml
16:05:42 elmiko like, should we spend some time over the next week or two to triage all the todos and reviews?
16:05:56 dtantsur the only reason we haven't done it already is that nobody has time for it
16:05:58 elmiko with the goal being to clean up things that we won't get to, or have shifted scope significantly
16:06:03 elmiko ack
16:06:12 elmiko i'm gonna take an action to make some progress there
16:06:14 dtantsur I'm open to an hour of a call to try tackle it
16:06:29 dtantsur I think a general "let's do it" won't help :)
16:06:32 elmiko how about this, i will start by going through the open reviews and adding my thoughts about them to each
16:07:00 elmiko maybe next week during the hour we can go through and just make some decisions about keeping them open, closing, or w/e
16:07:07 dtantsur ++
16:07:16 elmiko ok, cool
16:07:35 elmiko gtema_: i am happy to include you in any of this if you would like?
16:07:43 gtema_ sure
16:07:45 dtantsur of course he would :)
16:08:01 edleafe They aren't so much "ToDos" as they are "We know there's a gap here"
16:08:03 gtema_ hehe, dtantsur - you own me a review
16:08:07 elmiko edleafe: ++
16:08:11 dtantsur really? you owe me a beer!
16:08:15 elmiko i'm not sure what to do about the todos
16:08:18 gtema_ really?
16:08:25 dtantsur (I'm in DUS starting next week, so do your math!)
16:08:56 gtema_ I am not in DUS, was there already 2 times last week and not willing to go again - too crowded
16:09:00 elmiko i wonder if we could replace the todos with some specific language about there not being any guidance yet? is that any better than just a "todo"
16:09:09 gtema_ but I am on DOST in Sept in Berlin. Are you there?
16:09:29 dtantsur gtema_: in in Dusseldorf the whole September probably
16:09:42 gtema_ beh
16:09:42 dtantsur anybody going to OpenInfra Nordics?
16:09:55 gtema_ beh was not to Nordics
16:10:16 dtantsur I may end up here mid-September, depending on various circumstances

Earlier   Later