| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-08-29 | |||
| 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 | |
| 16:10:20 | gtema_ | I'm not - only "Deutsche OpenStack Tage" | |
| 16:10:33 | dtantsur | but my primary goal is to find a flat in DUS asap | |
| 16:10:52 | elmiko | ooh, nice dtantsur ! | |
| 16:10:56 | gtema_ | coool | |
| 16:11:57 | dtantsur | elmiko: I suggest we file a bug per each TODO and then follow the same process | |
| 16:12:05 | dtantsur | fix it OR close and remove the todo | |
| 16:12:28 | elmiko | i feel like that is where we are stuck though, the "fix it or forget it" stage | |
| 16:12:48 | elmiko | but, i like the idea of making some bugs to track this better | |
| 16:12:58 | elmiko | well, maybe not better, but just not in the docs themselves | |
| 16:13:20 | dtantsur | yeah | |
| 16:13:49 | gtema_ | ++ | |
| 16:14:52 | elmiko | so, it's a long holiday weekend here in the states, but i will make some actions next week when i return | |
| 16:15:03 | gtema_ | Guys, what do you think about API header “Accept: “? It does not make any sense from my POV and due to some patch/API Gateways in front some of the requests to Swift in my cloud are failing. | |
| 16:15:20 | efried | merge enormous doc patches, even though they're known to be incomplete, as long as they're at least largely technically accurate. open bugs for known gaps therein. | |
| 16:15:54 | dtantsur | gtema_: in what context? in some contexts it does make sense | |
| 16:16:04 | dtantsur | efried: ++ that's what we're discussing | |
| 16:16:07 | gtema_ | i.e. HEAD request | |