| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-11 | |||
| 11:59:54 | gtema | yeah, would need to | |
| 12:00:55 | mordred | you know what - maybe I should write a quick spec with the thoughts that were in my head WRT caching and we can talk it through and come up with an actual plan | |
| 12:01:29 | gtema | btw, racks support creating server with block_device_mapping2. Currently we use os-volumes_boot if bdm_v2 is present in params | |
| 12:01:39 | gtema | for caching - cool | |
| 12:01:42 | gtema | let's do this | |
| 12:01:50 | mordred | \o/ | |
| 12:02:24 | mordred | so - I'm also thinking - the support you added for having a cloud/vendor-specific driver that overrides some of the proxies ... | |
| 12:02:39 | gtema | :D | |
| 12:02:46 | mordred | maybe it would be cleaner to extract the rackspace-specific logic we have into a rackspace driver | |
| 12:03:46 | gtema | the ones "originated" all OpenStack are now a separate incompatible driver ??? | |
| 12:04:00 | mordred | yeah. it's "funny" | |
| 12:04:14 | mordred | but we carry a lot of logic that's just for them | |
| 12:04:24 | gtema | but yes, we can start really packing all of that into "drivers" | |
| 12:04:32 | mordred | like - the task import stuff - it's technically in upstream glance, but it's untestable in devstack | |
| 12:06:18 | gtema | I'm back in 10-20 min | |
| 12:18:11 | gtema | am back | |
| 12:19:20 | mordred | just added the call from 0.27.0 | |
| 12:20:11 | gtema | so it's really just "Accept:" | |
| 12:21:29 | gtema | well and then the order of "path" and "value" for each item | |
| 12:22:59 | mordred | I'm thinking maybe it's something to do with call sequencing | |
| 12:23:09 | mordred | I'm going to re-run latest logging to a file | |
| 12:23:17 | gtema | if you quickly remove line 284 in image/v2/image.py (setting Accept) to be also sure | |
| 12:23:30 | mordred | yeah - I did that yesterday | |
| 12:23:34 | gtema | ok | |
| 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 | |