| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-13 | |||
| 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 | mriedem | https://docs.openstack.org/api-ref/compute/#show-server-details | |
| 16:34:45 | mordred | well - ok - let's pause here for a sec | |
| 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? | |
| 16:43:51 | gtema | so for me the only "reliable" way is that one of 2 volumes attached shows really image information | |
| 16:44:23 | mordred | gtema: what does the image field show? | |
| 16:44:39 | gtema | links + id | |
| 16:44:55 | mordred | gtema: and you're sure you did boot-from-volume on that server? | |
| 16:45:08 | gtema | 99.9% | |
| 16:45:21 | mordred | cause that sounds like boot-from-image with a root volujme | |
| 16:45:26 | gtema | that is the only chance to get different size for the root volume | |
| 16:45:44 | mordred | no - you can do boot-from-image and pass a voluem to be used as the root filesystem | |
| 16:45:57 | gtema | is than boot from volume something different? | |
| 16:45:59 | mordred | yes | |
| 16:46:07 | gtema | ah, ok | |
| 16:46:16 | mordred | or - I think it is | |
| 16:46:19 | mordred | I might be smoking crack | |
| 16:46:22 | mordred | mriedem: ? | |
| 16:46:41 | mordred | gtema: it all has to do with block_device_mapping - which is hella com[ex | |
| 16:46:46 | gtema | boot-from-image seems exactly what I was doing | |
| 16:46:56 | mriedem | mordred: the actual volumes attached to the server? | |
| 16:47:07 | mriedem | https://docs.openstack.org/api-ref/compute/#list-volume-attachments-for-an-instance | |
| 16:47:22 | mriedem | that doesn't tell you the boot_index though | |
| 16:47:24 | mriedem | that's in thedb | |
| 16:47:27 | gtema | well, my "assumption" is that I was passing (or relying on SDK to do this) block_device_mapping with boot volume from image | |
| 16:47:45 | mordred | mriedem: I don't have access to the db | |
| 16:47:46 | mriedem | boot_index=0 and destination_type=volume == volume-backed server | |
| 16:48:18 | mriedem | was pretty sure we had a spec at one point to expose the boot_index in that api but must have never landed | |
| 16:48:48 | mordred | ok - sdk created servers with boot from volume do boot_index=0 and destination_type=volume for both | |
| 16:50:34 | mriedem | oh this was the spec that was going to expose boot_index in the volume attachments api but never landed https://specs.openstack.org/openstack/nova-specs/specs/train/approved/detach-boot-volume.html#proposed-change | |
| 16:55:18 | mordred | here's what we do create-side: https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_compute.py#L978-L1049 | |
| 17:02:34 | gtema | just now tried to create separately volume from image, and using OSC create server from volume: http://paste.openstack.org/show/787569/ | |
| 17:02:39 | gtema | still image is filled | |
| 17:03:44 | gtema | 'block_device_mapping_v2': [{'uuid': 'd30f638f-655d-4999-9bb7-205b3c082a0e', 'boot_index': '0', 'source_type': 'volume', 'destination_type': 'volume'}] | |
| 17:11:10 | mordred | gtema: your cloud is weird man | |
| 17:11:18 | gtema | sure | |
| 17:11:20 | mordred | gtema: what's in image? | |
| 17:11:26 | gtema | cirros | |
| 17:11:45 | mordred | that's what you created the volume from? | |
| 17:11:56 | gtema | yes - pure cirros image | |
| 17:12:03 | gtema | not even our customized one | |
| 17:12:25 | mordred | and the image field in the serer record shows cirror even though you did that boot_index / destination_type above? | |
| 17:12:39 | gtema | yes | |
| 17:12:53 | gtema | I find it useful | |
| 17:13:05 | gtema | it might be not what is expected, but really useful | |
| 17:13:29 | gtema | what might be also different - it should be somewhere on Queens level | |
| 17:13:36 | mordred | yeah - except now it's hard to know if it's a BFV ... :) | |
| 17:14:24 | gtema | agree. But according to api-ref: The image object might be an empty string when you boot the server from a volume. | |
| 17:14:28 | gtema | __MIGHT__ | |
| 17:19:22 | gtema | mordred, btw thanks for comment in image patch. It's not what I was expecting, but ok. | |
| 17:25:59 | mordred | gtema: sure nuff - the main thing I'd be opposed to is losing any of the existing sdk functionality ijn chasing support for stdin. If there's a way to support it for osc that doesn't screw up everything else ... I mean, who am I to judge. | |
| 17:26:32 | mordred | it's definitely not a thing *I* want to use | |
| 17:26:45 | gtema | I'm going to push patch to SDK soon, while it again affect lot, seems to be pretty strait forward | |
| 17:26:51 | mordred | cool | |
| 17:28:02 | gtema | would be nice to add src-sdk job to OSC not to depend on release | |
| 17:32:35 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Support uploading image from data and stdin https://review.opendev.org/698972 | |
| 17:33:21 | gtema | need to fall out. See ya | |
| 17:34:17 | mriedem | "_MIGHT__" - the api-ref wording shouldn't probably say that | |
| 17:34:21 | mriedem | it will be an empty string if bfv | |
| 17:35:07 | mriedem | https://github.com/openstack/nova/blob/2f0f8b8cf13b7441ce6a7a524b33d30d40f1d468/nova/api/openstack/compute/views/servers.py#L540 | |