Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-08
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
21:38:12 dhellmann oh, maybe not then
21:38:28 dhellmann last I heard they were upgrading, but maybe they haven't rolled out the results
21:38:36 dhellmann it's likely mitaka, then
21:38:40 sdague mriedem: yeh
21:38:44 dhellmann I can find out if it's important
21:38:54 mriedem i don't think it's hugely important
21:38:57 sdague mriedem: yeh, I do assume that same kind of delay
21:39:21 sdague so covering the bases across 4 releases with the fix, it's probably good enough for folks
21:39:58 sdague mriedem: we should make a pretty big release note on the stable branches so it's clear to people we're restoring previous behavior
21:40:22 mriedem sdague: i can put the release note in this change itself
21:40:27 mriedem i thought about that actually but apparently forgot
21:40:31 sdague mriedem: that's fine as well
21:40:38 sdague on master, I'm slightly less concerned
21:41:22 sdague but the api fix on stable is a little bigger of a thing, because the behavior we are trying to do is get ahead of people before they upgrade, or if they upgraded, get them to bump to latest on their stable branch
21:42:40 openstackgerrit Matt Riedemann proposed openstack/nova master: api-ref: fix delete server async postcondition docs https://review.openstack.org/431190
21:45:57 openstackgerrit melanie witt proposed openstack/nova master: Add Cells V1 --> Cells V2 step-by-step example https://review.openstack.org/429075
21:45:58 openstackgerrit melanie witt proposed openstack/nova master: Edits for Cells V2 step-by-step examples https://review.openstack.org/431115
21:55:00 openstackgerrit melanie witt proposed openstack/nova master: Add Cells V1 --> Cells V2 step-by-step example https://review.openstack.org/429075
21:55:01 openstackgerrit melanie witt proposed openstack/nova master: Edits for Cells V2 step-by-step examples https://review.openstack.org/431115
21:58:57 openstackgerrit Maciej Szankin proposed openstack/nova master: config options: remove libvirt imagecache https://review.openstack.org/378497
22:02:47 melwitt dansmith, mriedem: the boot-from-volume patches for rc2 nice-to-have are ready for review. I updated the rc1 todos etherpad to indicate
22:06:42 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: mark glance.api_servers opt as required https://review.openstack.org/428241
22:08:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Allow None for block_device_mapping_v2.boot_index https://review.openstack.org/430497
22:08:37 mriedem sdague: see if this makes sense https://review.openstack.org/#/c/430497/6/releasenotes/notes/bug-1662699-06203e7262e02aa6.yaml
22:29:28 mordred mriedem, sdague: did you see that list of public nova versions I made for cdent a few weeks ago?
22:29:42 mriedem don't think so
22:29:59 mordred there are basically 2 versions in the wild ...
22:31:36 mordred mriedem, sdague, dhellmann: http://paste.openstack.org/show/598149/

Earlier   Later