| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-11 | |||
| 12:23:37 | mordred | but I can do it again and do the log if we want | |
| 12:24:27 | gtema | would be nice, but if you say it didn't help - not prio | |
| 12:25:09 | gtema | let's then really compare order or calls. However unittest tests this also. And here we had no change | |
| 12:25:36 | mordred | yeah. I was pretty confident in the changes because we have this covered in unittests | |
| 12:29:16 | gtema | latest trace is broken - incomplete | |
| 12:29:45 | mordred | oh yeah? poo - maybe there was a length limit here | |
| 12:29:47 | mordred | hit | |
| 12:30:02 | mordred | http://paste.openstack.org/show/752725/ <-- there's a trimmed version with just the request sequence | |
| 12:31:49 | gtema | the order is same as in tests | |
| 12:32:04 | mordred | yeah | |
| 12:32:44 | mordred | running 0.31.0 now - we'll see how it goes | |
| 12:32:49 | mordred | takes about 20 minutes | |
| 12:32:53 | gtema | ok | |
| 12:48:56 | mordred | http://paste.openstack.org/show/752728/ | |
| 12:49:05 | mordred | there's 0.31.0 sequence - looks the same :( | |
| 12:49:51 | gtema | yeah. Is it now with "Accept: " or without? | |
| 12:53:14 | mordred | with | |
| 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 | |