Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-13
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
17:37:47 mriedem https://review.opendev.org/#/c/698976/
17:40:17 gtema mriedem, according to this block image_ref is populated in my case when BFV. Can this happen in some cases?
17:40:36 gtema I have no access to sources, but will try to figure out
17:41:38 mriedem it shouldn't be i don't think https://github.com/openstack/nova/blob/2f0f8b8cf13b7441ce6a7a524b33d30d40f1d468/nova/compute/api.py#L1433
17:41:50 gtema ok
17:42:04 gtema means some extra patch on my cloud

Earlier   Later