| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-13 | |||
| 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? | |
| 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 | |
| 17:42:14 | mriedem | maybe a problem when creating a server with an image specified and a bdm list, or that | |
| 17:42:26 | mriedem | but when booting from volume the specified imageRef should be ignored | |
| 21:10:14 | openstackgerrit | Keith Berger proposed openstack/python-openstackclient master: WIP:Fix openstack server list --deleted --marker option https://review.opendev.org/691045 | |
| 23:12:18 | openstackgerrit | Keith Berger proposed openstack/python-openstackclient master: WIP:Fix openstack server list --deleted --marker option https://review.opendev.org/691045 | |
| #openstack-sdks - 2019-12-14 | |||
| 14:14:19 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Support uploading image from data and stdin https://review.opendev.org/698972 | |
| 14:36:07 | openstackgerrit | Artem Goncharov proposed openstack/python-openstackclient master: Switch image to use SDK https://review.opendev.org/650374 | |
| 15:56:51 | mordred | dtantsur|afk: if you get a chance, could you re-review https://review.opendev.org/#/c/698972 ? | |
| #openstack-sdks - 2019-12-15 | |||
| 13:43:50 | openstackgerrit | Vishakha Agarwal proposed openstack/keystoneauth master: [ussuri][goal] Drop python 2.7 support and testing https://review.opendev.org/699121 | |
| 15:19:38 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Remove python2 from project-template https://review.opendev.org/699130 | |
| 15:21:16 | openstackgerrit | Monty Taylor proposed openstack/python-openstackclient master: Stop testing python2 https://review.opendev.org/686590 | |
| 15:21:17 | openstackgerrit | Monty Taylor proposed openstack/python-openstackclient master: Remove python2 from project-template https://review.opendev.org/699131 | |
| 18:24:54 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Stop running python2 test jobs https://review.opendev.org/699132 | |
| 18:24:55 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Remove extra python2 test jobs https://review.opendev.org/699133 | |
| 18:24:55 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Switch stable ansible job to 2.8 https://review.opendev.org/699134 | |
| #openstack-sdks - 2019-12-16 | |||
| 15:58:33 | mordred | Shrews: if you're bored there's a stack of patches ending in https://review.opendev.org/#/c/699134 that should be happy making | |
| 15:59:11 | mordred | Shrews: although I think I should maybe add a release note to one of them | |
| 16:00:44 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Stop supporting python2 https://review.opendev.org/699132 | |
| 16:00:45 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Remove extra python2 test jobs https://review.opendev.org/699133 | |
| 16:00:45 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Switch stable ansible job to 2.8 https://review.opendev.org/699134 | |