Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-11
13:12:02 gtema should we then force all the props before the line 277 (v2/_proxy) to update_image to be strings?
13:12:37 gtema or probably better in v2/image/_prepare_request (if patch ...)
13:13:31 gtema who is setting xenapi_ise_agent?
13:13:36 gtema nodepool?
13:15:37 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Filter properties through make_v2_image_params https://review.opendev.org/664582
13:15:58 mordred gtema: I *think* that ^^ should do the trick (looking at shade vs. current code, we're missing that call in that location)
13:16:17 mordred gtema: but - the things you were saying are likely a *better* approach
13:16:34 mordred gtema: xenapi_use_agent is actually set in the vendor profile of rackspace
13:16:35 gtema yes, and I remember explicitely skipping it and relying to the general "patch" in the resource
13:17:08 mordred oh. you know - it's set as boolean in the vendor file
13:17:18 mordred maybe let's try just updating that to "False"
13:17:27 gtema that's what I also mean. I think it will help either
13:17:53 mordred I'm going to try patching that (the vendor profile) and trying another upload
13:18:23 gtema and probably it is a better place to fix. Normal patch is just comparing two things and generates a diff out of it.
13:18:27 mordred yah
13:20:42 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Set xenapi_use_agent to "False" instead of false https://review.opendev.org/664585
13:22:18 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Set xenapi_use_agent to "False" instead of false https://review.opendev.org/664585
13:23:13 mordred also - how is this just a raw 400 error
13:23:25 gtema LOL
13:23:29 gtema it's Glance
13:23:35 mordred good point
13:31:13 gtema mordred: http://paste.openstack.org/show/752742/ - a current diff for using resource in cloud.server
13:31:20 gtema what do you think about it?
13:36:10 gtema btw, if vendor fix works - nodepool should also get "aka" change included, since it will fix image checksum verification
13:36:44 mordred ++
13:38:03 mordred I think that's looking good. it reminds me - I think as a followup, we should start using Flavor and SecurityGroup and Image resource objects in server.flavor, server.security_groups and server.image - and probably same for volume
13:38:20 mordred might be nicer than just a munch
13:38:49 gtema yeah, but be aware of caching - it does not support Resource objects properly as of now
13:39:07 mordred oh yeah - definitely a "for later" sort of thing
13:39:19 gtema yupp
13:39:55 gtema but still here for the server - I need to do a "dummy" normalization to fix image and some other stuff
13:40:20 mordred YES - the "False" patch fixed it
13:40:30 gtema that's great
13:40:34 mordred it is.
13:40:36 mordred it's absurd
13:40:37 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: WIP Use resource layer for compute.server cloud methods https://review.opendev.org/664593
13:40:38 mordred but it's great
13:41:19 gtema sure. That's why in SDK we try to fix things, so that end-user stuff should not cope with those things
13:41:40 mordred ++
13:42:09 gtema the patch above - it shows current _normalize_server to make it "more_or_less" comparable with current behavior
13:42:49 mordred Shrews, dtantsur: if you have a sec, would you look at https://review.opendev.org/#/c/663846/ - we need to cut a point release with the rackspace fix and it would be nice to get the aka fix in to fix checksumming too
13:43:19 dtantsur will try to, a bit busy today though
13:43:37 gtema dtantsur: those a "one-liners" ;-)
13:43:49 gtema hehe, almost
13:45:41 Shrews mordred: which of those fixes is the rackspace fix?
13:45:56 gtema https://review.opendev.org/664593
13:46:07 gtema nope - https://review.opendev.org/#/c/664585
13:46:24 mordred yeah. 664585 is the one
13:46:28 mordred Shrews: you're really going to enjoy it
13:48:57 Shrews all of those "While we are here" things would be easier to review as separate reviews
13:49:30 gtema sure, the thing is that exactly this fix found the issue
13:51:17 Shrews access_ipv4 = resource.Body('accessIPv4', aka='accessIPv4')
13:51:22 Shrews why is that aka necessary?
13:51:49 gtema that'S a wrong patch you look at. Here we want to return Resources in the cloud layer. However currently
13:52:08 gtema the cloud layer for servers return things with "bad names"
13:52:38 gtema and not to break compatibility for current users we need to expose attributes under old names
13:53:05 gtema so resource['accessIPv4'] returns something reasonable
13:54:55 gtema Shrews: the most interesting part of the story here is currently exposed attribute 'adminPass', which we do not want to see in SDK as regular attribute
14:41:08 Shrews mordred: i think i groked enough of 846 to vote on it
15:21:18 obre Are the python-sdk compatible with multiple domains in keystonev3? I am struggeling to use the sdk to retrieve users.
15:23:20 obre If I use an object returned from "openstack.connect" (an openstack.connection.Connection) called c i can get a user where I know the ID with "c.identity.find_user(userid)", but I cannot retrieve a user where I just know the username.
15:23:36 obre How are we supposed to search for a user using the name?
15:24:39 obre "c.identity.find_user(username, domain_id = domain.id)" does not help me either.
15:25:04 obre I simply get a None returned.
15:25:44 obre Retrieving users from the default-domain works though.
15:30:50 mordred obre: it should be compatible with multiple domains, althoguh I haven't done a lot of using that myself. perhaps mnaser or cmurphy knows more
15:31:26 mnaser obre: did you enable logging to see what requests are happening?
15:32:14 gtema I was experiencing nice nasty issue, that you need to modify your connection to get domain_scoped token
15:33:01 gtema and basically there is no easy way to establish connection and state which scope you want to connect to
15:33:32 gtema This leads to need of having multiple connection with/without user_project_name/id and selecting appropriate
16:06:15 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: WIP Use resource layer for compute.server cloud methods https://review.opendev.org/664593
16:09:04 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Use resource layer for compute flavors https://review.opendev.org/650903
16:52:50 openstackgerrit Merged openstack/openstacksdk master: Set xenapi_use_agent to "False" instead of false https://review.opendev.org/664585
17:06:56 openstackgerrit Merged openstack/openstacksdk master: Add access alias (aka) for the resource attributes https://review.opendev.org/663846
19:02:33 mordred remote: https://review.opendev.org/664671 Release 0.31.1 of openstacksdk
20:26:46 efried mordred: argh, I just saw that ^, *just* pushed a change to use 0.31.0. What was wrong with .0?
20:26:59 efried anything I'm going to care about?
20:30:23 efried mordred: Also, in case you care, I figured out why I had to bump the minimum for os-service-types to fix the lower-constraints job in nova for the "placement uses sdk" patch. If you care, read on:
20:30:24 efried We were previously requiring a minimum ost from before placement extraction, so placement's "project" was still "nova", so we were looking for placement's adapter creds in the [nova] section rather than the [placement] section, but because we were only at 0.30.0 we weren't raising an error at that point, just using defaults.
20:38:21 mordred efried: nothing you're goign to care about - it's a Rackspace public cloud profile issue
20:38:30 efried cool
20:38:47 mordred efried: ah - makes sense re: ost
21:00:34 efried mordred: incidentally, it looks like everything related to clouds.yaml-from-nova is going to get punted for a while.
21:10:21 mordred efried: ok.
21:54:14 mriedem dtroyer: mordred: can one of you abandon this now? https://review.opendev.org/#/c/460059/
21:55:17 mriedem and https://review.opendev.org/#/c/627801/
21:55:28 mriedem and https://review.opendev.org/#/c/589012/
21:55:56 mriedem those are all related to the same thing that i fixed already https://review.opendev.org/#/c/659382/
21:57:26 dtroyer mriedem: yes, I was planning to do that, just haven't gotten far enough down on the list
22:00:09 mriedem ack
#openstack-sdks - 2019-06-12
07:53:04 obre mnaser: Yes. And keystone reports "no user with username found" for the request looking up the user. It seems that it only works in domains with less than 100 users; or for the 100 first users in a domain.
07:53:34 obre c.list_users(domain_id='<ID>', username='foo') works though! So I have a workaroung :)
07:53:42 obre s/ng/nd/
07:54:00 dtantsur mordred: could you check https://github.com/ansible/ansible/pull/54463 please? I've realized it hasn't merged yet :(
08:26:15 dtantsur mordred: also, we seem to have screwed up something around version discovery: NotSupported: The baremetal service for envvars: exists but does not have any supported versions.
08:26:23 dtantsur this is with --os-auth-type none
08:30:11 gtema I do also have troubles with ver discovery
08:30:29 gtema and it might be really something even in ks1
08:32:48 dtantsur also this is very helpful: http://paste.openstack.org/show/752794/ :(
08:45:33 openstackgerrit Dmitry Tantsur proposed openstack/osc-lib master: Avoid misleading error message when using auth_type=none in clouds.yaml https://review.opendev.org/664830

Earlier   Later