Earlier  
Posted Nick Remark
#openstack-sdks - 2019-08-29
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
16:16:09 elmiko efried: my concern here is removing the "TODO" language from the docs and migrating that into bugs
16:16:48 efried I like the idea of keeping TODOs in docs, because they're more likely to be noticed by people consuming the docs, and more noticed is more likely to be acted upon.
16:16:48 gtema_ currently in SDK we enforce "Accept: " for head requests and for create object
16:16:51 elmiko efried: ahh, i see though, you are saying we should push through some of these long standing doc patchs?
16:17:00 efried yes elmiko, this ^
16:17:14 efried They're stagnant because they're so huge that nobody wants to review them.
16:17:18 elmiko my only problem with that notion is that they have been there for a long time and no one has acted on them
16:17:24 dtantsur I'm not convinced anybody will ever fix TODOs that we don't fix
16:17:27 elmiko the todos that is
16:17:32 elmiko dtantsur: ++

Earlier   Later