| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-08 | |||
| 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" | |
| 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 | mriedem | "With correct permissions, you can see the server status as" | |
| 21:19:56 | melwitt | yeah, I think it wouldn't hurt and only help to add that bit of additional obvious info | |
| 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 | openstack | Launchpad bug 1663036 in OpenStack Compute (nova) "api-ref: delete server async postcondition doc is missing some info" [Medium,Confirmed] | |
| 21:28:08 | mriedem | https://bugs.launchpad.net/nova/+bug/1663036 | |
| 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 | |