| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-03 | |||
| 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 | |
| 20:18:05 | edmondsw | mriedem why would you disconnect and reconnect volumes on stop/start? | |
| 20:20:52 | sean-k-mooney | edmondsw: the libvirt driver destorys the domain and recreates it on start stop | |
| 20:21:06 | edmondsw | right... why? | |
| 20:21:18 | sean-k-mooney | edmondsw: so its proably done as a sideffect of that | |
| 20:21:20 | mriedem | comments inline in that spec | |
| 20:22:29 | sean-k-mooney | edmondsw: legacy reasons but we treat stop like delete as far as libvirt is concerend but we dont delete the disk obviously | |
| 20:23:29 | sean-k-mooney | we do detach all ports, gpus ectra when we shut down the vm but we still retain owner ship of them in placement/the resouce tracker | |
| 20:24:58 | edmondsw | ok. I'll assume "legacy reasons" means there's no reason for other drivers to consider doing that | |
| 20:26:11 | sean-k-mooney | well there is one but its not a good one. if you are using iscsi volumes by detaching the volume on stop it reduces memory uses on the issci server | |
| 20:27:00 | sean-k-mooney | which if its hardware based also means we can potenailly free up other hardware resouces but that also means the vm can fail to start back up if somting else grabs the last slot | |
| 20:27:31 | sean-k-mooney | that said you would have max out your cloud stroage at that point so you have bigger issue then one vm not starting | |
| 20:28:14 | sean-k-mooney | edmondsw: i dont know if there is a actul usecase where you would want to disconnect today but mayber there is | |
| 20:28:31 | edmondsw | sean-k-mooney tx for the explanation | |
| 20:30:34 | sean-k-mooney | i know some people want to be able to do things with bfv root volumes when the instace is offline too but i kindof zoned out at the ptg for that conversation. | |
| 20:30:48 | mriedem | sean-k-mooney: that is exactly the spec i'm referring to above | |
| 20:30:52 | mriedem | and why i'm asking about this | |
| 20:31:05 | sean-k-mooney | mriedem: ah ok that make more sense. | |
| 20:31:10 | mriedem | because i'm pretty sure swapping the root volume while the instance is stopped was not part of the originally approved spec | |
| 20:31:15 | mriedem | and s10 got Kevin_Zheng to change it | |
| 20:31:22 | mriedem | b/c of how the libvirt driver works | |
| 20:31:31 | mriedem | and i'm asserting that's not a good enough reason... | |
| 20:32:07 | sean-k-mooney | right i think haveing an expcit api to say detach volume for stoped instacnce would be better | |
| 20:32:31 | sean-k-mooney | e.g. not assumeing its implcitly detatched when you stop | |