Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-13
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 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?

Earlier   Later