Friday, 2019-12-13

*** mriedem has quit IRC00:32
*** senrique__ has joined #openstack-sdks00:33
*** tobberydberg has quit IRC00:35
*** senrique_ has quit IRC00:36
*** tobberydberg has joined #openstack-sdks00:37
*** ricolin has joined #openstack-sdks00:43
*** senrique__ has quit IRC00:51
*** ricolin has quit IRC01:09
*** ricolin has joined #openstack-sdks01:09
*** enriquetaso has joined #openstack-sdks01:17
*** enriquetaso has quit IRC02:00
*** gtema has joined #openstack-sdks02:05
*** gtema has quit IRC02:09
*** gtema has joined #openstack-sdks04:05
*** gtema has quit IRC04:10
*** dave-mccowan has quit IRC05:30
*** gtema has joined #openstack-sdks06:06
*** ricolin has quit IRC06:10
*** gtema has quit IRC06:11
*** logan- has quit IRC07:09
*** logan_ has joined #openstack-sdks07:10
*** logan_ is now known as logan-07:10
*** gtema has joined #openstack-sdks07:47
*** gtema has quit IRC07:59
*** gtema has joined #openstack-sdks07:59
*** ricolin has joined #openstack-sdks08:06
*** ricolin has quit IRC08:06
*** ricolin has joined #openstack-sdks08:07
*** slaweq has quit IRC08:21
*** jpich has joined #openstack-sdks08:29
openstackgerritVishakha Agarwal proposed openstack/python-openstackclient master: Adding options to user cli
*** jangutter has joined #openstack-sdks08:33
*** tosky has joined #openstack-sdks08:40
*** slaweq has joined #openstack-sdks08:42
*** ricolin has quit IRC08:47
*** ralonsoh has joined #openstack-sdks08:49
*** jpena|off is now known as jpena08:54
*** yolanda has quit IRC10:53
*** ricolin has joined #openstack-sdks10:59
*** ricolin_ has joined #openstack-sdks11:02
*** ricolin has quit IRC11:04
openstackgerritArtem Goncharov proposed openstack/osc-lib master: Add get_osc_show_columns_for_sdk_resource function
*** ricolin_ has quit IRC11:18
*** yolanda has joined #openstack-sdks11:25
*** jangutter has quit IRC11:47
*** jangutter_ has joined #openstack-sdks11:47
*** dtantsur|afk is now known as dtantsur12:02
*** jpena is now known as jpena|lunch12:29
*** mgoddard has quit IRC12:30
*** dave-mccowan has joined #openstack-sdks12:40
*** mgariepy has joined #openstack-sdks12:40
*** jpich has quit IRC12:59
*** goldyfruit has joined #openstack-sdks13:07
*** mgoddard has joined #openstack-sdks13:21
*** gtema has quit IRC13:25
*** jangutter_ is now known as jangutter13:30
*** jpena|lunch is now known as jpena13:37
*** lbragstad has joined #openstack-sdks13:48
*** mriedem has joined #openstack-sdks14:00
*** gtema has joined #openstack-sdks14:06
*** gtema has quit IRC14:08
*** gtema has joined #openstack-sdks14:09
openstackgerritMerged openstack/openstacksdk master: Remove duplicate job definition
*** dmellado has quit IRC14:36
*** enriquetaso has joined #openstack-sdks14:37
*** dmellado has joined #openstack-sdks14:39
*** lbragstad has quit IRC15:47
*** dtroyer has quit IRC15:52
*** ricolin_ has joined #openstack-sdks15:53
*** enriquetaso has quit IRC16:06
mriedemefried: mordred: see the question in the ML - i'm not sure how a volume-backed server in the sdk is represented for the Server.image attribute because the sdk defines that as an Image type but for a volume-backed server the actual server.image response body param is an empty string16:11
efriedack, I'll have to get back to that later.16:12
*** efried is now known as efried_afk16:12
mordredmriedem: I'll have to go dig around (and look at that) - I know for server creation we have a large pile of logic16:12
mordredin the resource layer there - we have image = resource.Body('image', type=image.Image16:14
mordredso that's going to mean the sdk is going to pass the empty string value to the Image constructor - meaning that code looking for not image is not going to work16:14
mordredhowever - that should be a ludicrously empty Image with an id of ''16:15
gtemaI'm not really sure, image_id will be empty16:15
mordredso maybe an easy fix would be if not server.image.id16:15
mordredor test for image_id16:15
mordred(is imageRef also an empty string in the response?)16:15
gtemain my cloud even for servers booted from image I still see image in the response16:15
mriedemyeah i at least picked up that the Image field isn't going to be Falsey16:16
mriedemgtema: that would be expected...16:16
mordrednow - maybe we should add some logic to look for an empty string image and set Image to None if so16:16
mriedemthe servers body response will always have 'image'; if it's volume-backed the value is '', else it's a dict16:16
mriedemmordred: or some sugar on the Server object like is_volume_backed that hides those details based on the internal image object?16:17
mordredmriedem: that's a great idea16:17
mriedembecause it is a confusing API wrinkle few know about16:18
* mordred is trying to think where he has a volume backed server - vexxhost probably ...16:18
mriedemin your pet nfv cloud duh16:19
gtemamordred: but I mean for volume booted image is not an empty struct in my case16:21
gtemavolume booted server16:21
mordredactually - server.image is totally truthy16:21
gtemaand this is against mriedem statement16:21
mriedemshow me a raw GET /servers/<server_id> response of a volume-backed server that you have16:22
mordredI just grabbed a volume-backed server and it has an empty server.image property from sdk16:22
mriedemwhere volume-backed means the server was created with a block_device_mapping_v2 list where one entry has boot_index=0 and destination_type=volume16:22
mordredone sec - I'll reproduce with http calls16:22
gtemaformatted output
*** stephenfin is now known as finucannot16:25
gtemaand only request about one of the volumes contain volume_image_metadata16:26
mriedemgtema: can you show me the block_device_mappings table entries for that server?16:26
mriedem*block_device_mapping table16:26
mordredso - in my case at least, the server returned from sdk correctly has an empty image property16:26
gtemain the second past - os-extended-volumes:volumes_attached16:26
mriedemgtema: that doesn't mean the server is volume-backed, it just means there are volumes attached16:27
mordredOH FOR T?HE LOVE OF16:27
mordredwhy is this not doing /detail ?16:27
mriedemas i said, volume-backed == boot_index=0 and destination_type=volume16:27
gtemaone of them is with volume_image_metadata16:27
mriedemthat doesn't matter16:27
mriedemi would need to see your block_device_mapping entries for that server16:28
gtemaif only I could get them that easy16:28
mordredgtema: can we change sdk to NEVER make server calls with /detail ?16:29
mordredthe non /detail response is useless16:29
mordredland I don't se a way to make find_server do a /detail call16:29
gtemamy response is actually from the server GET16:30
mordredyah - 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 it16:30
mordredso now I'm fixated on that horrible experience16:30
gtemado you want to switch your focus?16:31
mordredok. NOW - I confirm that none of the servers I was looking at are actually volume backed16:32
mordredand I need to go find a new one16:33
mordredc.compute.servers() does details calls - so looking at the results from that gives you valid server objects16:33
mordredI 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
mriedemmordred: note that /detail is when listing servers so that's not what you want16:34
gtemawhich are at least in my case always with image filled independently on volume_backed or not16:34
mriedemyou want GET /server/<server_id> for find_server16:34
mriedemthat has the details16:34
mordredmriedem: it totally doesn't16:34
mriedemGET /servers/ is listing servers w/o details16:34
mordredwell - ok - let's pause here for a sec16:34
mriedem is the mostly useless thing16:35
mordredwhen I do the sdk call that is the equiv of GET /server/<server_id> I'm getting a Server with an empty image property16:35
mordredwhen I do the equiv of /servers/details - I get image with an Image object in it16:35
mordredfor the same servers16:35
mordredso - let's consider that a bug that should be addressed16:35
gtemawhat exactly do you consider as a bug?16:36
mordredI would expect find_server(server_id) to return an object that is similar to servers()[0]16:36
mordredrather than a minimal object wiht almost no information16:36
*** ricolin_ has quit IRC16:36
mordredbecause wht is returned by find_server is USELESS16:36
gtemaok, I was never using it in this context, but from the code looks like that16:38
mordredyeah - I've never used it either :)16:38
mordredok - I switched clouds and found one that is volume backed16:38
mordredand can confirm that it gets an empty Image object16:41
gtemagood for you, this is not same for me16:41
gtemabut you know my cloud - there are definitely some additional patches on top16:42
mordredgtema: yah16:43
mordredmriedem: how do I get the block_device_mapping for a server?16:43
gtemaso for me the only "reliable" way is that one of 2 volumes attached shows really image information16:43
mordredgtema: what does the image field show?16:44
gtemalinks + id16:44
mordredgtema: and you're sure you did boot-from-volume on that server?16:44
mordredcause that sounds like boot-from-image with a root volujme16:45
gtemathat is the only chance to get different size for the root volume16:45
mordredno - you can do boot-from-image and pass a voluem to be used as the root filesystem16:45
gtemais than boot from volume something different?16:45
gtemaah, ok16:46
mordredor - I think it is16:46
mordredI might be smoking crack16:46
mordredmriedem: ?16:46
mordredgtema: it all has to do with block_device_mapping - which is hella com[ex16:46
gtemaboot-from-image seems exactly what I was doing16:46
mriedemmordred: the actual volumes attached to the server?16:46
mriedemthat doesn't tell you the boot_index though16:47
mriedemthat's in thedb16:47
gtemawell, my "assumption" is that I was passing (or relying on SDK to do this) block_device_mapping with boot volume from image16:47
mordredmriedem: I don't have access to the db16:47
mriedemboot_index=0 and destination_type=volume == volume-backed server16:47
mriedemwas pretty sure we had a spec at one point to expose the boot_index in that api but must have never landed16:48
mordredok - sdk created servers with boot from volume do boot_index=0 and destination_type=volume for both16:48
mriedemoh this was the spec that was going to expose boot_index in the volume attachments api but never landed
*** finucannot is now known as stephenfin16:51
mordredhere's what we do create-side:
gtemajust now tried to create separately volume from image, and using OSC create server from volume:
gtemastill image is filled17:02
gtema'block_device_mapping_v2': [{'uuid': 'd30f638f-655d-4999-9bb7-205b3c082a0e', 'boot_index': '0', 'source_type': 'volume', 'destination_type': 'volume'}]17:03
mordredgtema: your cloud is weird man17:11
mordredgtema: what's in image?17:11
mordredthat's what you created the volume from?17:11
gtemayes - pure cirros image17:11
gtemanot even our customized one17:12
mordredand the image field in the serer record shows cirror even though you did that boot_index / destination_type above?17:12
gtemaI find it useful17:12
gtemait might be not what is expected, but really useful17:13
gtemawhat might be also different - it should be somewhere on Queens level17:13
mordredyeah - except now it's hard to know if it's a BFV ... :)17:13
gtemaagree. But according to api-ref: The image object might be an empty string when you boot the server from a volume.17:14
*** enriquetaso has joined #openstack-sdks17:19
gtemamordred, btw thanks for comment in image patch. It's not what I was expecting, but ok.17:19
*** jangutter has quit IRC17:25
mordredgtema: 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:25
mordredit's definitely not a thing *I* want to use17:26
gtemaI'm going to push patch to SDK soon, while it again affect lot, seems to be pretty strait forward17:26
gtemawould be nice to add src-sdk job to OSC not to depend on release17:28
*** openstackgerrit has quit IRC17:29
*** openstackgerrit has joined #openstack-sdks17:32
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: Support uploading image from data and stdin
gtemaneed to fall out. See ya17:33
mriedem"_MIGHT__" - the api-ref wording shouldn't probably say that17:34
mriedemit will be an empty string if bfv17:34
*** lbragstad has joined #openstack-sdks17:39
*** senrique_ has joined #openstack-sdks17:39
gtemamriedem, according to this block image_ref is populated in my case when BFV. Can this happen in some cases?17:40
gtemaI have no access to sources, but will try to figure out17:40
*** dtantsur is now known as dtantsur|afk17:40
mriedemit shouldn't be i don't think
gtemameans some extra patch on my cloud17:42
mriedemmaybe a problem when creating a server with an image specified and a bdm list, or that17:42
mriedembut when booting from volume the specified imageRef should be ignored17:42
*** mriedem is now known as mriedem_away17:42
*** enriquetaso has quit IRC17:42
*** gtema has quit IRC17:42
*** cmurphy is now known as cmorpheus17:43
*** jpena is now known as jpena|off17:53
*** melwitt is now known as jgwentworth17:57
*** gtema has joined #openstack-sdks18:18
*** gtema has quit IRC18:23
*** ralonsoh has quit IRC18:30
*** lbragstad has quit IRC18:41
*** lbragsta_ has joined #openstack-sdks18:41
*** yolanda has quit IRC18:43
*** tosky has quit IRC18:57
*** gtema has joined #openstack-sdks19:13
*** gtema has quit IRC19:19
*** mriedem_away has quit IRC19:29
*** mriedem has joined #openstack-sdks19:31
*** lbragsta_ is now known as lbragstad19:31
*** efried_afk is now known as efried19:32
*** senrique__ has joined #openstack-sdks19:39
*** lbragsta_ has joined #openstack-sdks19:40
*** senrique_ has quit IRC19:42
*** lbragstad has quit IRC19:43
*** gtema has joined #openstack-sdks19:59
*** gtema has quit IRC20:06
*** gmann is now known as gmann_afk20:13
*** lbragstad has joined #openstack-sdks20:42
*** lbragsta_ has quit IRC20:44
*** gtema has joined #openstack-sdks20:50
*** senrique__ has quit IRC20:52
*** gtema has quit IRC20:55
*** gtema has joined #openstack-sdks21:05
openstackgerritKeith Berger proposed openstack/python-openstackclient master: WIP:Fix openstack server list --deleted --marker option
*** gtema has quit IRC21:11
*** gtema has joined #openstack-sdks21:17
*** gtema has quit IRC21:24
*** gtema has joined #openstack-sdks21:34
*** gtema has quit IRC21:38
*** lbragstad has quit IRC21:40
*** lbragstad has joined #openstack-sdks21:42
*** gtema has joined #openstack-sdks21:54
*** gtema has quit IRC22:02
*** logan- has quit IRC22:04
*** logan- has joined #openstack-sdks22:06
*** slaweq has quit IRC22:14
*** KeithMnemonic1 has joined #openstack-sdks22:15
*** KeithMnemonic has quit IRC22:19
*** lbragsta_ has joined #openstack-sdks22:42
*** lbragstad has quit IRC22:43
*** gtema has joined #openstack-sdks22:51
*** lbragsta_ has quit IRC22:54
*** mriedem has quit IRC22:54
*** gtema has quit IRC22:55
openstackgerritKeith Berger proposed openstack/python-openstackclient master: WIP:Fix openstack server list --deleted --marker option
*** gtema has joined #openstack-sdks23:12
*** gtema has quit IRC23:17
*** KeithMnemonic1 has quit IRC23:19
*** gtema has joined #openstack-sdks23:57

Generated by 2.15.3 by Marius Gedminas - find it at!