<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 6, 2017 at 11:22 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
I distilled several of those bugs down to just this one and duplicated the rest:<br>
<br>
<a href="https://bugs.launchpad.net/nova/+bug/1482040" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nov<wbr>a/+bug/1482040</a><br>
<br>
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).<br>
<br>
There have been a couple of patches proposed over time to change this:<br>
<br>
<a href="https://review.openstack.org/#/c/305079/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/305079/</a><br>
<br>
<a href="https://review.openstack.org/#/c/201458/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/201458/</a><br>
<br>
<a href="https://review.openstack.org/#/c/467588/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/467588/</a><br>
<br>
And Paul Murray had a related (approved) spec at one point for detach and attach of root volumes:<br>
<br>
<a href="https://review.openstack.org/#/c/221732/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/221732/</a><br>
<br>
But the blueprint was never completed.<br>
<br>
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.<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Seems reasonable and correct to me, if we were dealing with ephemeral Cinder (which isn't a thing) we'd just delete the volume, create a new one with new image. In this case however the point of BFV for must is persistence so it seems reasonable to me to start with changing the response.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.</blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">It's a bug IMO, if you're relying on an incorrect response code and not getting what you expect it seems that should be more important than consistent behavior. </div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div></div>