| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-03 | |||
| 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 | melwitt | ok, yeah. comment if we do that because otherwise I'm not going to remember why | |
| 19:20:22 | jaypipes | mriedem: awesome. | |
| 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 | 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:43 | tssurya | melwitt: https://bugs.launchpad.net/nova/+bug/1794994 | |
| 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. | |
| 20:11:17 | efried | Gerald would be better equipped to answer this stuff. But he ain't here. | |
| 20:16:33 | edmondsw | mriedem re: bfv for powervm in-tree... I believe the code is close enough that it might work, but it's untested and there is at least one improvement we should make | |