[openstack-dev] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?
mgagne at calavera.ca
Fri Oct 6 17:32:32 UTC 2017
Why not supporting this use case?
Same reason as before: A user might wish to keep its IP addresses.
The use cannot do the following to bypass the limitation:
1) stop instance
2) detach root volume
3) delete root volume
4) create new volume
5) attach as root
6) boot instance
Last time I tried, operation fails at step 2. I would need to test
against latest version of Nova to confirm.
Otherwise boot-from-volume feels like a second class citizen.
On Fri, Oct 6, 2017 at 1:22 PM, Matt Riedemann <mriedemos at gmail.com> wrote:
> This came up in IRC discussion the other day, but we didn't dig into it much
> given we were all (2 of us) exhausted talking about rebuild.
> But we have had several bugs over the years where people expect the root
> disk to change to a newly supplied image during rebuild even if the instance
> is volume-backed.
> I distilled several of those bugs down to just this one and duplicated the
> I wanted to see if there is actually any failure on the backend when doing
> this, and there isn't - there is no instance fault or anything like that.
> It's just not what the user expects, and actually the instance image_ref is
> then shown later as the image specified during rebuild, even though that's
> not the actual image in the root disk (the volume).
> There have been a couple of patches proposed over time to change this:
> And Paul Murray had a related (approved) spec at one point for detach and
> attach of root volumes:
> But the blueprint was never completed.
> So with all of this in mind, should we at least consider, until at least
> someone owns supporting this, that the API should fail with a 400 response
> if you're trying to rebuild with a new image on a volume-backed instance?
> That way it's a fast failure in the API, similar to trying to backup a
> volume-backed instance fails fast.
> If we did, that would change the API response from a 202 today to a 400,
> which is something we normally don't do. I don't think a microversion would
> be necessary if we did this, however, because essentially what the user is
> asking for isn't what we're actually giving them, so it's a failure in an
> unexpected way even if there is no fault recorded, it's not what the user
> asked for. I might not be thinking of something here though, like
> interoperability for example - a cloud without this change would blissfully
> return 202 but a cloud with the change would return a 400...so that should
> be considered.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev