| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-12 | |||
| 17:13:27 | pabelanger | I'm not sure I'd try to use molecule... personally, I haven't see much work on ansible side to update it for collections | |
| 17:13:30 | mordred | that's how we unittest modules in zuul-jobs | |
| 17:14:02 | mordred | pabelanger: yah - also molecule seems a bit focused on being able to make test envs for you and stuff- I don't know that it's a great fit here | |
| 17:14:09 | pabelanger | mordred: yah, it would be great to some how loop that into a test runner, for both zuul and local | |
| 17:14:22 | mordred | pabelanger: I think we can do that pretty easily | |
| 17:14:31 | pabelanger | +1 | |
| 17:14:39 | mordred | if you run stestr in zuul-jobs it'll run those unit tests | |
| 17:14:51 | pabelanger | oh, today? | |
| 17:14:53 | pabelanger | nice | |
| 17:14:57 | pabelanger | that is what I want to do for network | |
| 17:15:04 | mordred | yeah | |
| 17:15:17 | mordred | it'll need to be slightly adapter - but it should be mostly cargo-cultable | |
| 17:15:23 | pabelanger | then, even add support for ansible-playbook and inventory file, like we did with zuul functional testing | |
| 17:15:29 | mordred | tests/test_discovery.py is what drives finding the tests to run | |
| 17:15:33 | mordred | ++ | |
| 17:16:49 | pabelanger | ack | |
| #openstack-sdks - 2019-12-13 | |||
| 08:31:58 | openstackgerrit | Vishakha Agarwal proposed openstack/python-openstackclient master: Adding options to user cli https://review.opendev.org/697444 | |
| 11:15:56 | openstackgerrit | Artem Goncharov proposed openstack/osc-lib master: Add get_osc_show_columns_for_sdk_resource function https://review.opendev.org/698874 | |
| 14:32:57 | openstackgerrit | Merged openstack/openstacksdk master: Remove duplicate job definition https://review.opendev.org/698057 | |
| 16:11:19 | mriedem | efried: mordred: see the question in the ML - i'm not sure how a volume-backed server in the sdk is represented for the Server.image attribute because the sdk defines that as an Image type but for a volume-backed server the actual server.image response body param is an empty string | |
| 16:12:11 | efried | ack, I'll have to get back to that later. | |
| 16:12:13 | mordred | mriedem: I'll have to go dig around (and look at that) - I know for server creation we have a large pile of logic | |
| 16:14:21 | mordred | in the resource layer there - we have image = resource.Body('image', type=image.Image | |
| 16:14:53 | mordred | so that's going to mean the sdk is going to pass the empty string value to the Image constructor - meaning that code looking for not image is not going to work | |
| 16:15:20 | mordred | however - that should be a ludicrously empty Image with an id of '' | |
| 16:15:36 | gtema | I'm not really sure, image_id will be empty | |
| 16:15:39 | mordred | so maybe an easy fix would be if not server.image.id | |
| 16:15:45 | mordred | or test for image_id | |
| 16:15:54 | mordred | (is imageRef also an empty string in the response?) | |
| 16:15:55 | gtema | in my cloud even for servers booted from image I still see image in the response | |
| 16:16:07 | mriedem | yeah i at least picked up that the Image field isn't going to be Falsey | |
| 16:16:12 | mordred | yeah | |
| 16:16:32 | mriedem | gtema: that would be expected... | |
| 16:16:34 | mordred | now - maybe we should add some logic to look for an empty string image and set Image to None if so | |
| 16:16:57 | mriedem | the servers body response will always have 'image'; if it's volume-backed the value is '', else it's a dict | |
| 16:17:43 | mriedem | mordred: or some sugar on the Server object like is_volume_backed that hides those details based on the internal image object? | |
| 16:17:53 | mordred | mriedem: that's a great idea | |
| 16:18:10 | mriedem | because it is a confusing API wrinkle few know about | |
| 16:18:15 | mordred | yup | |
| 16:19:51 | mriedem | in your pet nfv cloud duh | |
| 16:21:21 | gtema | mordred: but I mean for volume booted image is not an empty struct in my case | |
| 16:21:31 | gtema | volume booted server | |
| 16:21:44 | mordred | actually - server.image is totally truthy | |
| 16:21:47 | gtema | and this is against mriedem statement | |
| 16:22:30 | mriedem | show me a raw GET /servers/<server_id> response of a volume-backed server that you have | |
| 16:22:49 | mordred | I just grabbed a volume-backed server and it has an empty server.image property from sdk | |
| 16:22:54 | mriedem | where volume-backed means the server was created with a block_device_mapping_v2 list where one entry has boot_index=0 and destination_type=volume | |
| 16:22:58 | mordred | one sec - I'll reproduce with http calls | |
| 16:23:15 | gtema | http://paste.openstack.org/show/787562/ | |
| 16:24:47 | gtema | formatted output http://paste.openstack.org/show/787563/ | |
| 16:26:02 | mordred | http://paste.openstack.org/show/787564/ | |
| 16:26:03 | gtema | and only request about one of the volumes contain volume_image_metadata | |
| 16:26:12 | mriedem | gtema: can you show me the block_device_mappings table entries for that server? | |
| 16:26:38 | mriedem | *block_device_mapping table | |
| 16:26:42 | mordred | so - in my case at least, the server returned from sdk correctly has an empty image property | |
| 16:26:52 | gtema | in the second past - os-extended-volumes:volumes_attached | |
| 16:27:27 | mriedem | gtema: that doesn't mean the server is volume-backed, it just means there are volumes attached | |
| 16:27:30 | mordred | OH FOR T?HE LOVE OF | |
| 16:27:35 | mordred | why is this not doing /detail ? | |
| 16:27:36 | mriedem | as i said, volume-backed == boot_index=0 and destination_type=volume | |
| 16:27:49 | gtema | one of them is with volume_image_metadata | |
| 16:27:58 | mriedem | that doesn't matter | |
| 16:28:09 | mriedem | i would need to see your block_device_mapping entries for that server | |
| 16:28:44 | gtema | if only I could get them that easy | |
| 16:29:20 | mordred | gtema: can we change sdk to NEVER make server calls with /detail ? | |
| 16:29:25 | mordred | the non /detail response is useless | |
| 16:29:52 | mordred | land I don't se a way to make find_server do a /detail call | |
| 16:30:03 | gtema | my response is actually from the server GET | |
| 16:30:39 | mordred | yah - I'm just trying to explore what properties I get from the actual sdk interaction - and the first issue is that I get back an almost empty server with no intormation in it | |
| 16:30:50 | mordred | so now I'm fixated on that horrible experience | |
| 16:31:28 | gtema | do you want to switch your focus? | |
| 16:32:57 | mordred | ok. NOW - I confirm that none of the servers I was looking at are actually volume backed | |
| 16:33:04 | mordred | and I need to go find a new one | |
| 16:33:35 | mordred | c.compute.servers() does details calls - so looking at the results from that gives you valid server objects | |
| 16:34:06 | mordred | I will now look for a different cloud where I have booted a volume backed server to I can look at the question at hand :) | |
| 16:34:12 | mriedem | mordred: note that /detail is when listing servers so that's not what you want | |
| 16:34:18 | gtema | which are at least in my case always with image filled independently on volume_backed or not | |
| 16:34:21 | mriedem | you want GET /server/<server_id> for find_server | |
| 16:34:23 | mriedem | that has the details | |
| 16:34:29 | mordred | mriedem: it totally doesn't | |
| 16:34:33 | mriedem | GET /servers/ is listing servers w/o details | |
| 16:34:45 | mordred | well - ok - let's pause here for a sec | |
| 16:34:45 | mriedem | https://docs.openstack.org/api-ref/compute/#show-server-details | |
| 16:35:07 | mriedem | https://docs.openstack.org/api-ref/compute/#list-servers is the mostly useless thing | |
| 16:35:16 | mordred | when I do the sdk call that is the equiv of GET /server/<server_id> I'm getting a Server with an empty image property | |
| 16:35:32 | mordred | when I do the equiv of /servers/details - I get image with an Image object in it | |
| 16:35:35 | mordred | for the same servers | |
| 16:35:46 | mordred | so - let's consider that a bug that should be addressed | |
| 16:36:07 | gtema | what exactly do you consider as a bug? | |
| 16:36:32 | mordred | I would expect find_server(server_id) to return an object that is similar to servers()[0] | |
| 16:36:45 | mordred | rather than a minimal object wiht almost no information | |
| 16:36:57 | mordred | because wht is returned by find_server is USELESS | |
| 16:38:04 | gtema | ok, I was never using it in this context, but from the code looks like that | |
| 16:38:45 | mordred | yeah - I've never used it either :) | |
| 16:38:57 | mordred | ok - I switched clouds and found one that is volume backed | |
| 16:41:14 | mordred | and can confirm that it gets an empty Image object | |
| 16:41:38 | gtema | good for you, this is not same for me | |
| 16:42:27 | gtema | but you know my cloud - there are definitely some additional patches on top | |
| 16:43:21 | mordred | gtema: yah | |
| 16:43:50 | mordred | mriedem: how do I get the block_device_mapping for a server? | |