Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-11
12:54:08 gtema what I also see in the first trace before GET/PATCH image was first searched in the LIST. Could it "theoretically" be, that the ID changes?
12:59:33 mordred well - but in the failing one we do a GET on the image by id
13:01:09 gtema yes , exactly
13:01:49 mordred {"op": "add", "value": "False", "path": "/xenapi_use_agent"} 0.27.0
13:02:02 mordred {"op": "add", "path": "/xenapi_use_agent", "value": false} 0.31.0
13:02:14 mordred we're passing false as a string in 0.27 and as a bool in 0.31
13:02:23 gtema yeah, I see
13:05:54 mordred in the original _make_v2_image_params - we made sure to str() wrap each item if it wasn't in a specific list
13:06:35 mordred we have the same thing in the image proxy
13:06:42 gtema hmm
13:07:48 mordred we call it in master in _update_image_properties - but then we call self.update_image with the resulting dict - maybe that's flowing it back through the resource mapping and causing the False to get boolean'd
13:08:52 mordred that doesn't make any sense though - xenapi_use_agent isn't a known property - resource shouldn't be transforming its data type
13:09:46 gtema you know everything what's running in the background of all the methods ;-)?
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/

Earlier   Later