Earlier  
Posted Nick Remark
#openstack-sdks - 2019-12-13
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
16:01:11 mordred gtema: ^^ that stack was green - but I just added a release note to 699132
16:01:41 gtema oki
16:20:19 Shrews mordred: ok
16:33:14 openstackgerrit Keith Berger proposed openstack/python-openstackclient master: WIP:Fix openstack server list --deleted --marker option https://review.opendev.org/691045
19:34:44 openstackgerrit Keith Berger proposed openstack/python-openstackclient master: Fix openstack server list --deleted --marker option https://review.opendev.org/691045
19:59:32 openstackgerrit Merged openstack/openstacksdk master: Remove python2 from project-template https://review.opendev.org/699130
21:49:17 openstackgerrit Keith Berger proposed openstack/python-openstackclient master: Fix openstack server list --deleted --marker option https://review.opendev.org/691045
#openstack-sdks - 2019-12-17
13:40:51 mordred gtema: heya! - wanna +A https://review.opendev.org/#/c/699132 ?
13:41:18 gtema done
13:41:36 gtema a milestone with mixed feeling
13:41:39 mordred \o/
13:41:54 mordred python2 has served us well for many years
13:42:15 gtema sure, and it is still used in the backend of perhaps lots of installations
13:42:20 mordred yup
13:42:25 gtema at least unfortunately my cloud case
13:43:27 mordred yeah - I really wish a default transition to 3 had happened sooner
13:43:56 gtema yes, and perhaps even "harder" to force people
13:43:59 mordred I remember the first python3 summit session - during the *grizzly* summit
13:44:13 Shrews https://pythonclock.org
13:44:24 mordred we could never quite get people to take this one proactively
13:45:11 mordred although I blame rhel7 not shipping with even an optional python3 as a large part of the problem
13:45:24 gtema agree
13:45:29 mordred because for many people that made opting in to python3 a non-starter
13:46:04 gtema and the one available through EPEL (3.4) is not a good deal either
13:47:01 mordred yup
13:47:37 mordred this is an area where I really do think containers improve the story for many use cases
13:47:41 mordred not all
13:47:42 mordred but many
13:48:05 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: Switch image to use SDK https://review.opendev.org/650374
13:48:06 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: Complete switch from glanceclient to SDK for image service https://review.opendev.org/699416
13:48:22 mordred we've been working on switching gerrit to run in a container - and one of the big wins is that we don't have to care what version of java is shipped with the OS we're running on the gerrit server :)
13:49:05 gtema oh god, Java is the same for me. There are definitely still lots of Enterprises running JEE1.6
13:49:26 mordred yup
13:49:43 mordred and - you know - that's fine - build it in your container image and stop caring about it :)
13:49:57 mordred dtroyer: heya - got a sec for an easy one: https://review.opendev.org/#/c/695427/ ?
13:50:16 gtema he, in environments, which still depend on J1.6 there is most likely no container support as well
13:51:56 gtema mordred: please have a look at https://review.opendev.org/#/c/698972/ for stdin support image upload in SDK
13:52:39 mordred gtema: yes - I'm excited about that! (was waiting for the jobs to go green)

Earlier   Later