Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-08
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 dansmith image.I_suck=True
21:14:17 cfriesen sdague: you mean like os_shutdown_timeout ?
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 dansmith I want my 20 minutes back
21:15:04 melwitt hahaha
21:15:04 cfriesen sdague: well, except it's only for shutdown, not for delete
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"
21:19:31 sdague it could be tightened up for sure
21:19:51 dansmith By default, the instance is going to be (hard) deleted immediately
21:19:52 dansmith yeah
21:19:55 mriedem oh nice
21:19:56 melwitt yeah, I think it wouldn't hurt and only help to add that bit of additional obvious info
21:19:56 mriedem "With correct permissions, you can see the server status as"
21:19:58 mriedem AS WHAT?!
21:20:17 melwitt it's a secret!
21:20:40 sdague mriedem: we have the best statuses
21:20:45 mriedem i paid for the whole seat but only need the edge
21:20:52 dansmith that's true, if you really want this a an op, you can turn on soft_delete for 2 minute reclaim
21:21:11 sdague dansmith: well... that's different yet again right?
21:21:16 sdague That just defers the delete
21:21:24 sdague it still hard deletes when it happens
21:21:25 mriedem does it stop the instance?
21:21:26 dansmith sdague: same effect I think, we shutdown the instance and then delete it two minutes later
21:21:34 sdague I thought we just held
21:21:37 dansmith I don't think it hard deltes at the beginng
21:21:38 sdague it was more for the undelete case
21:21:48 dansmith no, it doesn't keep running
21:21:49 dansmith sdague: it is
21:22:24 dansmith self.driver.power_off(instance)
21:22:42 mriedem yup[
21:22:44 dansmith graceful shutdown, which will wait, and then soft_delete will reclaim in $interval
21:22:45 mriedem was just looking at that
21:23:15 sdague ah, ok
21:23:24 mriedem i was recently complaining about reclaim_instance_interval
21:23:46 mriedem but in my old age i've forgotten why
21:23:55 dansmith because it's stupid?
21:24:14 mriedem well, my complaint was if you set reclaim_instance_interval in the api but not on the compute hosting the instance, the instance won't actually be deleted
21:24:20 mriedem but, we assume you don't do that
21:24:24 dansmith ah yep
21:24:49 mriedem we assume you've correctly configured nova.conf's 5K options and deployed it correctly on all of your services
21:24:59 mriedem oops mine just blew off your toe!
21:25:38 mriedem at some point i think capabilities will bridge that gap
21:25:48 mriedem since the api could tell what the capabilities are on the host
21:25:51 cfriesen looks like only xen supports soft delete
21:26:17 cfriesen oh, I guess we fall back to just power_off
21:26:18 dansmith cfriesen: we fall back to poweroff if the driver doesn't do anything
21:26:20 dansmith yeah
21:28:08 mriedem https://bugs.launchpad.net/nova/+bug/1663036
21:28:08 openstack Launchpad bug 1663036 in OpenStack Compute (nova) "api-ref: delete server async postcondition doc is missing some info" [Medium,Confirmed]
21:28:17 mriedem for any low-hanging-fruit grabbers
21:28:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Allow None for block_device_mapping_v2.boot_index https://review.openstack.org/430497
21:28:57 cfriesen soft-delete can be undone though, so you can't really re-use any attached volumes until it's actually deleted, right?
21:29:00 mriedem sdague: assuming you're not tired of us, ^ is controversial
21:29:26 mriedem cfriesen: correct
21:31:00 dansmith cfriesen: but that's what you want if you want to wait
21:31:13 dansmith cfriesen: so you set the interval short, to your max timeout, and then you get what you want
21:35:19 sdague mriedem: so... if we aren't doing a microversion then we are backporting to all active stable branches right?
21:35:41 mriedem sdague: that was my plan yes
21:36:07 sdague including mitaka?
21:36:14 mriedem that was my plan yes
21:36:26 sdague if you are going to take it back to there, I'd be fine with it
21:36:36 mriedem ok
21:36:37 sdague it definitely is a bug to have busted that
21:37:12 mriedem when mordred and dhellmann were reporting it, they said it used to work, which i assume meant when they were talking to older clouds that were only exposing v2
21:37:37 mriedem and i also assume that most clouds are around 18 months behind trunk
21:37:45 dhellmann yes, it works on dreamhost's deployment but not devstack
21:37:53 dhellmann I believe dreamhost is running newton by now
21:38:05 mriedem we dropped the v2 code in newton,
21:38:09 mriedem so i doubt it

Earlier   Later