| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-08 | |||
| 20:59:53 | dansmith | smcginnis: otherwise you're running raid with memory cache and no battery | |
| 21:00:22 | mriedem | melwitt: we destroy the guest before we detach the volumes in _shutdown_instance | |
| 21:00:26 | dansmith | cburgess: it's just a change in behavior from right now, whereas we could add it for people that know, is all | |
| 21:00:37 | melwitt | mriedem: a-ha, okay | |
| 21:00:52 | dansmith | cburgess: anyone wondering why the volume isn't becoming available for a minute will have to realize we changed | |
| 21:00:55 | cburgess | dansmith Well I agree its a change which is why it should be a blueprint for P+? | |
| 21:01:02 | dansmith | cburgess: but agree it probably should have been this way from the beginning | |
| 21:01:14 | dansmith | cburgess: it should be a blueprint regardless of the default, IMHO | |
| 21:01:14 | cburgess | dansmith Can't we just handle that with release notes? | |
| 21:01:22 | dansmith | cburgess: lol | |
| 21:01:28 | cburgess | I mean we can add a flag I guess. | |
| 21:01:35 | cburgess | I know sdague will kill me for suggesting a flag. | |
| 21:01:37 | mriedem | no config options | |
| 21:01:44 | cburgess | Apparently mriedem too | |
| 21:01:47 | cburgess | :P | |
| 21:01:59 | dansmith | I'm not -2 on changing the default, I'm just not as up in arms about the current default | |
| 21:02:05 | dansmith | but I treat my data nicely, so | |
| 21:02:35 | melwitt | graceful destroy by default seems reasonable to me. I don't think we need a config option | |
| 21:03:19 | sdague | I think we've been back and forth across that line a bunch in the past | |
| 21:03:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: check if we can quiesce before volume-backed snapshot https://review.openstack.org/380433 | |
| 21:03:21 | cburgess | I agree it *should* be the default but if there is complaint I feel a config option is reasonable. Then again config options are so out of fashion now. | |
| 21:03:57 | dansmith | cburgess: were definitely not doing a config option :) | |
| 21:04:07 | sdague | one of the challenges with graceful shutdown by default is that you end up with a lot of cloud guests that don't have acpi actually working | |
| 21:04:15 | dansmith | right | |
| 21:04:20 | sdague | so it turns into add a 2 minute timeout to all deletes | |
| 21:04:54 | dansmith | well, four :) | |
| 21:04:55 | sdague | dansmith: oh, sorry, I only caught from cburgess yelling at me | |
| 21:05:09 | cburgess | sdague I didn't yell at you.. said you would yell at me. | |
| 21:06:18 | dansmith | with bfv, soft delete, and graceful shutdown before delete, we've really watered down the meaning of "destroy" | |
| 21:06:46 | cburgess | dansmith New call? New option to the call? destroy vs hard destroy? destroy + graceful? | |
| 21:07:12 | sdague | dansmith: well, we've given it a distinctly british flavour. please sir, may you stop now. | |
| 21:07:25 | dansmith | cburgess: well, my preference (after just telling people to shutdown their instances first) would be a "delete with flag for shut-me-down-first" | |
| 21:07:27 | cburgess | LOL | |
| 21:07:47 | dansmith | sdague: we should start apologizing to the users | |
| 21:07:49 | dansmith | 499: Sooory | |
| 21:07:54 | sdague | dansmith: ++ | |
| 21:07:56 | melwitt | the api doesn't call it "destroy" though. it's called "delete" which doesn't seem to imply anything to me | |
| 21:07:58 | cburgess | dansmith Thats not unreasonable either. New micro-version that adds an option graceful flag? | |
| 21:08:14 | cburgess | optional graceful flag even | |
| 21:08:14 | dansmith | cburgess: right | |
| 21:08:19 | melwitt | but, if the timeout is really 2 minutes then I could see the --graceful option being an option | |
| 21:08:45 | cburgess | OK well sorry to leave in the middle of this but wife just called to say the hot water heater is making a very loud banging noise continually.. so... yeah... thats fun. | |
| 21:09:08 | dansmith | melwitt: to me "delete" does not mean "don't really delete", but.. we lost the actually-deleting-things battle a while ago :P | |
| 21:09:36 | sdague | the main reason I think a lot of people want this is windows shutting down, and you get the "I'm applying patches don't turn me off" screen | |
| 21:09:51 | sdague | melwitt: so the timeout has to be at least 2 minutes so you don't kill that | |
| 21:09:58 | dansmith | oh forgot about that, that's a good one | |
| 21:10:00 | melwitt | dansmith: heh, I guess. as a layperson, I didn't think of "delete" as meaning much other than "get rid of this instance" and not thinking about what happens underneath | |
| 21:10:45 | mriedem | i think of delete as 'get rid of this instance' but also, don't mess up all my crap that's attached to it unless you're also deleting that, like volumes and ports | |
| 21:10:47 | cfriesen | isn't the default shutdown timeout 60 sec? | |
| 21:10:53 | melwitt | 2 minutes for windows update, that's generous (to think it would be that short) | |
| 21:11:06 | dansmith | melwitt: I know, 2 minutes is laughable | |
| 21:11:08 | sdague | melwitt: once upon a time there was 120 timer here | |
| 21:11:27 | dansmith | mriedem: "mess up my crap" is relative though. it won't corrupt the filesystem | |
| 21:11:30 | sdague | and it did do all sorts of oddity in the gate, because cirros totally ignores acpi | |
| 21:11:38 | sdague | so we were hanging around forever | |
| 21:11:49 | dansmith | mriedem: if your app corrupts your data on this event, then it also corrupts your data if the power goes out in the datacenter, so.. meh | |
| 21:11:52 | mriedem | i vaguely remember that, | |
| 21:12:00 | mriedem | didn't we revert Phil's like 1K LOC patch or somethign? | |
| 21:12:03 | melwitt | if it were called 'nova pull-the-power-cord' that would be clear to me :P | |
| 21:12:11 | mriedem | dansmith: true | |
| 21:12:22 | sdague | mriedem: maybe, I don't remember exactly how long it was around | |
| 21:12:32 | dansmith | sdague: ah, that's what I was thinking of | |
| 21:12:34 | melwitt | yeah, I can see both arguments | |
| 21:12:59 | mriedem | so at what point so volume multi-attach fix all of this? :) | |
| 21:13:05 | mriedem | s/so/does/ | |
| 21:13:35 | sdague | so, if it was a thing... (which I'm still not convinced it should be) it definitely doesn't seem like a system wide answer is the right answer | |
| 21:13:48 | dansmith | mriedem: volume multiattach asumes you don't have an app that would corrupt things like this, so that's a good argument for not caring IMHO :) | |
| 21:13:54 | sdague | it would be image based or instance based metadata for shutdown time | |
| 21:14:15 | sdague | so windows people could tune it up to 20 minutes for snowflakes | |
| 21:14:17 | cfriesen | sdague: you mean like os_shutdown_timeout ? | |
| 21:14:17 | dansmith | image.I_suck=True | |
| 21:14:33 | sdague | cfriesen: maybe, that already in there? | |
| 21:14:40 | cfriesen | sdague: yep | |
| 21:14:41 | sdague | that vaguely sounds familiar | |
| 21:14:43 | dansmith | lol | |
| 21:14:48 | sdague | ok, probablem solved! | |
| 21:14:58 | dansmith | unfuckingbelievable | |
| 21:15:04 | cfriesen | sdague: well, except it's only for shutdown, not for delete | |
| 21:15:04 | melwitt | hahaha | |
| 21:15:04 | dansmith | I want my 20 minutes back | |
| 21:15:47 | sdague | cfriesen: ok, but that means there is still a way for you to get what you want right? | |
| 21:15:48 | dansmith | ah, so setting it doesn't imply the different behavior on delete | |
| 21:15:56 | sdague | delete is delete | |
| 21:16:10 | cfriesen | dansmith: correct. sdague: I can manually do a nova shutdown before doing a delete, sure. | |
| 21:16:22 | mriedem | we don't check the image meta / extra spec for that on delete, only stop | |
| 21:16:26 | dansmith | right | |
| 21:16:35 | mriedem | but we could... | |
| 21:16:44 | sdague | ok, so I feel like thats fine then, there is an API people can use if they want the behavior | |
| 21:16:45 | mriedem | w/o new API parameters | |
| 21:16:57 | dansmith | sdague: agreed | |
| 21:17:17 | dansmith | sdague: we knew stop does what we want, but didn't know it was configurable timeout, which makes it even more useful for the thing | |
| 21:17:18 | mriedem | i always forget image_meta/extra_specs | |
| 21:17:31 | sdague | mriedem: well, they also aren't hugely tested | |
| 21:17:41 | mriedem | sdague: neither are the 5K config options | |
| 21:17:48 | dansmith | I think you mean bigly | |
| 21:17:50 | mriedem | but i tend to think of them in the same way | |
| 21:17:54 | cfriesen | sdague: maybe we document that "nova delete" is explicitly a hard shutdown, and may result in data loss unless the guest flushes disks first? | |
| 21:18:51 | openstackgerrit | Pushkar Umaranikar proposed openstack/nova master: Placement api: set custom json_error_formatter in allocations https://review.openstack.org/395194 | |
| 21:19:05 | sdague | http://developer.openstack.org/api-ref/compute/?expanded=stop-server-os-stop-action-detail,delete-server-detail#delete-server | |
| 21:19:12 | sdague | "By default, the instance is going to be (hard) deleted immediately from the system" | |