[openstack-dev] [Openstack-operators] [nova] Should we make rebuild + new image on a volume-backed instance fail fast?
mnaser at vexxhost.com
Fri Oct 6 17:54:02 UTC 2017
On Fri, Oct 6, 2017 at 1:32 PM, Mathieu Gagné <mgagne at calavera.ca> wrote:
> 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.
You are right, this is indeed something that is not possible.
> 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
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
Mohammed Naser — vexxhost
D. 800-910-1726 ext. 200
E. mnaser at vexxhost.com
More information about the OpenStack-dev