Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-03
19:09:01 sean-k-mooney "expect Exception as e: return e" is not
19:09:13 nicolasbock Yes of course :)
19:09:45 sean-k-mooney expect Exception: return sys.exc_info() is also fine
19:09:51 spatel sean-k-mooney: "pci=assign-busses,realloc" was causing issue my server got hung at boot, as soon as i remove that it works.. I have HP DL360p G8
19:09:59 dansmith sean-k-mooney: but this result object of yours is just going to swallow the exception that we get from our handler right?
19:10:11 dansmith sean-k-mooney: so it's still pinning the reference to the stack
19:11:09 sean-k-mooney dansmith: ya i was planning to extend it to do the right thing on each python verion.
19:11:17 sean-k-mooney this is only an issue on python2
19:11:29 sean-k-mooney they fix it in python 3 so you can just return the exception
19:11:34 dansmith we could trivially re-construct the exception since we know it inherits from NovaException and has very specific characteristics
19:12:05 dansmith since it's only py2, and since py3 is the future, and since this is a suuuper corner case that only "may" have issues with some GC being delayed... I would tend to punt on caring about this entirely
19:12:06 dansmith but
19:12:13 sean-k-mooney dansmith: yep but if we are going to do that i taught it would be nice to hide that in a result calss that does the right thing
19:12:17 dansmith just re-creating the exception and returning it would be fine for our purposes
19:13:20 melwitt tssurya: sorry, I'm not really getting the usefulness of the single cell scatter-gather from the commit message. how does it help for down cell?
19:13:24 sean-k-mooney spatel: ya dont add that. it was specically to work around a hardware bug in my old servers
19:13:25 dansmith IMHO we can punt and not worry about this
19:13:42 spatel roger!
19:13:52 spatel i took it out
19:14:08 tssurya melwitt: https://review.openstack.org/#/c/591658/3/nova/compute/api.py@2323
19:14:31 tssurya we could just directly use the scatter_gather_cells(), just that it looked bad
19:14:45 mriedem jaypipes: i have crushed your soul https://review.openstack.org/#/c/607626/
19:15:13 melwitt tssurya: I see, to get the automatic "wait for this amount of time before timing out" part. thanks
19:15:14 tssurya melwitt: we will be using it for Instance.get_by_uuid for the nova show part
19:17:25 sean-k-mooney dansmith: so ya ill likely work on https://review.openstack.org/#/c/605251/2 a little more in my spare time later this week as i want that class as a tool in my tool box for the future but we may not need it for this usecase.
19:17:27 tssurya dansmith, sean-k-mooney: so.. which way are are agreeing on ?
19:17:58 dansmith tssurya: I vote for return the exception and boil the ocean later :)
19:18:03 melwitt so what's all this reconstruction talk? in scatter-gather, when we catch the exception from the cell, are you saying we have to do more than just save the "as exp" part?
19:18:33 tssurya dansmith: ack,
19:18:39 dansmith melwitt: we do not
19:18:45 dansmith melwitt: we could trivially if we want
19:18:48 tssurya melwitt: as far as I understood just returning it should be enough
19:18:51 melwitt mmkay
19:19:07 dansmith just return exp.__class__(exp.args) would be enough
19:19:19 dansmith but it'd need a comment about why
19:19:29 dansmith and if we don't, then.. not
19:19:39 melwitt ok, that's what I meant, we can't just return exp, we have to do that step
19:19:51 dansmith we've just spawned a thread at this point, and most of these things are single DB calls, which means the stack being pinned by the exception is tiny
19:20:22 jaypipes mriedem: awesome.
19:20:22 melwitt ok, yeah. comment if we do that because otherwise I'm not going to remember why
19:20:28 sean-k-mooney dansmith: oh so just return a new exception object not the one we caught
19:20:51 jaypipes mriedem: it's hard enough already for me to give a rat's ass about a stable branch. :)
19:21:08 dansmith melwitt: we don't have to do that step.. we can just return exp. If we want, we can do the reconstruction step (and document it)
19:21:09 dansmith melwitt: I would vote for not reconstructing because I think this is super tiny
19:21:22 tssurya dansmith: ah got it
19:21:34 melwitt ack, thank you
19:21:47 tssurya melwitt, sean-k-mooney, dansmith: thanks
19:22:02 dansmith soooo, back to the meeting,
19:22:08 dansmith I will probably be back, if ya'll want to meet
19:22:10 tssurya dansmith: yea are we having one ?
19:22:35 melwitt I'm neutral about meeting. I don't have anything special to talk about
19:22:49 melwitt mriedem might want to talk about cross-cell stuff? I dunno
19:22:56 dansmith mriedem may want to talk about crossing the streams
19:22:58 dansmith yeah, t hat
19:22:59 tssurya I don't have anything special except some silly bugs
19:23:22 melwitt silly bugs? now I'm curious
19:23:25 sean-k-mooney just one other comment we are not holding any locks or file handels correct wehre we raise the exception in the scater gater case?
19:23:43 tssurya melwitt: https://bugs.launchpad.net/nova/+bug/1794994
19:23:43 openstack Launchpad bug 1794994 in OpenStack Compute (nova) "Update the --max-rows parameter description for nova-manage db archive_deleted_rows" [Low,In progress] - Assigned to Surya Seetharaman (tssurya)
19:23:58 tssurya for now I changed it to a doc fix, but I am skeptical about it
19:24:11 dansmith sean-k-mooney: we would have just gotten a result from a threadpool of db workers, and they would almost definitely have re-raised outside of any locks
19:24:31 tssurya it would be just good to have the API table record removal also in the max-rows
19:24:36 tssurya not sure if people care though
19:25:28 tssurya but yea its not super urgent
19:26:01 tssurya okay then I will head home now and will be lurking around during the meeting time in case we decide to have one
19:26:15 melwitt ok, will read through it. the issue is the command output can be confusing given the treatment of the API records
19:26:16 sean-k-mooney dansmith: ok the the stack frame reference keeps stack locals alive including any file handles or locks so can we add a commet the pep issue if we just return the exception just incase we have issue in the future
19:26:25 tssurya melwitt: exactly
19:26:41 dansmith sean-k-mooney: yep
19:27:14 sean-k-mooney dansmith: i think we will be fine but future me would regret not adding it if we ever have to debug it :)
19:28:07 melwitt tssurya: thanks. this is hard for me to imagine because I can't remember what the archive_deleted_rows output looks like :P will look in the code
19:28:32 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: stable-only: fix typo in IVS related privsep method https://review.openstack.org/604817
19:30:45 mriedem melwitt: dansmith: i don't really want to talk about cross-cell resize today probably; i suggested to dansmith that i skim my poc with him over a hangout early next week (i'm out tomorrow and friday)
19:31:06 melwitt k
19:31:09 mriedem tl;dr functional testing shows it working,
19:31:12 mriedem but there are a shit load of todos
19:31:17 mriedem and the patch is over 2K LOC now
19:31:36 mriedem it is definitely not enterprise ready
19:31:41 melwitt lol
19:32:22 mriedem i have also resorted to taking sleep aids to not wake up at 1am thinking about it...
19:34:35 mriedem i've found this helps https://www.youtube.com/watch?v=Lrle0x_DHBM
19:36:13 melwitt heh
19:43:15 sean-k-mooney mriedem: oh youtube look kind of weird to me when its rendering 4:3 aspect ratio videos
19:59:50 mriedem who here knows what actually happens to the guest when you stop/start a vmware/hyperv/xenapi/ironic/powervm VM?
20:00:03 mriedem specifically, the root disk of said VMs if it's volume-backed?
20:00:11 mriedem efried: does powervm in-tree support boot from volume yet?
20:00:30 efried edmondsw: ^
20:00:35 efried looking...
20:05:00 efried mriedem: Does compute set destroy_disks=False to the destroy() method if booted from volume?
20:06:57 efried mriedem: I assume you're trying to find out whether the disk gets destroyed or not.
20:07:12 efried I can tell you this: In tree, we don't destroy volumes.
20:07:28 efried But I don't know whether we support bfv
20:07:38 mriedem efried: no not related to that
20:07:44 mriedem related to https://review.openstack.org/#/c/600628/
20:07:51 mriedem which i haven't -1ed yet but it's coming
20:08:30 mriedem the virt driver doesn't destroy volumes, the compute manager orchestrates the detach and delete if bdm.terminate_on_deletion is True
20:08:50 mriedem i'm mostly wondering if the virt driver will disconnect and reconnect volumes on simple stop/start operatoins
20:08:57 mriedem for libvirt, we do - starting around queens or rocky
20:10:05 efried We don't disconnect anything on power-off
20:10:53 efried That said, I'm not 100% sure the *platform* retains ownership of that resource in such a way that you couldn't attach it to something else while the instance is powered off.

Earlier   Later