On Fri, Oct 6, 2017 at 1:32 PM, Mathieu Gagné <mga...@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. > > -- > Mathieu > > > On Fri, Oct 6, 2017 at 1:22 PM, Matt Riedemann <mriede...@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 >> rest: >> >> https://bugs.launchpad.net/nova/+bug/1482040 >> >> 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: >> >> https://review.openstack.org/#/c/305079/ >> >> https://review.openstack.org/#/c/201458/ >> >> https://review.openstack.org/#/c/467588/ >> >> And Paul Murray had a related (approved) spec at one point for detach and >> attach of root volumes: >> >> https://review.openstack.org/#/c/221732/ >> >> 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. >> >> -- >> >> Thanks, >> >> Matt >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev